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

[Manav Bhatia <[e-mail]>]

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) <
[e-mail]> wrote:

> Manav –
>
>
>
> We are mainly in agreement I think.
>
> Inline.
>
>
>
> *From:* Manav Bhatia [mailto:[e-mail]]
> *Sent:* Tuesday, December 22, 2015 7:06 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Marc Binderberger; Alvaro Retana (aretana); Santosh P K;
> [e-mail]; [e-mail];
> [e-mail]
> *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)
> > > <[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.
> > >>> >
> > >>
> > >
>
>
>