Subject: [mpls-tp] some comments about draft-ietf-mpls-tp-cc-cv-rdi-02

From: [email-masked]
Date: Fri, 12 Nov 2010 09:40:05 +0800

Hi editors:
  I have some comments for this draft below:

1. The title of the draft is not according to the order of cc, cv, rdi, 
suggest you to adjust them.

2. These three OAM functions should all support section, but most of the 
draft contents only talks about LSP or PW, not talking about section. I 
suggest to mention at the begin of this draft that later contents also 
apply to section to make clear.

3. The RDI mechanisms introduction in the Abstract and Introduction of 
section 1 is not consistent. In Abstract uses "End point and its 
associated End point", in section 1 uses "MEP and its peer MEP". So I 
suggest all to use the latter one.

4. The last paragraph of section 3.1 has introduced a new mechanism to 
simultaneously employ the cc and cv operation. I think it is good, but 
still needs more details, such as if cv packet is also count for one cc 
packet for the LOC? and some contents about configuration, etc. I think it 
will make this mechanism more clear for others.

5. Continuing my question in the IETF MPLS session, I am still not clear 
why we can not establish the exist criteria of mis-connectivity defect by 
configuring the period of cv packet or the "n" number in the sink MEP? 
Hope for your more detailed explanation.

6. BTW, What's your next plan for supporting the cc and cv for 
unidirectional path?

Thanks very much!

B.R.
Liang

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: David Allan I <[email-masked]>
Date: Thu, 11 Nov 2010 20:58:36 -0500

HI Xia:

Responses in line:

1. The title of the draft is not according to the order of cc, cv, rdi, suggest you to adjust them.

OK

2. These three OAM functions should all support section, but most of the draft contents only talks about LSP or PW, not talking about section. I suggest to mention at the begin of this draft that later contents also apply to section to make clear.

OK

3. The RDI mechanisms introduction in the Abstract and Introduction of section 1 is not consistent. In Abstract uses "End point and its associated End point", in section 1 uses "MEP and its peer MEP". So I suggest all to use the latter one.

Agreed.

4. The last paragraph of section 3.1 has introduced a new mechanism to simultaneously employ the cc and cv operation. I think it is good, but still needs more details, such as if cv packet is also count for one cc packet for the LOC? and some contents about configuration, etc. I think it will make this mechanism more clear for others.

Yes a CV packet counts as CC for LOC. You are not the first to ask this question, so we will make it clearer in the next draft.

5. Continuing my question in the IETF MPLS session, I am still not clear why we can not establish the exist criteria of mis-connectivity defect by configuring the period of cv packet or the "n" number in the sink MEP? Hope for your more detailed explanation.

IF we use a ubiquitous minimum CV insertion rate network wide, then we can establish an exit criteria which is: a misconnected CV PDU was not received in 3.5 times the minimum CV insertion rate. If the minimum rate is not known, then the exit criteria  becomes arbitrary, will not be reliable and mis-connectivity defect can flap.

My point was that the PDU will not self identify the CV insertion rate, and for off line configuration a sink MEP cannot know the CV insertion rate for ALL source MEPs, such that it can tailor the exit criteria to the misbranching ME. Therefore either a universal minimum rate is required, or we cannot define exit criteria and would need manual intervention to reset the MEP.

6. BTW, What's your next plan for supporting the cc and cv for unidirectional path?

We are following the progress of reviving the p2mp BFD draft in the BFD WG. We are of the understanding that work is being "dusted off" and would like to aign with it.

Thanks very much!

you're welcome
Dave

---

From: [email-masked]
Date: Fri, 12 Nov 2010 10:32:24 +0800

Hi editors:
  Thanks very much for your promptly reponse~~
  my reponses for the question 5 in line:

B.R.
Liang

David Allan I <[email-masked]> 写于 2010-11-12 09:58:36:

