That makes sense to me, Reshad, Thanks, — Carlos.
> On Nov 4, 2015, at 9:48 AM, Reshad Rahman (rrahman) <[email protected]> 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] > <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] > <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 > <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] >> <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] >> <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
