Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

From: Loa Andersson <[email-masked]>
Date: Thu, 03 Feb 2011 15:13:49 +0100

Working Group,

this is to start a four week working group last call on
"Proactive Connectivity Verification, Continuity Check and
Remote Defect indication for MPLS Transport Profile"
(draft-ietf-mpls-tp-cc-cv-rdi-03.txt).

Please send comments to the [email-masked] mailing list.

This working group last call ends on February 28, 2011.

Loa, George and Ross

MPLS wg co-chairs
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Mach Chen <[email-masked]>
Date: Thu, 10 Feb 2011 11:44:35 +0800

Dear authors,

I read the draft, here are some comments, please consider:

1.Section 3.5, last sentence of first paragraph

"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD."
There is a "be" lost between "can" and "only".

2.Section 3.5.2
"1. BFD control packets are received with an unexpected encapsulation
(mis-connectivity defect), these include: 
          - a PW receiving a packet with a GAL", Since GAL can be used for
PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), this
should not be a defect. Suggest to remove it.

3 Section 3.5.2
" 4. Receipt of an expected session discriminator with an unexpected label
(mis-connectivity defect).", For a receiver, how does it know that the
session discriminator is valid but the label is invalid? IMHO, this defect
is just another description of defect 3 . Suggest to remove it.

4.Section 3.5.4.2
" Exit from a misconfiguration defect occurs when two consecutive CC or CV
frames have been received with the expected M bit setting." IMHO, this
sentence is little bit vague, and since this draft only defines for P2P LSP,
why not just say "...with M bit clear."

5. Section 3.5.4.3
"Exit from a mis-connectivity defect state occurs when no CV messages have
been received with an incorrect source MEP-ID for a period of 3.5 seconds.",
since there are several defects listed in Section 3.5.2 and this is only one
condition for exiting from a mis-connectivity defect state. How about "Exit
from a mis-connectivity defect state occurs when no CV messages with
mis-connectivity defects have been received for a period of 3.5 seconds "

6. Section 3.5.5

In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state.

Best regards,
Mach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: Thursday, February 03, 2011 10:14 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03
> 
> Working Group,
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: David Allan I <[email-masked]>
Date: Thu, 10 Feb 2011 06:08:35 -0500

Hi Mach: 

Thanks for the review

>There is a "be" lost between "can" and "only".

Good catch, will fix.

>2.Section 3.5.2
>"1. BFD control packets are received with an unexpected encapsulation (mis-connectivity defect), these include: 
>          - a PW receiving a packet with a GAL", Since GAL can be used 
>for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), this should not be a defect. Suggest to remove it.

We'll review and edit accordingly.

>3 Section 3.5.2
>" 4. Receipt of an expected session discriminator with an unexpected label (mis-connectivity defect).", For a receiver, how does it know that the session >discriminator is valid but the label is invalid? IMHO, this defect is just another description of defect 3 . Suggest to remove it.

If the session discriminator exists in the BFD database, it is superficially a valid descriminator but the label of arrival can be incorrect. This may indicate an implementation problem at the source MEP. What we were referring to in '3' was a session discriminator that did not exist in the local database, BFD had never handed it out hence it could not be found.

>4.Section 3.5.4.2
>" Exit from a misconfiguration defect occurs when two consecutive CC or 
>CV frames have been received with the expected M bit setting." IMHO, this sentence is little bit vague, and since this draft only defines for P2P LSP, why not just say "...with M bit clear."

OK

>5. Section 3.5.4.3
>"Exit from a mis-connectivity defect state occurs when no CV messages 
>have been received with an incorrect source MEP-ID for a period of 3.5 seconds.", since there are several defects listed in Section 3.5.2 and this is only one condition for exiting from a mis-connectivity defect state. How about "Exit >from a mis-connectivity defect state occurs when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds "

That seems to be more accurate, I'd replace "with...." with "indicating an on-going mis-connectivity defect has been....". Simply wordsmithing.

>In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state.

Good catch. Will fix

Cheers
Dave

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> this is to start a four week working group last call on "Proactive 
> Connectivity Verification, Continuity Check and Remote Defect 
> indication for MPLS Transport Profile"

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Feb 2011 13:36:25 +0200

Dave and all,
I'd like to remind you that Rob and I have already questioned the decision to change the BFD state machine by disabling in some case the Poll/Final sequence.

The situation as presented in the draft seems to introduce even more problems. 
E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but follows the procedures specified in RFC 5880 and 5881 which, to the best of my understanding, include usage of Poll/Final sequence.

It is my understanding that BFD for an MPLS-TP LSP would look exactly as BFD in VCCV (including the same code point).
If this is correct, how should the implementation distinguish between "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they seem to be prohibited?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Thursday, February 10, 2011 1:09 PM
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Mach: 

Thanks for the review

Good catch, will fix.

OK

Good catch. Will fix

Cheers
Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Feb 2011 16:38:20 +0200

Dave, and all,
To avoid any misinterpretation, please consider the original email as my LC comment.

Regards,
     Sasha

