Marc - > -----Original Message----- > From: Marc Binderberger [mailto:[email protected]] > Sent: Monday, December 21, 2015 11:09 PM > To: Manav Bhatia; Les Ginsberg (ginsberg) > Cc: Alvaro Retana (aretana); Santosh P K; [email protected]; draft-ietf-bfd- > [email protected]; [email protected] > Subject: Re: AD Review of draft-ietf-bfd-seamless-base > > 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?
[Les:] Perhaps - or we could leave these drafts as is - allowing the possibility of sending multiple discriminators in the future. The key would be for the base S-BFD draft to say something like "currently only support for a single discriminator per node is defined". If in the future support for multiple discriminators is required and defined then the IGP/L2TP drafts could either: o Be left alone - a simple list is all that is required o Be revised to carry whatever additional info S-BFD requires My point is that since we have no idea what additional info might be required in the future leaving the IGP/L2TP drafts in their current state does no harm - and restricting them to one discriminator only provides no benefit. That said, if folks feel strongly that we should restrict the IGP/L2TP advertisement format to one discriminator I would find that acceptable. Les > > > 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. > >>> > > >> > >
