Subject: [mpls] MPLS-TP CC-CV-RDI

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 11 Apr 2011 18:51:22 +0200

Dear authors,

Slide 14 of the attached, says that "This document an enhancement to RFC
5884/5885....But it still requires two new code points as it will not be
perfectly backwards compatible...."

http://tools.ietf.org/agenda/80/slides/mpls-9.pdf

It is my understanding that the extension done to BFD is completely
compatible with BFD. 

Can you please clarify this point? Is the solution being defined in
draft cc-cv-rdi is compatible with BFD? 

Is it also possible for CC-CV-RDI and existing BFD to be compatible
today given only the proper configuration?

Best regards,

Nurit

---

From: David Allan I <[email-masked]>
Date: Mon, 11 Apr 2011 18:08:16 -0400

Hi Nurit

It is backwards compatible in the sense that the new code points allow the additional  behaviors specified for MPLS TP to be disambiguated from existing RFC 5884/5 behaviors
    - this is the addition of the GAL, the source MEP TLV, interleaving of CC and CV PDUs, and accepting the TP-FAULT inputs as valid state machine inputs.

It is not perfectly backwards compatible in that the addition of the GAL and new code points means deployed implementations will not support the new encap and TLV without an upgrade .... RFC 5885 is close but not an exact match due to the addition of the Source MEP ID TLV. Some implementation tweaks are required.

hope this helps
Dave

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Sent: Monday, April 11, 2011 9:51 AM
To: David Ward; David Allan I; John E Drake; Nitin Bahadur
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; Schink, Helmut (NSN - DE/Munich)
Subject: MPLS-TP CC-CV-RDI

Dear authors,

Slide 14 of the attached, says that "This document an enhancement to RFC 5884/5885....But it still requires two new code points as it will not be perfectly backwards compatible...."

http://tools.ietf.org/agenda/80/slides/mpls-9.pdf
It is my understanding that the extension done to BFD is completely compatible with BFD.
Can you please clarify this point? Is the solution being defined in draft cc-cv-rdi is compatible with BFD?
Is it also possible for CC-CV-RDI and existing BFD to be compatible today given only the proper configuration?
Best regards,
Nurit

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 11 Apr 2011 23:27:51 -0400

In message <[email-masked]>
David Allan I writes:
>  
> Hi Nurit
>  
> It is backwards compatible in the sense that the new code points allow
> the additional  behaviors specified for MPLS TP to be disambiguated
> from existing RFC 5884/5 behaviors
>  
>     - this is the addition of the GAL, the source MEP TLV,
>       interleaving of CC and CV PDUs, and accepting the TP-FAULT
>       inputs as valid state machine inputs.
>  
> It is not perfectly backwards compatible in that the addition of the
> GAL and new code points means deployed implementations will not
> support the new encap and TLV without an upgrade .... RFC 5885 is
> close but not an exact match due to the addition of the Source MEP ID
> TLV. Some implementation tweaks are required.

The usual way to handle an extension to an existing protocol is to use
a capability negotiation, not assign a new code point.

> Slide 14 of the attached, says that "This document an enhancement to
> RFC 5884/5885....But it still requires two new code points as it will
> not be perfectly backwards compatible...." 
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 12 Apr 2011 07:58:23 +0200

Hi David,

Thanks for your response.

In the IETF we define protocols, so I believe it would be correct to say
that the extension to the BFD protocol is fully compatible with BFD. 

Best regards,

Nurit

