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

[Mach Chen <[e-mail]>]

Hi Manav, Les and others,

Happy Holidays!

The solution below makes perfect sense to me!

Best regards,
Mach

From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Manav Bhatia
Sent: Wednesday, December 23, 2015 8:32 AM
To: Les Ginsberg (ginsberg)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

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]<mailto:[e-mail]>> wrote:
Manav –

We are mainly in agreement I think.
Inline.

From: Manav Bhatia [mailto:[e-mail]<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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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. ☺

   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]<mailto:[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]<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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; bfd-
> >>> [e-mail]<mailto:[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]<mailto:[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.
> >>> >
> >>
> >