Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

From: [email-masked]
Date: Thu, 19 Aug 2010 09:37:44 +0200

Hi Maarten,

Please see my reply inline as <Jingrq>.

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, August 18, 2010 2:52 PM
> To: [email-masked]
> Cc: [email-masked]

> Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
>
> Hi Ruiquan,
>
> It is very uncommon to shutdown an input port after detection
> of a physical layer degraded signal (DEG) condition. DEG
> conditions represent a low error rate condition and provide a
> warning that the the link is not longer error free.
>
> In SDH VC-n terms, a DEG condition occurs when either
> - the BER is exceeding a configurable threshold of 10-x, with
> x=5,6,7,8,9, or
> - the number of errored blocks per second is exceeding a
> configurable threshold THR during M consecutive seconds, with
> M=2..10 (default 7) and THR=0..100% (default 30%).
>
> In OTN ODUk terms, a DEG condition occurs when
> - the number of errored blocks per second is exceeding a
> configurable threshold THR during M consecutive seconds, with
> M=2..10 (default 7) and THR=0..100% (default 15%).
>
> Under those conditions there is no reason to shutdown the
> input port; traffic is still flowing with some number of bit
> errors, and some loss of packets. SLAs for the unprotected
> services is still met; only SLA for protected services with
> SD=DEG trigger conditions will not longer be met and traffic
> should be switched.
> Shutting down the input port under this limited loss of
> packets will make all unprotected services to fail, and thus
> make many customers unhappy...
<Jingrq> I get this idea from the current practice of POS and 10GE WAN 
interface on IP router. 
AFAIK, there are very few unprotected services in our transport network. 
Because when the fiber is cut, unprotected services will fail anyway.

> -----------
>
> Note that SDH also includes an optional Excessive (EXC)
> condition, which contributes to the signal fail (SF)
> condition (SF = ... or EXC or ...). EXC condition is only
> specified for networks in which Poisson distributed errors
> prevail. EXC occurs when
> - the BER is exceeding a configurable threshold of 10-x, with x=3,4,5.
>
> Detection of EXC does not block the forwarding of the traffic
> in the input port (see G.783), nor causes the insertion of
> RDI; it only is an additional trigger condition for
> protection switching.
>
> In OTN networks Poisson distributed error conditions are
> assumed to be 'not present', so OTN does not support the
> detection of such EXC condition.
>
> -----------
>
> May I ask you a few questions concerning your definition of
> SD condition; I am not sure if we have a common understanding
> of the SD condition...
>
> Q1: Could you describe the packet loss ratio (PLR) value or
> value range that you would like to see detected and
> consequently trigger a protection switch action? E.g.
> 1) 50%
> 2) 30%
> 3) 10% (1E-1)
> 4) 1% (1E-2)
> 5) 0.1% (1E-3)
> 6) 0.01% (1E-4)
> 7) 0.001% (1E-5)
> 8) 0.0001% (1E-6)
> 9) other..
<Jingrq> I think the PLR equal to 1E-6 BER will be ok, which is about  0.08%
£¨MTU=64byte£©or 1%£¨MTU=1500byte£©.

> Q2: Could you indicate how quickly you would like to see the
> packet loss ratio degradation detected? E.g.
> 1) 10 seconds
> 2) 7 seconds (default value for bursty error distribution DEG defect
> detector)
> 3) 5 seconds
> 4) 3 seconds
> 5) 1 second
> 6) 100 ms
> 7) 10 ms
> 8) 3.3 ms
> 9) other..
<Jingrq>I don't have spcific value for it. Just like in SDH will be ok.

>
> As proposed and discussed on this mailinglist, an alternative
> SD condition definition in a packet transport network is the
> use of the physical layer SD condition, which is based on
> detecting bit errors by means of Error Detection Code
> Violation (EDCV) measurements (e.g. BIP, CRC, FCS).
>
> For the case MPLS-TP LSPs/PWs are transported within the
> payload of PDH, SDH VC-n or OTN ODUk signals it is possible
> to use the PDH, SDH and OTN EDCV detectors to determine a DEG
> (or perhaps EXC) condition and use these conditions to
> trigger protection switching in a packet layer (MPLS-TP
> Section layer, MPLS-TP Transport Path layer, MPLS-TP
> Transport Service layer).
>
> Such physical layer based SD condition is a different
> condition than a packet layer based SD condition.
> Nonetheless, if our industry wants to use such physical layer
> SD condition instead of a packet layer one, then we can
> define it and have it implemented.
<Jingrq>I think we should support physical layer based SD.