From: ext David Allan I [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 1:08 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake;
Nitin Bahadur
Cc: [email-masked]; Schink, Helmut (NSN - DE/Munich)
Subject: RE: MPLS-TP CC-CV-RDI

Hi Nurit

It is backwards compatible in the sense that the new code points allow
the additional  behaviors specified for MPLS TP to be disambiguated from
existing RFC 5884/5 behaviors

    - this is the addition of the GAL, the source MEP TLV, interleaving
of CC and CV PDUs, and accepting the TP-FAULT inputs as valid state
machine inputs.

It is not perfectly backwards compatible in that the addition of the GAL
and new code points means deployed implementations will not support the
new encap and TLV without an upgrade .... RFC 5885 is close but not an
exact match due to the addition of the Source MEP ID TLV. Some
implementation tweaks are required. 

hope this helps

Dave

From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: Monday, April 11, 2011 9:51 AM
To: David Ward; David Allan I; John E Drake; Nitin Bahadur
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; Schink,
Helmut (NSN - DE/Munich)
Subject: MPLS-TP CC-CV-RDI

Dear authors,

Best regards,

Nurit

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Apr 2011 10:25:11 +0300

Nurit and all,

A couple of additional points.

 1.  Dropping the Poll/Final scheme has been shown to be highly problematic both per se (e.g. due to potential false LOC detection immediately after the end points have been configured, especially if the detection interval is very short) and when it comes to interoperability with the existing implementations (e.g., if they use the BFD slow start as defined in RFC 5880 in order to program HW accelerators that would take care of BFD at the desired high rate). This has been discussed during the Prague meeting (both at the mike and in private talks with Dave), and still has to be resolved.
 2.  IMHO the user that is only interested in proactive and fast CC/RDI (but not in proactive CV) could safely run BFD over GAL/G-ACh using the code point and procedures defined in RFC 5885 (which in its turn assumes the procedures defined in 5880) "as is". In order to provide a backward compatible solution, this option should be explicitly specified in the draft, preferably as MUST to implement.
 3.  Proactive CV as defined in the draft definitely needs a new code point because it relies on a Source MEP ID TLV as the G-ACh TLV, and these TLVs are or are not expected by the receiver based on the G-ACh type. So it will not be backward compatible with the existing implementations, and this fact MUST be explicitly spelled out in the draft.

My 2c,

     Sasha

From: [email-masked] [[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Tuesday, April 12, 2011 8:58 AM
To: ext David Allan I; David Ward; John E Drake; Nitin Bahadur
Cc: [email-masked]; Schink, Helmut (NSN - DE/Munich)
Subject: Re: [mpls] MPLS-TP CC-CV-RDI

Hi David,
Thanks for your response.
In the IETF we define protocols, so I believe it would be correct to say that the extension to the BFD protocol is fully compatible with BFD.
Best regards,
Nurit

To: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Nitin Bahadur

Hi Nurit

hope this helps
Dave

---

From: David Allan I <[email-masked]>
Date: Tue, 12 Apr 2011 10:17:08 -0400

Agreed, but that would require redesigning BFD. The other alternative would be to use the version number.

As we had a simultaneous change of encapsultion with the GAL/G-ACh as well as the need for additional features, the code point seemed to make sense.

Thanks
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 11, 2011 8:28 PM
To: David Allan I
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Nitin Bahadur; [email-masked]; Schink, Helmut (NSN - DE/Munich)
Subject: Re: [mpls] MPLS-TP CC-CV-RDI 

> TLV. Some implementation tweaks are required.

The usual way to handle an extension to an existing protocol is to use a capability negotiation, not assign a new code point.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Apr 2011 17:19:53 +0300

Dave,
Raw BFD encapsulation over G-ACh has been already defined in RFC 5885.
GAL does not really add anything to this encapsulation IMO, simply allows to use G-ACh on top of LSPs and not just PWs.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Allan I
> Sent: Tuesday, April 12, 2011 5:17 PM
> To: [email-masked]
> Cc: [email-masked]; David Ward; Schink, Helmut (NSN - DE/Munich)
> As we had a simultaneous change of encapsultion with the GAL/G-ACh as
> well as the need for additional features, the code point seemed to make
> sense.
> 
> Thanks
> Dave
> 
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake;
> Nitin Bahadur; [email-masked]; Schink, Helmut (NSN - DE/Munich)
> In message
> <[email-masked]
> .se>
> David Allan I writes:
> >
> > Hi Nurit
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: David Allan I <[email-masked]>
Date: Tue, 12 Apr 2011 10:25:40 -0400

There is a few semantic differences over 5885 unique to MPLS-TP....

1) Interleave of CC and CV.
2) The additional mis-connectivity logic implied by CV 
3) The additional transactions in TP-FAULT are valid inputs.

And a couple of other things meant that BFD for TP could not be supported by a vanilla 5885 implementation.

Hope this helps
Dave

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 7:20 AM
To: David Allan I
Cc: [email-masked]; David Ward; Schink, Helmut (NSN - DE/Munich); [email-masked]
Subject: RE: [mpls] MPLS-TP CC-CV-RDI

Dave,

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of David Allan I
> well as the need for additional features, the code point seemed to 
> make sense.
> 
> Thanks
> Dave
> 
> > close but not an exact match due to the addition of the Source MEP 
> > ID TLV. Some implementation tweaks are required.
> 
> > RFC 5884/5885....But it still requires two new code points as it 
> > will not be perfectly backwards compatible...."
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Apr 2011 17:39:12 +0300

Dave,
Lots of thanks for a prompt solution.

The question that comes to my mind is: do we really want to put all the tools in the same bag?

Vanilla 5885 implementation will provide the required CC/RDI functionality without any changes.
Is this correct? 

