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

From: [email-masked]
Date: Tue, 17 Aug 2010 08:46:51 +0200

Hi Maarten and all,

Here is another option to use SD as a triger for protection switch.
When a node detect on its ingress port some bit errors when terminating the 
physical layer signal,if the BER excede the SD thread, the node should shutdown 
this port/link. Then send a RDI to it's peer node.  By this way, PW/LSP end-
point will detect the port/link down by CC, and then do protection switch.

Any comments?

Best regards 
  
Ruiquan Jing 
 
China¡¡Telecom  Beijing  Research¡¡Institute 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Thursday, July 29, 2010 3:54 PM
> To: 'Rafi Ram'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> 
> Rafi,
>  
> If you look at the SD specification in G.8021 (i.e. for 
> Ethernet based packet transport network), then you will find 
> the following:
> 1) SD = dDEG
> 2) dDEG is activated if there are M (2 <=M <= 10) consecutive 
> BAD seconds. A BAD second is a second in which the frame loss 
> ration exceeds the value DEGTHR and more then a minimum 
> number of TFMIN frames was transmitted.
>  
> The MEP Sink function detecting the dDEG defect is totaly 
> unaware of the reasons of the frame loss; it could be bit 
> errors on the medium and/or frame drops due to congestion 
> and/or other frame drop conditions.
>  
> For MPLS-TP based packet transport networks it will be the same.
> 
> ****************
> 
> If you would like to change this and would only trigger 
> protection switching due to bit errors on a medium, then you 
> would need to create a complex error forwarding mechanism... 
> e.g. assume that a PW or service-LSP is passing through e.g. 
> 10 nodes as follows:
>  
> PE1 - PE2 - P1 - PE3 - P2 - P3 - PE4 - P4 - PE5 - PE6
>          \- P5 - PE7 - P6 - P7 - PE8 - P8 -/   
> 
> 				FIGURE 1
>  
> 1:1 PW/service-LSP SNC protection is set up between PE2 and PE5.
> Assume that bit errors occur on the links between PE2->P1 and P2->P3. 
> How will PE5 be aware of the occurrence of those bit errors?
> 
> A) P1 will detect on its ingress port some bit errors when 
> terminating the physical layer signal.
> B) P3 will detect on its ingress port some bit errors when 
> terminating the physical layer signal.
> C) P1 and P3 have to communicate those bit error indications 
> to PE5, but P1 and P3 are totally unaware of the PW or 
> service-LSP's SPME which is monitoring the PE2 egress to PE5 
> ingress working connection ("working SPME LSP" in Figure 2).
> 
> |----------------PW or service-LSP------------------|
> 
>         |---------working SPME LSP----------|
>         |-tLSP23-| |---tLSP34----| |-tLSP45-|
>   |-S-| |-S-||-S-| |-S-||-S-||-S-| |-S-||-S-| |-S-|
>   |-P-| |-P-||-P-| |-P-||-P-||-P-| |-P-||-P-| |-P-|
> 
> PE1 - PE2 - P1 - PE3 - P2 - P3 - PE4 - P4 - PE5 - PE6
>          \- P5 - PE7 - P6 - P7 - PE8 - P8 -/ 
>   
>         |-P-||-P-| |-P-||-P-||-P-| |-P-||-P-|
>         |-S-||-S-| |-S-||-S-||-S-| |-S-||-S-|
>         |-tLSP27-| |---tLSP78----| |-tLSP85-|
>         |-------protection SPME LSP---------|
> 
> P: Physical medium conection
> S: MPLS-TP Section connection
> tLSP: MPLS-TP transport-LSP
> 
> 				FIGURE 2
> 
> D) In theory you could think of the following bit error 
> communication channel architecture:
> 1) P1 ingress port will write the number of bit errors (or 
> errored blocks) detected in a second on the physical 
> interface into a Bit Error Comms (BEC) OAM packet and insert 
> this BEC OAM packet into tLSP23 (and all other tLSPs active 
> on this interface)
> 2) PE3 will detect the BEC OAM packet in its tLSP23 MEP Sink 
> function and inserts this BEC packet into the working SPME 
> LSP (and in all other LSPs/PWs present in tLSP23)
> 3) P3 ingress port will write the number of bit errors 
> detected in a second on the physical interface into a BEC OAM 
> packet and insert this BEC OAM packet into tLSP34 (and all 
> other tLSPs active on this interface)
> 4) PE4 will detect the BEC OAM packet in its tLSP34 MEP Sink 
> function and inserts this BEC packet into the working SPME 
> LSP (and in all other LSPs/PWs present in tLSP34)
> 5) PE5 will detect the BEC OAM packets inserted into the 
> working SPME LSP by
> PE3 and PE4 in its working SPME LSP MEP Sink function.
> 
> Unfortunately, PE5 does not have any information if those bit 
> errors/errored blocks have caused any actual packet loss in 
> the working SPME LSP. How can
> PE5 now correctly interprete the numbers within the BEC OAM 
> packets? Perhaps the working SPME LSP MEP in PE5 can also 
> count the number of packets lost between PE2 and PE5 on the 
> working connection, and use the BEC information to filter the 
> packet loss information; e.g. if no BEC OAM packets are 
> received, then assume any packet loss is due to congestion; 
> if BEC OAM packets are received, then assume packet loss is 
> due to bit errors.
> 
> As the 1-second bit error/errored block counting in P1 and P3 
> and the 1-second packet loss counting in PE5 are not 
> synchronized, there is a misalignment in the BEC OAM and 
> packet loss information counting... This will degenerate the 
> correctness of the results... i.e. we will get very arbitrary results.
> 
> Can we do better? An other alternative is to require that the 
> egres ports count the number of discarded packets due to 
> congestion; e.g. PE2, P1, PE3, P2, P3, PE4 and P4 could be 
> configured to count the number of discarded working SPME LSP 
> packets in their egress ports and generate every 1-second a 
> Discarded Packets (DP) OAM packet into the working SPME LSP. 
> For P1, P2, P3,
> P4 this implies that these nodes have to have awareness of 
> the inner working SPME LSP... Not a very attractive option in 
> my understanding.
> 
> 
> If MPLS-TP is carrying an Ethernet service (90% of cases), 
> then the Ethernet customer will use its Ethernet frame loss 
> measurement capability to check if his service provider 
> (using his MPLS-TP network) complies with the agreed SLA. The 
> customer will as such count lost, non-drop eligible ethernet 
> frames, including those frames lost due to congestion in the 
> service providers network. If the service provider is 
> counting dropped frames/packets excluding those dropped due 
> to congestion, there will be regularly conflicts between the 
> customer and service provider with respect to the number of 
> lost frames. Very bad for the MPLS-TP technology...
> 
> Regards,
> Maarten
> 
> ________________________________
> 
> From: Rafi Ram [mailto:[email-masked]]
> Sent: woensdag 28 juli 2010 20:58
> To: Maarten Vissers; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> 
> 
> Maarten,
>  
> There are (at least) 3 possible link impairment:
> 1. Bit errors on link
> 2. Offered load greater than link bandwidth (i.e. congestion)
> 
> 3. Reduction in link bandwidth
> 
> In existing transport networks (which MPLS-TP targets) :
> (a) Only bit errors are considered cause for SD condition
> (b) Protection is triggered due to SD condition
> 
> Regards
> Rafi
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Aug 2010 12:13:35 +0100