> 2. These three OAM functions should all support section, but most of
> the draft contents only talks about LSP or PW, not talking about 
> section. I suggest to mention at the begin of this draft that later 
> contents also apply to section to make clear. 
> 
> OK 
> 
> 3. The RDI mechanisms introduction in the Abstract and Introduction 
> of section 1 is not consistent. In Abstract uses "End point and its 
> associated End point", in section 1 uses "MEP and its peer MEP". So 
> I suggest all to use the latter one. 
> 
> Agreed. 
> 
> 4. The last paragraph of section 3.1 has introduced a new mechanism 
> to simultaneously employ the cc and cv operation. I think it is 
> good, but still needs more details, such as if cv packet is also 
> count for one cc packet for the LOC? and some contents about 
> configuration, etc. I think it will make this mechanism more clear for 
others.
> 
> Yes a CV packet counts as CC for LOC. You are not the first to ask 
> this question, so we will make it clearer in the next draft. 
> 
> 5. Continuing my question in the IETF MPLS session, I am still not 
> clear why we can not establish the exist criteria of mis-
> connectivity defect by configuring the period of cv packet or the 
> "n" number in the sink MEP? Hope for your more detailed explanation. 
> 
> IF we use a ubiquitous minimum CV insertion rate network wide, then 
> we can establish an exit criteria which is: a misconnected CV PDU 
> was not received in 3.5 times the minimum CV insertion rate. If the 
> minimum rate is not known, then the exit criteria  becomes 
> arbitrary, will not be reliable and mis-connectivity defect can flap.
> 

[Liang] If you use a ubiquitous minimum CV insertion rate network wide, 
there are other problems exist for all the CV rate bigger than this 
minimum CV rate, they will exit the mis-connectivity defect in advance but 
in fact still be in the defect condition.

> My point was that the PDU will not self identify the CV insertion 
> rate, and for off line configuration a sink MEP cannot know the CV 
> insertion rate for ALL source MEPs, such that it can tailor the exit
> criteria to the misbranching ME. Therefore either a universal 
> minimum rate is required, or we cannot define exit criteria and 
> would need manual intervention to reset the MEP.
>

[Liang]What's your mean about the All source MEPs? Isn't there only one 
source MEP for a p2p bidirectional BFD session sink MEP? And what's the 
mean of "it can tailor the exit criteria to the misbranching ME"?

> We are following the progress of reviving the p2mp BFD draft in the 
> BFD WG. We are of the understanding that work is being "dusted off" 
> and would like to aign with it. 
> 
> Thanks very much! 
> 
> you're welcome
> Dave 
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: David Allan I <[email-masked]>
Date: Thu, 11 Nov 2010 21:46:28 -0500

HI Liang

A misconnectivity fault is detected when CV PDUs from one source MEP appear at an unexpected sink MEP due to some misconfiguration of forwarding in the network. The set of source MEPs that could somehow be cross connected to an incorrect sink MEP COULD be quite large. That is what I meant by "all the source MEPs". An ME has only one correct source MEP, but can have many incorrect ones...

Now if there is a minimum insertion rate e.g. 1/sec, then a sink MEP needs to be clean for 3.5 secs. IF there are nodes inserting CV slower than every second then they would be non-compliant and yes we would have problems. Cannot avoid that.

I hope this helps
Dave

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 9:32 PM
To: David Allan I
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: 答复: RE: some comments about draft-ietf-mpls-tp-cc-cv-rdi-02

Hi editors:

B.R.
Liang

David Allan I <[email-masked]> 写于 2010-11-12 09:58:36:

> configuration, etc. I think it will make this mechanism more clear for others.
>

[Liang] If you use a ubiquitous minimum CV insertion rate network wide, there are other problems exist for all the CV rate bigger than this minimum CV rate, they will exit the mis-connectivity defect in advance but in fact still be in the defect condition.

> would need manual intervention to reset the MEP.

[Liang]What's your mean about the All source MEPs? Isn't there only one source MEP for a p2p bidirectional BFD session sink MEP? And what's the mean of "it can tailor the exit criteria to the misbranching ME"?