If you want to add proactive CV to that you have several options:

1. Run an additional "slow" CV-only BFD session using a new code point (no interleave). 
2. Combine CC/RDI and CV into a single session with interleave and bear the price of increased implementation complexity

There are probably other practical options for CV. E.g., one could use the simple password authentication option and use Source MEP ID as the password. Persistent misconnection could be detected as loss of connectivity, but once it happens, it would be (hopefully) pretty simple to define the underlying reason... (Not sure the security people would approve:-)

Insisting on one size to fit all (CC/RDI and proactive CV) seems not practical to me. We may provide a solution for that, but should we really require from  everybody to stick with this complicated combined solution?

Regards,
     Sasha

> From: David Allan I [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2011 5:26 PM
> To: Alexander Vainshtein
> And a couple of other things meant that BFD for TP could not be
> supported by a vanilla 5885 implementation.
> 
> Hope this helps
> Dave
> 
> 
> 
> GAL does not really add anything to this encapsulation IMO, simply
> allows to use G-ACh on top of LSPs and not just PWs.
> 
> 
> Regards,
>      Sasha
> 

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 12 Apr 2011 16:50:53 +0200

That is correct!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Alexander Vainshtein
Sent: Tuesday, April 12, 2011 5:20 PM
To: David Allan I
Cc: [email-masked]; Schink, Helmut (NSN - DE/Munich); David Ward
Subject: Re: [mpls] MPLS-TP CC-CV-RDI

Dave,

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> well as the need for additional features, the code point seemed to
make
> > close but not an exact match due to the addition of the Source MEP
ID
> a capability negotiation, not assign a new code point.
will

---

From: David Allan I <[email-masked]>
Date: Tue, 12 Apr 2011 11:08:00 -0400

We had a bunch of motivations in simplifiying it to one tool.

1) Less configuration as there would be fewer modes of operation.
2) CC by itself is of limited utility and compromises the rest of the network if CV functionality is desired. A CC monitored LSP can leak into another LSP undetected. IMO calling CC out as a separate requirement has only been a source of confusion.

Feedback was that running CV ALL the time was considered onerous, so we went with the interleaved solution to reduce the processing load while still providing complete fault coverage in the network. We did set a minimum CV rate so that there could be an exit criteria from a mis-connectivity fault.

Running an extra session so that CC and CV were distinct sessions would be a possible solution, and would have the desirable trait of self identifying the CV periodicity as well as the CC periodicity, but would impact scaling as it would be an extra session.

At least that was the thinking...
Dave

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 7:39 AM
To: David Allan I
Cc: [email-masked]; David Ward; Schink, Helmut (NSN - DE/Munich); [email-masked]
Subject: RE: [mpls] MPLS-TP CC-CV-RDI

Dave,

Regards,
     Sasha

> > Agreed, but that would require redesigning BFD. The other 
> > alternative would be to use the version number.
> >
> > As we had a simultaneous change of encapsultion with the GAL/G-ACh 
> > as well as the need for additional features, the code point seemed 
> > to make sense.
> >
> > Thanks
> > Dave
> >
> > > the additional  behaviors specified for MPLS TP to be 
> > > disambiguated from existing RFC 5884/5 behaviors
> > >
> > > Can you please clarify this point? Is the solution being defined 
> > > in draft cc-cv-rdi is compatible with BFD?
> > > Is it also possible for CC-CV-RDI and existing BFD to be 
> > > compatible today given only the proper configuration?
> > > Best regards,
> > > Nurit

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Apr 2011 19:20:10 +0300

Dave,
Lots of thanks for a prompt response and sharing your motivation.

Please see a couple of comments inline below.

Regards,
     Sasha

> Sent: Tuesday, April 12, 2011 6:08 PM
> To: Alexander Vainshtein

 [[[Sasha]] I suspect that carrying CC and CV in the same session would effectively result in approximately
the amount of configuration - at least, as long as you do not want to configure the BFD discriminators 
(vanilla BFD does not require that).

> 2) CC by itself is of limited utility and compromises the rest of the
> network if CV functionality is desired. 

[[[Sasha]]] Is it always desired? Or is it an option?

> A CC monitored LSP can leak into another LSP undetected. 
[[[Sasha]]] IMO you can use one of the BFD authentication mechanisms to prevent these effects.
Note also that with interleaved CC and CV only semi-permanent leakage would be detected.