Hi Ruiquan,

I agree with you that SD can be a trigger for protection switching.

I believe this is captured clearly in draft-ietf-mpls-tp-survive-fwk

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 17, 2010 7:46 AM
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten and all,

physical layer signal,if the BER excede the SD thread, the node should 
shutdown

Any comments?

Best regards

Ruiquan Jing

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 17 Aug 2010 15:06:41 +0300

Adrian, Ruiquan, and all,
I've looked up draft-ietf-mpls-tp-survive-fwk-06 (now in the RFC Editor queue) in order to check
What exactly it captures with regard to SD as a trigger for protection.

I've found two relevant fragments.

The first one is an reference to ITU-T G.806 (01/09). Unfortunately, this document does not specify
how the signal degrade (SD) condition can be detected.

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
   - 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.

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
   - 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.

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).

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, August 17, 2010 2:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Ruiquan,

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 17, 2010 7:46 AM
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten and all,

Any comments?

Best regards

Ruiquan Jing

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 17 Aug 2010 14:11:13 +0200

Sasha, hi

I fully support your conclusions that performing protection switching based on SD indications should be very restricted and that we need to be careful in defining the phrase (quoted from the survivability framework) "only if the recovery entity can guarantee better conditions"!

BR,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Alexander Vainshtein
Sent: Tuesday, August 17, 2010 15:07
To: Adrian Farrel; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

