Re: AD Review of draft-ietf-bfd-seamless-base

[Manav Bhatia <[e-mail]>]

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) <[e-mail]
> 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:[e-mail]] On Behalf Of Marc
> > Binderberger
> > Sent: Saturday, December 19, 2015 1:33 AM
> > To: Alvaro Retana (aretana); Santosh P K
> > Cc: [e-mail]; [e-mail]; bfd-
> > [e-mail]
> > 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" <[e-mail]> 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.
> > >
>
>