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 <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 <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]> 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] >> <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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
