Subject: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-00

From: [email-masked]
Date: Mon, 8 Mar 2010 10:47:24 +0800

Hi Editors and All,

I have some comments on this draft as below:

1. As I know there are two kinds of defect conditions which may trigger 
AIS transmission:
   a. Signal fail conditions
   b. AIS condition
In this draft only "Signal fail conditions" are mentioned, the "AIS 
condition" which means the condition of receiving AIS message is not 
mentioned. I think it's needed for AIS propagation when more than two 
layers exist and no CC/CV running on intermediate layer, so propose to add 
it with specification.

2. Similar with comment 1, for Lock reporting message transmission there 
are three kinds of triggers:
   a. Administrative Locking Action
   b. Receive Lock Instruction
   c. Lock condition
In this draft only the first one is mentioned, propose to add the last two 
triggers.

3. In section 1 three classes of service disruptive conditions "Defect, 
Fault and Lock" are identified, and three messages "AIS, LDI and LKR" are 
defined accordingly. IMO it's not necessary to distinguish "LDI" from 
"AIS", the only LDI purpose I can imagine is to trigger immediate 
protection switching on client layer, but there is already hold-off timer 
which can be used to trigger protection switching on client layer. Propose 
to combine "defect" with "fault" and remove "LDI" if no other 
consideration.

Best Regards,
Xiao Min

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Mar 2010 08:58:31 +0100

Hi Xiao,
 
See inline...

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 8 maart 2010 3:47
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-00

Hi Editors and All, 

1. As I know there are two kinds of defect conditions which may trigger AIS
transmission: 
   a. Signal fail conditions 
   b. AIS condition 
In this draft only "Signal fail conditions" are mentioned, the "AIS
condition" which means the condition of receiving AIS message is not
mentioned. I think it's needed for AIS propagation when more than two layers
exist and no CC/CV running on intermediate layer, so propose to add it with
specification. 
 
[maarten] I agree with you that there is a need to generate AIS in a MEP
Sink function under the following condition: the CC/CV process is disabled
in the MEP source function for this PW/LSP and an AIS or LCK defect is
detected by the MEP Sink function.
 
2. Similar with comment 1, for Lock reporting message transmission there are
three kinds of triggers: 
   a. Administrative Locking Action 
   b. Receive Lock Instruction 
   c. Lock condition 
In this draft only the first one is mentioned, propose to add the last two
triggers.  
 
[maarten] I do not agree with you on this item. Only the administrative Lock
action is allowed to generate LCK message. If CC/CV is active on the PW/LSP
that is being locked at an intermediate point along the LSP/PW, then the MEP
Sink function at the end of the LSP/PW iwll detect loss of CC and this will
resutl in AIS insertion. The detection of an incoming LCK message will
suppress the loss of CC failure/alarm and instead present a LCK
failure/alarm. 

3. In section 1 three classes of service disruptive conditions "Defect,
Fault and Lock" are identified, and three messages "AIS, LDI and LKR" are
defined accordingly. IMO it's not necessary to distinguish "LDI" from "AIS",
the only LDI purpose I can imagine is to trigger immediate protection
switching on client layer, but there is already hold-off timer which can be
used to trigger protection switching on client layer. Propose to combine
"defect" with "fault" and remove "LDI" if no other consideration.  
 
[maarten] I agree with you that LDI must be deleted from the set. See also
my responses on the original draft. I do not agree that defect and fault can
be merged. A Fault represents a condition in the network, which results in
anomalies in the transport, which result in detection of a defect.
 
Regards,
Maarten 

Best Regards, 
Xiao Min

---

From: [email-masked]
Date: Tue, 9 Mar 2010 10:34:16 +0800

Please see inline.

Maarten Vissers <[email-masked]> 
2010-03-08 15:58

收件人
[email-masked], [email-masked], [email-masked], 
[email-masked]
抄送
[email-masked]
主题
RE: [mpls-tp]  Comments on draft-ietf-mpls-tp-fault-00

Hi Xiao,
 
See inline...

Hi Editors and All, 

 

<Xiao Min> I agree. We describe the same condition with different words.

[maarten] I do not agree with you on this item. Only the administrative 
Lock action is allowed to generate LCK message. If CC/CV is active on the 
PW/LSP that is being locked at an intermediate point along the LSP/PW, 
then the MEP Sink function at the end of the LSP/PW iwll detect loss of CC 
and this will resutl in AIS insertion. The detection of an incoming LCK 
message will suppress the loss of CC failure/alarm and instead present a 
LCK failure/alarm. 

<Xiao Min> I think LKR propagation is also needed as AIS propagation under 
the condition described in comment 1.

[maarten] I agree with you that LDI must be deleted from the set. See also 
my responses on the original draft. I do not agree that defect and fault 
can be merged. A Fault represents a condition in the network, which 
results in anomalies in the transport, which result in detection of a 
defect.

<Xiao Min> I agree with you that "A Fault represents a condition in the 
network", but I think it's unnecessary to differentiate them in *this* 
draft and it may be processed in protection draft.
 
Regards,
Maarten 

Best Regards, 
Xiao Min