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

From: "Shahram Davari" <[email-masked]>
Date: Tue, 1 Mar 2011 11:54:57 -0800

Hi,

I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs. Transport networks don't need to change the rates and are mostly static. Also Poll/Final will most likely require extra Software in addition to HW, which can increase complexity and cost for MPLS-TP operation.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Thursday, February 10, 2011 6:38 AM
To: David Allan I
Cc: [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,
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,
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

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

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.

>6. Section 3.5.5

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

Good catch. Will fix

Cheers
Dave

> -----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,
> 
> 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 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Mar 2011 12:29:52 -0800

Dear Shahram, Sasha and All,
I support current wording of the first para in Section 3.5. to address
Sasha's concern regarding distinguishing MPLS CC message from BFD over VCCV
per RFC 5885 the last sentence might be changed to like:
"Poll/final discipline can be only used for VCCV and UDP/IP encapsulated BFD
when using unique appropriate Associated Channel type."
I believe that lately there was sufficient discussion about compatibility of
BFD-based CC OAM and BFD over VCCV. AFAIK, there's no requirement to support
backward compatibility and that might be stated in the document.

Regards,
Greg

On Tue, Mar 1, 2011 at 11:54 AM, Shahram Davari <[email-masked]> wrote:

> Hi,
>
> I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs.
> Transport networks don't need to change the rates and are mostly static.
> Also Poll/Final will most likely require extra Software in addition to HW,
> which can increase complexity and cost for MPLS-TP operation.
>
> Regards,
> Shahram
>
> 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.
>
> 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
>
> >"1. BFD control packets are received with an unexpected encapsulation
> (mis-connectivity defect), these include:
> >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.
>
> >" 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
> >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
> >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.
>
> >6. Section 3.5.5
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 2 Mar 2011 15:36:54 +0200

Shahram and all,
Please see some comments inline below.

Regards,
     Sasha

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2011 9:55 PM
> To: Alexander Vainshtein; David Allan I
> I would like to support the disabling of Poll/Final for MPLS-TP LSP
> BFDs. Transport networks don't need to change the rates and are mostly
> static. 
[[[Sasha]]] There are two different statements here IMO:

1. "Transport networks do not have to change the rates".
   Sounds very much like "transport networks are always single-vendor" to me.
   Because in a multi-vendor environment you have to deal with different rate ranges
   And have from time to time manipulate these rates...

2. "Transport networks are mostly static".
   I do not really understand how this is related to the subject.  

Also Poll/Final will most likely require extra Software in
> addition to HW, which can increase complexity and cost for MPLS-TP
> operation.
[[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the operators.
And the vendors who have implemented Poll/Final will have to go into 
new development and support two different BFD state machines... if this is not expensive, what is?
> 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.
> 
> 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
> 
> >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.
> 
> >" 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.
> 
> 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
> >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
> 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.
> 
> >6. Section 3.5.5
>