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