> IMO calling CC out as a separate requirement has only been a source of confusion.
> 
> Feedback was that running CV ALL the time was considered onerous, so we
> went with the interleaved solution to reduce the processing load while
> still providing complete fault coverage in the network. We did set a
> minimum CV rate so that there could be an exit criteria from a mis-
> connectivity fault.
> 
> Running an extra session so that CC and CV were distinct sessions would
> be a possible solution, and would have the desirable trait of self
> identifying the CV periodicity as well as the CC periodicity, but would
> impact scaling as it would be an extra session.
> 
[[[Sasha]]] Only if all LSPs require CV all the time... 
> 2. Combine CC/RDI and CV into a single session with interleave and bear
> the price of increased implementation complexity
> 
> There are probably other practical options for CV. E.g., one could use
> the simple password authentication option and use Source MEP ID as the
> password. Persistent misconnection could be detected as loss of
> connectivity, but once it happens, it would be (hopefully) pretty
> simple to define the underlying reason... (Not sure the security people
> would approve:-)
> 
> Insisting on one size to fit all (CC/RDI and proactive CV) seems not
> practical to me. We may provide a solution for that, but should we
> really require from  everybody to stick with this complicated combined
> solution?
> 
> Regards,
>      Sasha
> 
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.

---

From: David Allan I <[email-masked]>
Date: Tue, 12 Apr 2011 12:39:13 -0400

HI Sasha:

<snipped> 

> 1) Less configuration as there would be fewer modes of operation.

 [[[Sasha]] I suspect that carrying CC and CV in the same session would effectively result in approximately the amount of configuration - at least, as long as you do not want to configure the BFD discriminators (vanilla BFD does not require that).

[Dave: We're adding a configuration section to the draft as a result of last comments, combining the tools and setting explicit defatuls does reduce the number of knobs.]

[Dave: I'm not sure why one would expend the heat of using CC alone when processing the occasional information token is far more robust]

[Dave: True, but very intermittent leakage is problematic anyway as the defect condition would flap, and the leak needs to correspond to the axchange of a CV PDU. And I have trouble envisioning a fault that was not a hard trash of the LIB, and had the characteristics of only leaking into one other LSP sproadically.

Use of the authentication techniques was a possibility, but then that would require the administration of a whole other class of identifiers/tokens, hence would be operationally undesirable]

> Feedback was that running CV ALL the time was considered onerous, so 
> we went with the interleaved solution to reduce the processing load 
> while still providing complete fault coverage in the network. We did 
> set a minimum CV rate so that there could be an exit criteria from a 
> mis- connectivity fault.
> 
> Running an extra session so that CC and CV were distinct sessions 
> would be a possible solution, and would have the desirable trait of 
> self identifying the CV periodicity as well as the CC periodicity, but 
> would impact scaling as it would be an extra session.
> 

[Dave: Hence the interleave to minimize the penalty...

Cheers
D]
<snipped to end>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 12 Apr 2011 10:28:04 -0700

Dear Sasha,
thank you for the great comparative analysis of RFC 5885 and
draft-ietf-mpls-tp-cc-cv-rdi. I have couple notes:

   - when refer to RFC 5885 are we imply use of GAL/G-ACh encapsulation with
   procedures described in RFC 5884?
   - RFC 5885 does not address independent mode introduced for
   bi-directional associated p2p LSP.
   - the scope of draft-ietf-mpls-tp-cc-cv-rdi is limited to bi-directional
   p2p LSPs, section and PWs. It is my understanding that at some point we'll
   address CC/CV monitoring over unidirectional p2p and p2mp LSP. It might be
   easier to expand OAM by using the draft rather then generalized BFD
   mechanism.

Regards,
Greg

On Tue, Apr 12, 2011 at 7:39 AM, Alexander Vainshtein <
[email-masked]> wrote:

> 2. Combine CC/RDI and CV into a single session with interleave and bear the
> price of increased implementation complexity
>
> There are probably other practical options for CV. E.g., one could use the
> simple password authentication option and use Source MEP ID as the password.
> Persistent misconnection could be detected as loss of connectivity, but once
> it happens, it would be (hopefully) pretty simple to define the underlying
> reason... (Not sure the security people would approve:-)
>
> practical to me. We may provide a solution for that, but should we really
> require from  everybody to stick with this complicated combined solution?
>
> Regards,
>     Sasha
>
>
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 12 Apr 2011 16:24:16 -0400

In message <[email-masked]>
> would be to use the version number.

The version number seems to make sense.

We need to make sure to extend BFD in such a way that we don't throw
away capability that exists today.

> well as the need for additional features, the code point seemed to

I don't think this is a good idea.  It is creating to BFDs.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 12 Apr 2011 18:35:48 -0400

In message <[email-masked]>
> supported by a vanilla 5885 implementation.

Sounds like a version update at most.

Curtis