The bottom line: 

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, August 17, 2010 2:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Ruiquan,

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 17, 2010 7:46 AM
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten and all,

Any comments?

Best regards

Ruiquan Jing

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Aug 2010 13:42:01 +0100

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 :-( ....

> 1. Degradation can be measured by proactively activating MPLS-TP OAM
>     packet loss measurement or delay measurement.

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?

> - This applicability is restricted to a very special use case (1+1 linear 

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

---

From: <[email-masked]>
Date: Tue, 17 Aug 2010 14:16:13 +0100

Whatever you do do not assume a BER model (ie Poisson) of error
distributions is correct.  I spent years measuring error events and
breaks on real transport networks (albeit sometime ago) and BER is about
as wrong as as a model as one can get.  I did place a post here I little
while ago that went into a little more detail on the nature of real
error events, viz
http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04491.html.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 17 August 2010 13:42
> To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Alexander 
> Vainshtein; [email-masked]
> Cc: [email-masked]
> 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.
> 
> When you say how something can be done, you make no comment 
> about other ways that it can be done.
> 
> 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.
> 
> >      is 1+1 linear protection (when the same traffic pattern is 
> > guaranteed on
> 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
> 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 
>

---

From: [email-masked]
Date: Wed, 18 Aug 2010 07:57:30 +0200

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.
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, 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, but they are the mainstream interface type on MPLS-TP based 
equipments. 

Best regards 
  
Ruiquan Jing 

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, August 17, 2010 8:42 PM

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 08:51:50 +0200

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...

-----------

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..

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..

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.

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
4) other...

Q4: And what should be the detection times of such physical layer SD
condition?

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 17 augustus 2010 8:47
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten and all,

Here is another option to use SD as a triger for protection switch.
When a node detect on its ingress port some bit errors when terminating the
physical layer signal,if the BER excede the SD thread, the node should
shutdown this port/link. Then send a RDI to it's peer node.  By this way,
PW/LSP end- point will detect the port/link down by CC, and then do
protection switch.

Any comments?

Best regards 
  
Ruiquan Jing

---

From: <[email-masked]>
Date: Wed, 18 Aug 2010 08:21:12 +0100

What is written here is technically 'not very good' (I am being polite)......see in-line: 

> [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]
> 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.

> 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  

> measured 
> > since the point I was responding to was whether or not SD could be 
> > used as a trigger for protection switching.
> > 
> > > I would like to note that the quoted fragment contains 
> two important
> > > statements:
> > >
> > >   - IMHO excludes SD detection based directly on 
> monitoring of the 
> > > physical
> > 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.
> 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.
> > 
> > does not prohibit switching under other circumstances. 
> Choose how to 
> > operate your network, define your policy, configure your 
> > implementations.
> > 
> > > - This applicability is restricted to a very special use 
> case (1+1 
> > > linear protection).
> > 
> your first

---

From: <[email-masked]>
Date: Wed, 18 Aug 2010 08:35:01 +0100

Maarten,

I would like to think that you have written in here is an attempt to expose just how daft the proposal to use a server layer network to proxy for the performance monitoring of a client layer network is.

Your questions 1 and 2 do strongly hint at the problems of both metric mapping (big problem for co-cs server and co-ps or cl-ps mode clients) and temporal scaling.  However, this does not consider the problems of layer ownership by different parties, the fact that we also have a length scaling problem (ie a E2E path at layer N is only a single link connection at layer N-1) or the fact that server layer paths cannot pick-up client layer nodal defects/perf problems

Your questions 3 and 4 should be a massive hint to others in the operator community just how daft this idea is, eg make them think about things like *metric* mappings across different network modes.

regards, Neil

> Sent: 18 August 2010 07:52
> 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.
> 
> - 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%).
> 
> - 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...
> 
> -----------
> 
> 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
> 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..
> 
> Q2: Could you indicate how quickly you would like to see the 
> packet loss ratio degradation detected? E.g.
> 1) 10 seconds
> 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 
> 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?
> Q4: And what should be the detection times of such physical 
> layer SD condition?
> 
> 
> Regards,
> Maarten
> 
> 
> When a node detect on its ingress port some bit errors when 
> terminating the physical layer signal,if the BER excede the 
> SD thread, the node should shutdown this port/link. Then send 
> a RDI to it's peer node.  By this way, PW/LSP end- point will 
> detect the port/link down by CC, and then do protection switch.
> 
> Any comments?
> 
> Best regards 
>   
> Ruiquan Jing 
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 09:35:47 +0200

