Hi! Happy New Year!
I strongly agree with Les' perspective here, as that was also the way I was trying to write the spec. As we design a spec, it is important that we, simultaneously: 1. Provide future growth capability and forward compatibility, and not corner ourselves being too stringent in design considerations. 2. Specify clearly the current set of interoperable options. The healthy tension between these two calls for: 1. Let the transport/discovery drafts (IGPs, L2TP) have the option of carrying multiple disc 2. Expand S3.8 in the base document to say that, today, the app is to have a single disc and if in the future multiple are needed, then the procedures need to update this spec clearly scoping both endpoints' behavior. Concerns with this approach? It allows for well defined current behavior and maximum forward compatibility and growth potential. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Dec 22, 2015, at 08:24, Les Ginsberg (ginsberg) <[email protected]> wrote: > > 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. >>>
