Hello everyone! > 1. Remove the multiple sessions terminating on the same target example from > the use-case document. > 2. Change the base s-bfd draft to only advertise 1 discriminator > 3. Leave the IGP drafts as is.
as we have to do point (2) in any case, if the IGP drafts are changed or remain, I would think this is the most efficient way to get out of the troubles. Makes a nice test case: send multiple S-BFD discriminators in the subtlv and see how the test unit behaves ;-) > And i was convinced by some folks working for the same vendor to include the > possibility of supporting multiple discriminators per node since the > line cards can keep conking off ! ;-) well, they can ;-) but the way it is implemented right now I think we can solve the problem without a 2nd discriminator. Regards, Marc On Wed, 23 Dec 2015 03:34:37 +0000, Mach Chen wrote: > Hi Manav, Les and others, > > Happy Holidays! > > The solution below makes perfect sense to me! > > Best regards, > Mach > > From: Rtg-bfd [mailto:[email protected]] On Behalf Of Manav Bhatia > Sent: Wednesday, December 23, 2015 8:32 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: AD Review of draft-ietf-bfd-seamless-base > > Les, > > I am fine with this as well. > > Can we hear what others think on this issue and move on? In the absence of > a clear majority i would like to go ahead with the changes that you > propose, which are: > > 1. Remove the multiple sessions terminating on the same target example from > the use-case document. > 2. Change the base s-bfd draft to only advertise 1 discriminator > 3. Leave the IGP drafts as is. > > Cheers, Manav > > On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > Manav – > > We are mainly in agreement I think. > Inline. > > From: Manav Bhatia [mailto:[email protected]] > Sent: Tuesday, December 22, 2015 7:06 AM > To: Les Ginsberg (ginsberg) > Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; > [email protected]; [email protected]; [email protected] > Subject: Re: AD Review of draft-ietf-bfd-seamless-base > > Les, > >>> >>> 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". > > The problem as i see is this: > > 1. The use case for supporting multiple discriminators per node imo is > pretty contrived. I havent yet heard a compelling argument of why we need > to support that. > > 2. The bigger problem is to see how the multiple discriminators can be > mapped to the respective end-points. If IGPs advertise multiple > discriminators, then we would map all those to the same node, and you > cannot support the use case defined in the use-case document, which > currently is the only case that requires multiple discriminators to be > advertised. > > [Les:] If base S-BFD draft says “only one discriminator is supported” > then IGPs will never be asked to send multiple discriminators (even though > they can). > >> 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 > > In future when we are revising the IGP drafts to carry the additional > information then why dont we change the drafts then to advertise multiple > discriminators? > > [Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at this > time unnecessarily. And since S-BFD will never ask to advertise multiple > discriminators this seems safe. >> >> 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. > > I would not argue against this. > >> >> That said, if folks feel strongly that we should restrict the IGP/L2TP >> advertisement format to one discriminator I would find that acceptable. > > Likewise, if folks feel that we should keep the IGP drafts as is, i would > find that acceptable. > > [Les:] Either way I think we are both OK. J > > Les > > Cheers, Manav >> >> 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. >>> >>> > >>> >> >>> > > > >