Hi,

It seems that we have to discuss the definition of the "SD (Signal Degrade)"
condition for packet connections and that we have to discuss the underlying
reason that such SD condition is requested to control a protection switch
action.

To start with the latter item, protection switching is typically applied to
the high performance transport service layer connections, for which the SLA
specifies very high availability and very low severely errored seconds
numbers. 

In addition, for packet layer services these two basic conditions are
complemented by requirements for maximum transfer delay for each of the
active QoS levels and by requirements for in-profile frame/packet loss for
each of the active QoS levels. MEF has created those additional
requirements, and this is resulting in the extension of Ethernet OAM with
proactive delay measurement for multiple QoS levels and proactive frame loss
measurement for multiple QoS levels. 

The result will be that the customer and the service provider can measure
the delay and loss per QoS level.... The logical next step could be that the
service providers/network operators want to prevent that a service does not
meet the per QoS delay/loss values when this service connection is
protected... i.e. protection switching will have to perform a switch under
those type of SD conditions as well. This would imply that the SD condition
becomes the summation of multiple delay and loss defect conditions.

This extension introduces a significant complication of the amount of OAM
processing per MEP. I expect that what is required for Ethernet OAM is also
required for MPLS-TP OAM. I.e. if an Ethernet service is transported over a
MS-PW, it will be a requirement that the MPLS-TP operator can measure the
same degradation conditions as its Ethernet customer. 

Only if an MPLS-TP operator deploys an Ethernet VC layer on top of its
MPLS-TP layers, the operator can use the extended Ethernet OAM for its
service level monitoring and service level protection switching, and in such
case MPLS-TP OAM may not have to support such pro-active per QoS level delay
and loss measurement OAM.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: dinsdag 17 augustus 2010 14:42
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,

> - Limited applicability of SD based on packet loss has been discussed 
> on this

Hmmm. Yes.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 10:15:28 +0200

Ruiquan,

If e.g. a SDH/OTN/ETH PHY in a P-node in the core of a network (e.g. P7)
experiences a SD condition (e.g. on link P6 to P7), and a MS-PW or
MS-service-LSP is protected in its metro-edge S-PE nodes (SPE3 and SPE10),
we need a method to communicate this PHY SD condition from the line port in
P7 to the protection switch (PSW) function in SPE10 (???). This signal has
to pass through P7, SPE8 and P9.

CE1--TPE2--SPE3--P4--SPE5--P6--P7--SPE8--P9--SPE10--TPE11--CE12
           PSW               SD ----???------>PSW

The problem is not only the definition of SD on 1GE and 10GE LAN PHYs, but
also the communication means from e.g. P7 to e.g. SPE10.

Furthermore we would need to specify what to communicate if e.g. two PHY
links (e.g. P6-P7 and SPE8-P9)have an SD condition:

CE1--TPE2--SPE3--P4--SPE5--P6--P7--SPE8--P9--SPE10--TPE11--CE12
           PSW               SD ----???------>PSW
                                       SD --->

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 18 augustus 2010 7:58
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

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.
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, 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, but they are the mainstream interface type on MPLS-TP based
equipments. 

Best regards 
  
Ruiquan Jing 

> I didn't want to get dragged into a discussion of how SD is measured 
> 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 
> does not prohibit switching under other circumstances. Choose how to

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 18 Aug 2010 11:30:40 +0300

Maarten and all,
Please see inline below.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Wednesday, August 18, 2010 10:36 AM
To: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi,

[[[Sasha]]] My reading of this statement is 
"Let's go back to the drawing board and start from scratch, because what we've done so far doesn't hold water". 

I agree with the 2nd part, but I suggest to seriously consider an alternative, namely:
"Let's scrap the concept".

