Hello Reshad and other BFD experts, I'm not too deep into YANG et al., so I apologize upfront for this email :-) . I understand YANG is about configuration but are we trying to find a common way to reflect the various (CLI-)configurations that are out in the market? Isn't this, well, a bit restricting?
Should a generic "configuration" of a BFD session not contain all the variables of the particular layers? E.g. for the BFD packet itself not just timer and multiplier but "my" and "your" discriminator too? For the IP layer src/dst IP and egress interface? The various RFCs 5881, 5883, ... would be special cases that could be incorporated. E.g. a "your" discriminator of zero (or lack of this parameter) for a single-hop IP-based BFD session would mean to follow RFC5881 and it's bootstrapping mechanism. Maybe this is too generic to start the YANG endeavor. But in these days of "programmability" I would expect more than an API that replaces my CLI 1:1. Regards, Marc On Wed, 4 Nov 2015 00:48:44 +0000, Reshad Rahman (rrahman) wrote: > <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]> > Date: Tuesday, November 3, 2015 at 9:38 AM > To: "Carlos Pignataro (cpignata)" <[email protected]>, Reshad > <[email protected]> > Cc: "[email protected]" <[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] > > 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] > 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]> >> 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]> >> Date: Tuesday, November 3, 2015 at 2:48 AM >> To: Reshad <[email protected]> >> Cc: Santosh P K <[email protected]>, Gregory Mirsky >> <[email protected]>, "[email protected]" <[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]> >>> 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]> on behalf of Santosh P K >> <[email protected]> >> Date: Tuesday, November 3, 2015 at 1:25 AM >> To: Gregory Mirsky <[email protected]>, "[email protected]" >> <[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] >> 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 >> > >
