Subject: Re: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03

From: Maarten vissers <[email-masked]>
Date: Fri, 05 Aug 2011 13:09:22 +0000

Hi Suhui,

Please see inline…

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: 1 August 2011 09:10
To: Maarten vissers
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: 答复: RE: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03

Hi Maarten，
Please see the online….

Regards，
Suhui

Maarten vissers <[email-masked]<mailto:[email-masked]>>

2011-07-29 20:24

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

RE: [mpls] 答复: Re:  Comments to draft-rkhd-mpls-tp-sd-03

Suhui,

Your solution does not meet the requirement to prevent entering UAT in protected transport service layer connections under packet loss conditions; i.e. packet loss due to non bit error conditions is not taken care of. Customer will still complain and will ask his/her money back in such case :(.
[SH] There are there reasons which can cause SD: fiber defect, congestion, equipment defect. This mechanism can only deal with the first reason. Someone told me that more than 90% failure are cause by fiber defect and power defect(maybe some carriers can give us more accurate number), and it is impossible to detect SD caused by congestion or equipment defect if no packet is transmitting, so if there is no other better solution, this is good enough for me.
[MV] Bottom line question is if protection switching on Physical layer SD (=dDEG) condition should prevent service to enter UAT. If it is allowed to prevent entering UAT only for ~90% of packet loss cases then your proposed trigger condition might be good enough. But this needs to be agreed first.

An FEI adds much more than just another maintenance signal type of OAM packet. It may require changes to OTN devices (i.e. concerning processing of bit error information and consequent actions) and changes to MPLS-TP devices (i.e. concerning processing of packet loss information and consequent actions).
[SH] Yes, if one adds a type of packet, one must generate/receive this packet. But since the mechanism is the same as FDI, it does not add much work.
[MV] Changes to existing hardware and software are not appreciated if they do not completely resolve the issue.

FEI propagation is not the same as FDI/AIS propagation.
-          Default FDI/AIS propagation is based on detection of local CC/CV defect in MEP Sink which controls insertion of FDI/AIS into client layer signal (PW, service-LSP, transport-LSP) or into client TCM level (PSME).
Only if MEP Sink is configured not to perform CC/CV defect detection it is necessary to use FDI/AIS defect to control insertion of FDI/AIS; this is only necessary at transport service layer MEP functions when SLA does not require pro-active fault monitoring. Now it will be necessary to generate FDI/AIS in the customer’s signal based on detected AIS defect.
-          FEI propagation always requires forwarding of  incoming FEI information; i.e. FEI OAM is terminated, FEI information is extracted and inserted into client FEI OAM packet(s). There may be multiple FEI OAM packets incoming every second (one from every physical layer link passed; i.e. every second more than one FEI OAM packet may have to be inserted into the client layer or client PSME signal. See figure below.
[SH] I do not see there is any difference between FEI propagation and FDI propagation.
For FDI :  A MEP receives a FDI packet or detects failure by other OAM , then it enters TSF condition, then consequent actions of TSF condition will insert FDI packet in its client layer.
For FEI:  A MEP receives a FEI packet, then it enters TSD condition, then consequent actions of TSD condition will insert FEI packet in its client layer. A MEP only inserts one packet in one second in each client no matter how much FEI packets it receives.
[MV] The FEI propagation method you describe is not able to accumulate packet loss along a multi-segment path. E.g. if the connection (PW, LSP, PSME) consists of 10 segments and each segment has e.g. a 1E-7 error rate then the total connection would have a 1E-6 error rate. If 1E-6 would be the trigger for a packet SD condition, then you will not reach that with your solution, but you would get to that with the solution I described. What you describe is a very much simplified version, which can be described as: if one or more of the physical links detects a Degraded defect, then the packet SD condition will be declared.

Regards,
Maarten

Regards,
Maarten

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 7 Aug 2011 09:23:16 +0300

Hi Marteen,

Regarding your last comment, pls note that the last SD draft revision includes support for the scenario you describe (error rate in each link below the SD threshold and end-to-end error rate path above the threshold) – see section 5.1.

Daniel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten vissers
Sent: Friday, August 05, 2011 4:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03

Hi Suhui,

Please see inline…

From: [email-masked] [mailto:[email-masked]] 
Sent: 1 August 2011 09:10
To: Maarten vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: 答复: RE: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03

Hi Maarten， 
Please see the online…. 

Regards， 
Suhui 

Maarten vissers <[email-masked]> 

2011-07-29 20:24 

收件人

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 

主题

		

Suhui, 
  
Your solution does not meet the requirement to prevent entering UAT in protected transport service layer connections under packet loss conditions; i.e. packet loss due to non bit error conditions is not taken care of. Customer will still complain and will ask his/her money back in such case L. 
[SH] There are there reasons which can cause SD: fiber defect, congestion, equipment defect. This mechanism can only deal with the first reason. Someone told me that more than 90% failure are cause by fiber defect and power defect(maybe some carriers can give us more accurate number), and it is impossible to detect SD caused by congestion or equipment defect if no packet is transmitting, so if there is no other better solution, this is good enough for me.

Regards,

Maarten

Regards, 
Maarten