>
> Q3: For the case the operator community would agree with such
> physical layer SD definition for packet transport networks,
> what would be the physical layer SD condition definition?
> 1) [assume bursty error distribution] the number of errored
> blocks per
>    second is exceeding a configurable threshold THR during M
> consecutive
>    seconds, with M=2..10 (default 7) and THR=0..100%.
> 2) [assume poisson error distribution] the BER is exceeding a
> configurable
>    threshold of 10-x, with x=3,4,5
> 3) [assume poisson error distribution] the BER is exceeding a
> configurable
>    threshold of 10-x, with x=5,6,7,8,9
<Jingrq> This one.

> 4) other...
>
> Q4: And what should be the detection times of such physical
> layer SD condition?
 <Jingrq> Same as in SDH/OTN.

Best regards 
  
Ruiquan Jing

---

From: [email-masked]
Date: Mon, 23 Aug 2010 02:49:27 +0200

Hi Neil£¬

Just to clarify, what I mean is that the two type of SD should be supported by 
MPLS-TP based PTN, not by MPLS-TP. 
I think Type I SD should be supported by PTN equipment, although it doesn¡¯t 
belong to MPLS-TP.

Best regards 
  
Ruiquan

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, August 18, 2010 3:21 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> What is written here is technically 'not very good' (I am 
> being polite)......see in-line: 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Sent: 18 August 2010 06:57
> > To: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> > 
> > Hi all,
> > 
> > IMHO, I think we can separate SD in MPLS-TP into two type:
> > Type I: SD based on monitoring of the physical layer signal such as 
> > SDH/OTN/ETH PHY.
> 
> NH=> What!  These are separate layer networks in their own 
> right.  The fact they have a real physical manifestation (ie 
> q'ary EM modulating symbol mapping from binary path symbols) 
> is simply a property that a real BOS transport networks 
> should have....MPLS-TP does not have this property, so always 
> relies on having real BOS layer networks under it that do.  
> 
> Aside=> Irrespective of what I just stated above, the fact 
> MPLS-TP continues to have MS-PWs and has sublayering per se 
> stands out like a beacon that announces 'this is not a 
> transport network' anyway.  What we have in reality is just 
> another spin of MPLS with the big/obvious problems of merging 
> and the lack of OOB CP/MP partially addressed. 
> 
> And why should these SDH/etc layer networks be coupled in 
> some way to MPLS-TP?....MPLS has enough layering/arch 
> violations of its own without adding more.  
> 
> But in any case this proposal is technically flawed from the 
> trite observation that an end-2-end path in any of the 
> SDH/etc layer networks mentioned is *only 1 link-connection* 
> (==hop) of a BOS MPLS LSP (whether this is a true layer LSP 
> or sublayer LSP).  In addition to the obvious technical 
> problems of length incongruence and perf degradation 
> metric/objective scaling (even if all the layers were owned 
> by the same party), there is another problem in that 
> monitoring a server layer path does not pick-up 
> defects/perf-problems in client layer network nodes.
> 
> So please let us have no more of saying that a server layer 
> network can proxy for the defects/performance of a client 
> layer.....each layer must be self-contained and look after itself.
> 
> 
> > Type II: SD based on measurements of packet loss of LSP/PW
> > 
> > In my point of view,  Type I SD should be supported in the first 
> > phase,
> 
> NH=> This has nothing to do with MPLS-TP (see above)...so why 
> are you making this flawed proposal?
> 
> 
> > Type II SD could be supported in future.
> > The problem with  Type I SD is that 1GE & 10GE LAN PHY 
> don't support 
> > BER monitoring,
> 
> NH=> BER monitoring!?  Are you serious?  Poisson models of 
> error events are quite inappropriate for digital transport 
> networks....this fact has been known for the last 20 years or so.
> 
> I suppose you might even propose doing Type I SD for each QoS 
> class (sic) that a client LSP carries in the server 
> layer?.....which of course would be madness in the extreme.  
> To appreciate this one must properly grasp what 
> *transparency* really means...and the one service-behaviour 
> that a transport network MUST be able to provide to its 
> clients is transparency.  Hint=> Transport networks MUST NOT 
> have multiple QoS classes in the same connection.
> 
> > but they are the mainstream interface type on MPLS-TP based 
> > equipments.
> 
> NH=> So what?  They are the physical manifestation 
> (interfaces) of other layer networks which possess a true BOS 
> form, ie can modulate an EM wave.....the fact that a client 
> of theirs might be MPLS-TP (or some other layer network 
> technology) is quite irrelevant.
> 
> regards, Neil  
> 
> > 
> > Best regards
> >   
> > Ruiquan Jing
> >  
> > China¢®¢®Telecom  Beijing  Research¢®¢®Institute
> >  
> > 
> > > From: Adrian Farrel [mailto:[email-masked]]
> > > Sent: Tuesday, August 17, 2010 8:42 PM
> > > To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Alexander 
> > > Vainshtein; [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> > > 
> > > Hi,
> > > 
> > > I didn't want to get dragged into a discussion of how SD is
> > measured
> > > since the point I was responding to was whether or not SD 
> could be 
> > > used as a trigger for protection switching.
> > > 
> > > But, since the box has been opened :-( ....
> > > 
> > > > The second fragment is more informative. It is located 
> in Section
> > > > 6.4.1 of the draft and says:
> > > > <quote>
> > > >   Signal degradation - notification from OAM performance
> > monitoring
> > > >   indicating degradation in the working entity may also
> > be used as a
> > > >   trigger for protection switching.  In the event of 
> degradation,
> > > >   switching to the recovery entity is necessary only if
> > the recovery
> > > >   entity can guarantee better conditions.  Degradation can be
> > > >   measured by proactively activating MPLS-TP OAM packet loss
> > > >   measurement or delay measurement.
> > > > <end quote>
> > > >
> > > > I would like to note that the quoted fragment contains
> > two important
> > > > statements:
> > > >
> > > > 1. Degradation can be measured by proactively activating
> > MPLS-TP OAM
> > > >     packet loss measurement or delay measurement.
> > > >   - IMHO excludes SD detection based directly on
> > monitoring of the
> > > > physical
> > > >     layer as proposed by Ruiquan and others
> > > 
> > > The text makes no such statement!
> > > When you say how something can be done, you make no comment about 
> > > other ways that it can be done.
> > > 
> > > However, I would say that monitoring the physical layer is
> > precisely
> > > that.
> > > I.e., it is monitoring in a lower layer. This is definitely
> > acceptable
> > > (for example, I am sure that we are happy to use LOL
> > reported by the
> > > physical layer as an indication that there may be a problem
> > with the
> > > link), however, I don't think this counts as SD in the 
> packet layer.
> > > 
> > > > - Seems to ignore the fact that measurements of packet loss
> > > and delay are
> > > >    not applicable to MPLS-TP entities that carry multiple
> > > traffic classes.
> > > >    AFAIK, such entities are allowed in MPLS-TP.
> > > 
> > > "ignore" may be a bit harsh :-)
> > > But you are right that there is no discussion.
> > > 
> > > > 2. In the event of degradation, switching to the recovery
> > entity is
> > > > necessary
> > > >    only if the recovery entity can guarantee better conditions.
> > > >    - Packet loss and delay in packet networks depend on the
> > > actual traffic
> > > >      pattern. Hence the only case when SD-triggered
> > > switching is necessary
> > > >      is 1+1 linear protection (when the same traffic pattern is 
> > > > guaranteed on
> > > >      two alternative paths). In all the other cases "better
> > > conditions" 
> > > > cannot
> > > >      be guaranteed
> > > 
> > > You are correctly interpretting "guarantee".
> > > You seem to be ingnoring "necessary". "Necessary only if" 
> > > does not prohibit switching under other circumstances. 
> > Choose how to
> > > operate your network, define your policy, configure your 
> > > implementations.
> > > 
> > > > - Limited applicability of SD based on packet loss has been
> > > discussed
> > > > on this
> > > >    list. SD based on delay measurements has not been explicitly 
> > > > discussed, but
> > > >    I do not see any difference.
> > > 
> > > Hmmm. Yes.
> > > I wonder if there is any other meaning to SD in a packet network?
> > > 
> > > > The bottom line:
> > > >
> > > > My reading of the draft to which Adrian refers says that:
> > > > - Applicability if SD as a trigger for protection is
> > indeed captured
> > > > - This applicability is restricted to a very special use
> > case (1+1
> > > > linear protection).
> > > 
> > > As is (I hope) clear from what I wrote above, I agree with
> > your first
> > > statement, but I find your second statement too restrictive.
> > > 
> > > Cheers,
> > > Adrian
> > > 
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >