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. > 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? > 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. 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. > > >>> > > > >> > > > >
