Hello Manav! > S-BFD draft. You can look at Sec 3.8 of > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7 to > understand why we may want to support multiple discriminators per node.
ah, that problem :-) > My considered opinion is to strike that off from the base draft and move > on, since S-BFD solves a real problem and should not be stalled for > something that may never end up getting implemented. So OSPF, IS-IS, L2TP could transport a single discriminator instead of a list? Regards, Marc On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote: > Hi Les, > > I had asked the exact same question in an offline email that i did not get > a reply for. > > I can say, as the primary co-author of the base S-BFD draft that the case > for multiple SBFD discriminators stands on very tenuous grounds. The idea > was very weird and i had argued that it really was an > architectural/implementation limitation that was being addressed by way of > supporting multiple discriminators per node. Given that there are others > that share this concern I would recommend striking that off from the base > S-BFD draft. You can look at Sec 3.8 of > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7 to > understand why we may want to support multiple discriminators per node. > > I had conceded to that being added since i did not want to preclude the > possibility of adding that mechanism in the future. And it was felt that > this would get debated in the WG and we would go based on the consensus. > > My considered opinion is to strike that off from the base draft and move > on, since S-BFD solves a real problem and should not be stalled for > something that may never end up getting implemented. > > Cheers, Manav > > > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg) > <[email protected]> wrote: >> I certainly agree with everyone that the IGPs are merely a transport and >> do not "allocate" reflector discriminators nor - for the purposes of >> advertising S-BFD discriminators - do they have any understanding of how >> S-BFD discriminators are to be used. >> >> However, before we rush off in a direction which will invalidate any early >> implementations of the IGP drafts, I would like to see a justification of >> the need for a given node to require multiple reflector S-BFD >> discriminators and an explanation of what criteria would be used to >> determine whether the reflector should/should not respond to an Initiator >> S-BFD packet to a particular S-BFD reflector discriminator. Perhaps I have >> missed it, but to date I am not aware of any cogent explanation of this >> capability. The desire for multiple S-BFD discriminators seems to be made >> out of either: >> >> o An abundance of caution ("We don't know why we would need them - but >> if we come up with something in the future it would be nice if we didn't >> preclude it.") >> >> o Use cases which no one knows how to support (e.g. mapping a >> particular discriminator to a particular incoming interface or line card) >> >> What are the requirements and what about them necessitates multiple S-BFD >> discriminators? >> >> Les >> >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:[email protected]] On Behalf Of Marc >>> Binderberger >>> Sent: Saturday, December 19, 2015 1:33 AM >>> To: Alvaro Retana (aretana); Santosh P K >>> Cc: [email protected]; [email protected]; bfd- >>> [email protected] >>> Subject: Re: AD Review of draft-ietf-bfd-seamless-base >>> >>> Hello Santosh, Alvaro et al., >>> >>> >> [SPK] This is implementation specific right? Do we need this to be >>> >> captured in document? >>> >>> we could make it "just a TLV" which the IGP/L2TP transports to other >> S-BFD >>> modules. The transport mechanism then would not need to know the inner >>> structure, e.g. [type, discriminator], to function correctly. >>> >>> But for S-BFD modules to interoperate we would need to define the inner >>> structure of the "V" in the TLV. >>> >>> Implementation specific could be if you want to have awareness of the >> inner >>> structure in the IGP/L2TP code already, e.g. when the IGP wants to make >> use >>> of S-BFD information it transports, for it's own purpose (shortcutting >> some >>> API calls). >>> >>> >>> We have to ask the L2TP, OSPF, IS-IS authors if they would be fine with >> this >>> change :-) >>> >>> >>> Regards, Marc >>> >>> >>> >>> >>> >>> >>> On Fri, 18 Dec 2015 14:00:16 +0000, Alvaro Retana (aretana) wrote: >>> > On 12/18/15, 4:30 AM, "Santosh P K" <[email protected]> wrote: >>> > >>> > Santosh: >>> > >>> > Hi! >>> > >>> >>> There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan to >>> >>> transport >>> >>> a list of discriminators. Okay ... but how is the receiver S-BFD >> module >>> >>> making sense out of this list? Would have expected something like >>> (type, >>> >>> discriminator). The protocols don't need to understand the details, >> only >>> >>> that >>> >>> the API transports one or more of these tuples in/out of the protocol >>> >>> module. >>> >>> S-BFD would know/define what a particular type means. >>> >>> Just asking before we send OSPF, IS-IS, L2TP into the wrong >> direction :-) >>> >> >>> >> [SPK] This is implementation specific right? Do we need this to be >>> >> captured in document? >>> > >>> > What is implementation specific? >>> > >>> > Right now the IGPs (generalizing: ISIS, OSPF, L2TP, etc.) are >> developing >>> > drafts to only carry the discriminators. If, as Mark suggests, the >> IGPs >>> > also transport something like "type", then S-BFD would know what each >>> > discriminator is for. >>> > >>> > Several questions: Is this (transporting [type, discriminator]) what >> is >>> > expected from the IGPs? If so, I assume the S-BFD module on the nodes >>> > assigns those values for transportation, right? How does a receiver >> know >>> > what a particular type means? >>> > >>> > Maybe the expectation from S-BFD is different...?? That is something >> that >>> > needs to be clarified so the IGP work can proceed. >>> > >>> > Thanks! >>> > >>> > Alvaro. >>> > >> >
