<Speaking as individual contributor>

Hi all,

Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD 
sessions for MH, I think that the operational model for BFD IP MH should allow 
for multiple sessions between 2 endpoints (same src/dst/vrf). To support this, 
we could e.g. add local discriminator to the key.

Note that I am not pushing for another OOB mechanism.

Regards,
Reshad.

From: Alexander Vainshtein 
<[email protected]<mailto:[email protected]>>
Date: Tuesday, November 3, 2015 at 9:38 AM
To: "Carlos Pignataro (cpignata)" 
<[email protected]<mailto:[email protected]>>, Reshad 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: RE: Multiple BFD sessions between the same pair of end-points

Hi all,
I concur with Carlos, only wanted to add that in the case of BFD in MPLS LSP 
ability for in-band initialization does not exist (e.g. in the case of PHP, see 
Section 5 in RFC 5884), and so an OOB initialization procedure was unavoidable.

I’d say we need a very strong use case for multiple BFD sessions between the 
same pair of endpoints to justify introduction of yet another OOB 
initialization procedure.

My 2,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
[email protected]<mailto:[email protected]>

From: Rtg-bfd [mailto:[email protected]] On Behalf Of Carlos Pignataro 
(cpignata)
Sent: Tuesday, November 03, 2015 3:16 PM
To: Reshad Rahman (rrahman)
Cc: [email protected]<mailto:[email protected]>
Subject: Re: Multiple BFD sessions between the same pair of end-points

Hi Reshad,

It really depends on what is considered a “path” over which BFD detects faults, 
and how the initial demux can be done vs. bootstrapped out-of-band.

RFC 5881 has the text quoted by Greg, because in that case single-hop 
initialization procedures can be done (by binding the interface to BFD context) 
and not require out-of-band discriminator bootstrapping.

However, on a single interface between two forwarding endpoints, there could be 
multiple sessions in a generic application. The simplest example is what is 
described in the second paragraph of 
https://tools.ietf.org/html/rfc5882#section-6. In that case, a path is a 
specific diffserv code point over IPv4 between two endpoints, and that is the 
context used for initialization using single-hop procedures. In RFC5885 we 
chose to allow only one, to use single-hop initialization for example within a 
tunnel (PW) context.

For the multi-hop case, there could also be multiple sessions between 
endpoints. If there is only one session, then the initialization can be done 
using single-hop procedures binding source/dst addresses. However, is there are 
multiple sessions, as e.g., if there is some ECMP-awareness, then some 
different and additional mechanism (e.g., out-of-band bootstrapping) is needed. 
This is described in the second paragraph of 
https://tools.ietf.org/html/rfc5883#section-3. In fact, these two options are 
covered in S4.1 (limit to one session and use src/dst) and S4.2 (allow multiple 
sessions and use an OOB bootstrapping).

As far as the YANG models, I’d think that single session for both single- and 
multi-hop covers vast majority of real cases, being pragmatic. If someone wants 
to have for example multiple sessions between a pair of endpoint addresses in 
multi-hop, then an OOB mechanism is needed, and I do not believe there is a 
spec’ed one other than for MPLS.

Thanks,

— Carlos.

On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) 
<[email protected]<mailto:[email protected]>> wrote:

Hi Sam,

Typo in my email indeed. What I meant is that there could be vendor specific 
extensions if needed.

Also looks like there was confusion in the design team (seemingly caused by my 
misinterpretation of what was said), there is no known implementation which 
supports multiple BFD single-hop sessions for the same pair of endpoints (right 
Santosh?). For MH it’s a different story because of multiple-paths.

The DT will get together to clarify and apologies for the confusion.

Regards,
Reshad.

From: Sam Aldrin <[email protected]<mailto:[email protected]>>
Date: Tuesday, November 3, 2015 at 2:48 AM
To: Reshad <[email protected]<mailto:[email protected]>>
Cc: Santosh P K <[email protected]<mailto:[email protected]>>, Gregory 
Mirsky <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: Multiple BFD sessions between the same pair of end-points

Reshad,

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) 
<[email protected]<mailto:[email protected]>> wrote:

Hi Santosh,

Even for single-hop we had discussions about implementations which support the 
option of having multiple BFD single-hop sessions on 1 interface between 2  
endpoints. That was an argument for having the BFD config in routing 
applications. This is what was discussed today in the WG. And I think Greg’s 
point is that we don’t have to support this in the base model, but 
implementations are have vendor specific model which supports this behavior.
Are there already vendor specific models/implementations in the single hop 
case? OR did you mean, there could be vendor specific extensions?

-sam


Regards,
Reshad.


From: Rtg-bfd <[email protected]<mailto:[email protected]>> on 
behalf of Santosh P K <[email protected]<mailto:[email protected]>>
Date: Tuesday, November 3, 2015 at 1:25 AM
To: Gregory Mirsky 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: RE: Multiple BFD sessions between the same pair of end-points

This is form RFC 5881 section 3.

In this application, there will be only a single BFD session between
   two systems over a given interface (logical or physical) for a
   particular protocol.  The BFD session must be bound to this
   interface.

Which says for singlehop you will have only single BFD session for an 
interface.  The case where we are struggling in Yang is for multihop BFD 
session.

Thanks
Santosh P K


From: Rtg-bfd [mailto:[email protected]] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: [email protected]<mailto:[email protected]>
Subject: Multiple BFD sessions between the same pair of end-points

Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits multiple 
single-hop BFD sessions between the same pair of end points:
   Each BFD session between a pair of systems MUST traverse a separate
   network-layer path in both directions.  This is necessary for
   demultiplexing to work properly, and also because (by definition)
   multiple sessions would otherwise be protecting the same path.

                Regards,
                                Greg


Reply via email to