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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Marc -

> -----Original Message-----
> From: Marc Binderberger [mailto:[e-mail]]
> Sent: Monday, December 21, 2015 11:09 PM
> To: Manav Bhatia; Les Ginsberg (ginsberg)
> Cc: Alvaro Retana (aretana); Santosh P K; [e-mail]; draft-ietf-bfd-
> [e-mail]; [e-mail]
> 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)
> > <[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.
> >>> >
> >>
> >