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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Jan 2016 10:12:43 +0000

Hi!

Happy New Year!

I strongly agree with Les' perspective here, as that was also the way I was trying to write the spec.  

As we design a spec, it is important that we, simultaneously:
1. Provide future growth capability and forward compatibility, and not corner ourselves being too stringent in design considerations.
2. Specify clearly the current set of interoperable options. 

The healthy tension between these two calls for:
1. Let the transport/discovery drafts (IGPs, L2TP) have the option of carrying multiple disc
2. Expand S3.8 in the base document to say that, today, the app is to have a single disc and if in the future multiple are needed, then the procedures need to update this spec clearly scoping both endpoints' behavior. 

Concerns with this approach? It allows for well defined current behavior and maximum forward compatibility and growth potential. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Dec 22, 2015, at 08:24, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Marc -
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[email-masked]]
>> Sent: Monday, December 21, 2015 11:09 PM
>> To: Manav Bhatia; Les Ginsberg (ginsberg)
>> Cc: Alvaro Retana (aretana); Santosh P K; [email-masked]; draft-ietf-bfd-
>> [email-masked]; [email-masked]
>> 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)
>>> <[email-masked]> 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:[email-masked]] On Behalf Of Marc
>>>>> Binderberger
>>>>> Sent: Saturday, December 19, 2015 1:33 AM
>>>>> To: Alvaro Retana (aretana); Santosh P K
>>>>> Cc: [email-masked]; [email-masked]; bfd-
>>>>> [email-masked]
>>>>> 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-masked]> 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.
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Jan 2016 10:32:03 +0000

Manav,

Thanks for the discussion.

Let's not cripple the spec before its out.

Saying "let's update 5 RFCs when I understand the use case" is not forward compatibility and artificially constrain the spec :-)

Please find some comments inline.

On Dec 22, 2015, at 10:06, Manav Bhatia <[email-masked]<mailto:[email-masked]>> wrote:

Les,

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.

I am also looking at use cases for it. I won't pass judgement on how contrived they are or not, but to me they will be compelling to customers.

But even without this, a protocol spec need not artificially block progress based on your current understanding of use cases. There's a lot of creativity to be applied here.

Net-net, allow the possibility for the transport to carry multiple disc (that's 3 specs!) while put the constrain in the sbfd-ip/base spec for the current use case. That way, when the future catches up, we do not need to rewrite RFCs.

2. The bigger problem is to see how the multiple discriminators can be mapped to the respective end-points.

This is solvable, but I fully agree with you it needs to be specified explicitly.

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.

Like I said, let the discovery/transport capability of multi disc, even if today we only use single one. I very highly suspect multiple disc will become common in these contexts.

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?

If we are already planning on revising a spec that is not even printed, we might be short-sighted into its real use.

I would not argue against this.

Likewise, if folks feel that we should keep the IGP drafts as is, i would find that acceptable.

That would be my preference.

However, as you said, we need to tight S3.8 of the base.

Thanks!

Carlos.

Cheers, Manav

   Les

> > <[email-masked]<mailto:[email-masked]>> wrote:
> >>> From: Rtg-bfd [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Marc
> >>> Binderberger
> >>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; bfd-
> >>> [email-masked]<mailto:[email-masked]>
> >>> > On 12/18/15, 4:30 AM, "Santosh P K" <[email-masked]<mailto:[email-masked]>> wrote:
> >>> >
> >>> > Santosh:
> >>> >
> >>> > Hi!
> >>> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Jan 2016 10:33:59 +0000

Thanks Manav and Les, and sorry for the delay in pitching in.

I like the proposal below with one difference:
1. Instead of removing, let's say it's for future study, leave the current use case but say this spec allows for one only.
2. And 3. Yes!

Thanks!

On Dec 22, 2015, at 19:32, Manav Bhatia <[email-masked]<mailto:[email-masked]>> wrote:

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) <[email-masked]<mailto:[email-masked]>> wrote:
Manav –

We are mainly in agreement I think.
Inline.

From: Manav Bhatia [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 22, 2015 7:06 AM
To: Les Ginsberg (ginsberg)
Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

Les,

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

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

[Les:] Either way I think we are both OK. :)

   Les

Cheers, Manav

   Les

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Jan 2016 10:34:53 +0000

Thanks Manav!

> 3. Leave the IGP drafts as is.

as we have to do point (2) in any case, if the IGP drafts are changed or
remain, I would think this is the most efficient way to get out of the
troubles.

Great. Will do that.

Makes a nice test case: send multiple S-BFD discriminators in the subtlv and
see how the  test unit behaves ;-)

> And i was convinced by some folks working for the same vendor to include the
> possibility of supporting multiple discriminators per node since the
> line cards can keep conking off ! ;-)

well, they can ;-) but the way it is implemented right now I think we can
solve the problem without a 2nd discriminator.

Wow. Some serious architectural changes have gone in since then and now, eh?  ;-)

Cheers, Manav