<Speaking as individual contributor> Hi Marc,
For classical BFD we are looking at matching with what’s currently in CLI (config, operational, …). When we tackle YANG for S-BFD, that’s when we’ll look at the programmability aspect. Regards, Reshad. On 2015-11-04, 6:20 PM, "Marc Binderberger" <[email protected]> wrote: >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 >>> >> >>
