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

[Marc Binderberger <[e-mail]>]

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?


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