[[[Sasha]]] Just to remind you that packet loss and delay measurements in MPLS-TP also make 
sense only if applied to a specific traffic class within an entity. 
MEF has recognized this fact already; it is high time for the IETF to do the same IMO.

The result will be that the customer and the service provider can measure
the delay and loss per QoS level.... 

[[[Sasha]]]  The missing word is "only": the customer and the service provider
Can ONLY measure the delay and loss per QoS level. And, on top of that, yet another
problem is that split of the customer's traffic  into "service profile-compliant" and
"excessive" components is done (in most cases) by the provider. 
To the best of my recollection, MEF has implicitly recognized this problem long ago 
when it stated that correlation between packet loss measurements done by the customer 
and by the provider is out of scope of its Ethernet Service PM specs.

The logical next step could be that the

[[[Sasha]]] Please see above.

[[[Sasha]]] Sorry, but I've failed to parse this statement. Can you please explain?

Regards,
Maarten

-----Original Message-----

Hi,

Hmmm. Yes.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 11:13:47 +0200

Sasha,

> [[[Sasha]]] Just to remind you that packet loss and delay measurements
> in MPLS-TP also make sense only if applied to a specific traffic class
> within an entity. 

This is what I am pointing at. 
In Ethernet you have to count the frames that per 15-bit PCP+VID, 16-bit
PCP+DEI(0)+VID or 28-bit PCP+DEI(0)+SID value.
In MPLS-TP this would translate into counting the packets per 23-bit
LABEL+TC value.

> MEF has recognized this fact already; it is high time for the IETF to

Is this not the case today?

> [[[Sasha]]]  The missing word is "only": the customer and the service
> provider can ONLY measure the delay and loss per QoS level. 
> And, on top of that, yet another problem is that split of the 
> customer's traffic  into "service profile-compliant" and

This depends on the traffic conditioning capabilities of egress UNI-C ports
in customer equipment. If 802.1Q compliant ports are used, then the clause
8.6.5 function should allow customer edge nodes to mark every frame as
either a "service profile-compliant" (i.e. non-drop eligible) or "excessive"
(i.e. drop eligible) component.

> To the best of my recollection, MEF has implicitly recognized this 
> problem long ago when it stated that correlation between packet
> loss measurements done by the customer and by the provider is out
> of scope of its Ethernet Service PM specs.

It is indeed up to the customer to decide if it would precondition its frame
stream and control which frames are in-profile and out-of-profile. To
measure the amount of lost frames between UNI-C ports, it is necessary that
such UNI-C port includes an Ethernet Down MEP function for the service
instance between the clause 8.6.5 function and the physical interface port.
Did the MEF locate such Eth MEP in its UNI-C port model?

> [[[Sasha]]] Sorry, but I've failed to parse this statement. 

An MPLS-TP network may include as its top layer and Ethernet layer (referred
to as an Ethernet Virtual Channel (VC) layer). Such layer is always included
in MPLS-TP networks that support E-LAN and E-Tree VPLS services for these
RMP and MP2MP services. Such layer could also be used to support P2P E-Line
services. For this latter case, the network can use its UNI-to-UNI Ethernet
OAM to measure the per QoS level in-profile frame loss and per QoS level
frame delay between UNI-N ports. The MS-PW that is started/ended on NNI
ports will not longer be transporting/monitoring the customer Ethernet
service directly. Note that I have seen this approach in multiple networks.
The ethernet PW in such case does not carry the customer ethernet service,
it carries the network ethernet service in which the customer's ethernet
service is encapsulated.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 18 augustus 2010 10:31
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten and all,
Please see inline below.

Regards,
     Sasha

-----Original Message-----
Of Maarten Vissers

Hi,

[[[Sasha]]] My reading of this statement is "Let's go back to the drawing
board and start from scratch, because what we've done so far doesn't hold
water". 

I agree with the 2nd part, but I suggest to seriously consider an
alternative, namely:
"Let's scrap the concept".

[[[Sasha]]] Just to remind you that packet loss and delay measurements in
MPLS-TP also make sense only if applied to a specific traffic class within
an entity. 
MEF has recognized this fact already; it is high time for the IETF to do the
same IMO.