-----Original Message-----
From: Alexander Vainshtein 
Sent: Thursday, February 10, 2011 1:36 PM
To: 'David Allan I'
Cc: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; Robert Rennison
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Dave and all,

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Thursday, February 10, 2011 1:09 PM
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Mach: 

Thanks for the review

Good catch, will fix.

OK

Good catch. Will fix

Cheers
Dave

---

From: Mach Chen <[email-masked]>
Date: Fri, 11 Feb 2011 16:11:56 +0800

Hi Dave,

Thanks for your prompt response!

> session >discriminator is valid but the label is invalid? IMHO, this
defect is just
> another description of defect 3 . Suggest to remove it.
> 
> If the session discriminator exists in the BFD database, it is
superficially a valid
> descriminator but the label of arrival can be incorrect. This may indicate
an
> implementation problem at the source MEP. What we were referring to in '3'
> was a session discriminator that did not exist in the local database, BFD
had
> never handed it out hence it could not be found.
> 

OK, but more clarification text would be helpful.

Best regards,
Mach

---

From: David Allan I <[email-masked]>
Date: Fri, 11 Feb 2011 05:11:40 -0500

OK, will do...

Dave 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

defect is just
superficially a valid
an
had

Best regards,
Mach

---

From: "HUANG Feng F" <[email-masked]>
Date: Thu, 17 Feb 2011 00:42:50 +0800

Dear Dave,
     In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is defined without MEG, how to detect Mismerge?
     And BFD protocol is enabled for period negotiation, when period is different, lower one is used, then how to detection Uexpect period?
B.R.
Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: 2011年2月11日 18:12
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]]
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

defect is just
superficially a valid
an
had

Best regards,
Mach

---

From: David Allan I <[email-masked]>
Date: Wed, 16 Feb 2011 11:50:37 -0500

HI Feng:

See section 7.1 of http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-03 . IMO it is simply a terminology issue as to whether a MEG is encoded in the LSP and PW formats or not.

Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation is not used. So unexpected period occurs when one end unpexpectedly changes the period advertised.

I hope this helps
Dave 

-----Original Message-----
From: HUANG Feng F [mailto:[email-masked]] 
Sent: Wednesday, February 16, 2011 5:43 PM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

 Dear Dave,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: 2011年2月11日 18:12
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]]
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

defect is just
superficially a valid
an
had

Best regards,
Mach

---

From: "HUANG Feng F" <[email-masked]>
Date: Thu, 17 Feb 2011 14:27:12 +0800

Hi,Dave,
     Thanks, LSP MEP ID in draft-ietf-mpls-tp-identifiers-03 is: Node_ID::Tunnel_Num::LSP_Num,  

and for LSP MEG ID: (7.1.2.1.)
    Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs
   for MPLS-TP LSPs are simply the corresponding LSP_IDs.  We note that
   while the two identifiers are syntactically identical, they have
   different semantics.  This semantic difference needs to be made
   clear.  For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs
   are to be encoded in TLVs different types need to be assigned for
   these two identifiers.
 
you can only detect wrong MEP ID, that's Unexpected MEP, it is not Mis-merge.

If period negotiation is not used, how to insure interoperability with BFD used in IP/MPLS asked always by providers?

B.R.
Feng

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: 2011年2月17日 0:51
To: HUANG Feng F; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03

HI Feng:

I hope this helps
Dave 

-----Original Message-----
From: HUANG Feng F [mailto:[email-masked]]
Sent: Wednesday, February 16, 2011 5:43 PM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

 Dear Dave,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: 2011年2月11日 18:12
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]]
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

defect is just
superficially a valid
an
had

Best regards,
Mach

---

From: David Allan I <[email-masked]>
Date: Thu, 17 Feb 2011 03:01:34 -0500

Hi Feng:

I'm not sure how unexpected MEP is not indicative of a mismerge. Either the source MEP ID has been misconfigured, or you are receiving a message from a MEP due to LIB corruption or similar defect somewhere in the network. 

As for your second point, it is not that negotiation is not used, there is simply no give and take allowed, so the procedures are simply modified slightly in the TP case . If the far end refuses to support the requested periodicity for whatever reason, you do not progress beyond the INIT state and presumably send some indication to management that the session could not come "UP". You have that option whether you are conformant to CC-CV-RDI draft or simply RFC 5884. So as far as I can tell interoperability options exist, they were always there in the protocol, we are simply providing implementation guidelines for the TP application...

I hope this helps
Dave

-----Original Message-----
From: HUANG Feng F [mailto:[email-masked]] 
Sent: Thursday, February 17, 2011 7:27 AM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03

Hi,Dave,

B.R.
Feng

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: 2011年2月17日 0:51
To: HUANG Feng F; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03

HI Feng:

I hope this helps
Dave 

-----Original Message-----
From: HUANG Feng F [mailto:[email-masked]]
Sent: Wednesday, February 16, 2011 5:43 PM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

 Dear Dave,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: 2011年2月11日 18:12
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]]
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

defect is just
superficially a valid
an
had

Best regards,
Mach