[[[Sasha]]]  The missing word is "only": the customer and the service
provider
Can ONLY measure the delay and loss per QoS level. And, on top of that, yet
another
problem is that split of the customer's traffic  into "service
profile-compliant" and
"excessive" components is done (in most cases) by the provider. 
To the best of my recollection, MEF has implicitly recognized this problem
long ago 
when it stated that correlation between packet loss measurements done by the
customer 
and by the provider is out of scope of its Ethernet Service PM specs.

[[[Sasha]]] Sorry, but I've failed to parse this statement. Can you please
explain?

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 11:21:27 +0200

Neil,

At this point in time I simply try to understand the details associated with
the presented SD proposals. Good or bad, accurate or not accurate
conclusions should be made afterwards in my opinion. 

Note that it is technically possible to **describe** how to transport a PHY
layer's DEG defect (SD) condition in LSPs and PWs from the ingress line port
with the SD condition to any point in the MPLS-TP network and use it there
to control a protection switch action. It would be a new thing, which was
not required before in PDH, SDH and ATM and has not been required in OTN and
Ethernet.

If such solution meets the requirement of the operator community (e.g.
"trigger protection when a physical layer SD is detected along the LSP") and
if it is not adding too much complexity to equipment, then it could be
included in the MPLS-TP standards.

We can discuss the requirement separately from the technical solution to
support this requirement.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 18 augustus 2010 9:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

I would like to think that you have written in here is an attempt to expose
just how daft the proposal to use a server layer network to proxy for the
performance monitoring of a client layer network is.

Your questions 1 and 2 do strongly hint at the problems of both metric
mapping (big problem for co-cs server and co-ps or cl-ps mode clients) and
temporal scaling.  However, this does not consider the problems of layer
ownership by different parties, the fact that we also have a length scaling
problem (ie a E2E path at layer N is only a single link connection at layer
N-1) or the fact that server layer paths cannot pick-up client layer nodal
defects/perf problems

Your questions 3 and 4 should be a massive hint to others in the operator
community just how daft this idea is, eg make them think about things like
*metric* mappings across different network modes.

regards, Neil

> 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.
> 
> threshold THR during M consecutive seconds, with M=2..10 (default 7) 
> and THR=0..100% (default 30%).
> 
> threshold THR during M consecutive seconds, with M=2..10 (default 7) 
> and THR=0..100% (default 15%).
> 
> 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...
> 
> -----------
> 
> 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
> 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..
> 
> Q2: Could you indicate how quickly you would like to see the packet 
> loss ratio degradation detected? E.g.
> 1) 10 seconds
> 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 
> 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.
> 
> 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?
> terminating the physical layer signal,if the BER excede the SD thread, 
> the node should shutdown this port/link. Then send a RDI to it's peer 
> node.  By this way, PW/LSP end- point will detect the port/link down 
> by CC, and then do protection switch.
> 
> Any comments?
> 
> Best regards
>   
> Ruiquan Jing
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 18 Aug 2010 13:34:03 +0300

Maarten,
Lots of thanks for a prompt response. Please see a bit more inline below.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, August 18, 2010 12:14 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Sasha,

> in MPLS-TP also make sense only if applied to a specific traffic class

This is what I am pointing at. [[[Sasha]]]  Great! At least we are on the same wavelength at this point.
... snipped ...

[[[Sasha]]] Depends on how you look at it. Section 5.1 of the latest MPLS-TP Packet Loss and Delay Measurements draft (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay/) is quite unambiguous regarding delay measurements but,
IMHO, a bit vague when it deals with the loss measurements. And of course having multiple measurements per entity requires
a refinement of the SD definition (which, IMHO, is lacking).

[[[Sasha]]] This is technically correct, but, AFAIK, does not match the operational reality.
The customers usually do not mark the traffic they send towards the provider across the UNI as "not compliant"
even if UNI in question allows such marking. One possible explanation is that, would the customer do that,
the provider could simply discard all the traffic that the customer has marked as not compliant
without violating the SLA. 

[[[Sasha]]] Sorry, I cannot answer that without looking up MEF specs. 

[[[Sasha]]] I am not sure, but it seems that these considerations (interworking between MPLS-TP and
Ethernet OAM) have been defined as "out of scope" of the MPLS-TP effort at the IETF.  
Loa/George/Adrian, could one of you please clarify?
Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 18 augustus 2010 10:31
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten and all,
Please see inline below.

Regards,
     Sasha

-----Original Message-----

Hi,

Regards,
Maarten