RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

[Marc Binderberger <[e-mail]>]

Hello Nobo,

(back from Hawaii or writing emails at the beach? ;-)


> Your view is then:
> 
> Instead of:
> 
> (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and keep 
> the alert discriminator mechanism in the 
> draft-akiya-bfd-seamless-alert-discrim.
> 
> Do:
> 
> (2) Keep the extended use-cases and alert discriminator mechanism in the 
> draft-akiya-bfd-seamless-alert-discrim.
> 
> Or
> 
> (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case and 
> move the alert discriminator mechanism to draft-ietf-bfd-seamless-base.

yes, exactly.


> Whether the S-BFD packets with alert discriminator are handled in HW or SW 
> is an implementation choice. Similar to how IP router alert option & router 
> alert label are handled, I do see handling of S-BFD packets with alert 
> discriminator in the SW to be a reasonable approach, in which case the HW 
> instruction for S-BFD packets with alert discriminator is to punt to SW for 
> processing.

> Personally, I tend to recommend that alert discriminators are handled in 
> the SW. Let's assume that you agree on this (hypothetically). In that case, 
> would you still recommend the alert discriminator mechanism to be moved to 
> the draft-ietf-bfd-seamless-base or is it reasonable to keep it in the 
> draft-akiya-bfd-seamless-alert-discrim?


That's probably where our different views come from :-)
I would aim to simplify the main idea of the draft so it _can_ easily be 
implemented even in hardware.

For the traceroute - my guess is TTL punts (if that mechanism to "deliver" is 
used) happen in software as many mechanism use this "trick" but if a hardware 
can handle TTL punts, it can handle the diag code as well. I don't see the 
document needs to adjust for the traceroute case.

For a basic reflector task, having a zero discriminator as a default 
reflector discriminator would allow for very simple implementations (we 
discussed a while ago a fixed discriminator value for simple broadband 
modems, remember?).
For more complex equipment and scenarios, keeping it in hardware instead of a 
software punt would maintain the ability of S-BFD to go up very quickly.


I tend to not see the zero discriminator as such a big exception, which may 
explain my idea to integrate it into the base document. And to keep it 
compatible to hardware implementations.
Assuming you want to add more "special effects" in the future I can see why 
you have an extra document. I would propose to keep the zero-reflector 
mentally aligned :-) with the base document and accordingly designed to allow 
implementations to cover the zero-reflector together with "normal" S-BFD 
(read: may be in hardware).


> Ah, great catch. Yes we do not want "intermediate nodes" to pick up S-BFD 
> packets with alert discriminator.

Good - makes life simpler :-)


Regards, Marc


On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote:
> Hi Marc,
> 
> Thanks for providing your view.
> 
> Please see in-line.
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Monday, November 17, 2014 1:04 AM
>> To: Nobo Akiya (nobo)
>> Cc: [e-mail]
>> Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
>> 
>> Hello Nobo and BFD experts,
>> 
>> giving this document a closer look for the first time (ahem ;-) I have a
>> slightly different view.
>> 
>> Having S-BFD use cases for the general S-BFD in an extra document does
>> improve the overall discussion and documentation, simply because the
>> base S-BFD is already complex enough, as are the use cases.
>> 
>> But for such a relatively small document splitting off the reason why the
>> document exists is not improving the reading/understanding of this draft.
>> Unless you decide to integrate the alert-discriminator document into the
>> base document, then obviously you use the use-case document.
> 
> Your view is then:
> 
> Instead of:
> 
> (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and keep 
> the alert discriminator mechanism in the 
> draft-akiya-bfd-seamless-alert-discrim.
> 
> Do:
> 
> (2) Keep the extended use-cases and alert discriminator mechanism in the 
> draft-akiya-bfd-seamless-alert-discrim.
> 
> Or
> 
> (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case and 
> move the alert discriminator mechanism to draft-ietf-bfd-seamless-base.
> 
> My thought was that (1) makes sense, but your view that (1) makes all the 
> S-BFD documents set more complex to understand is a valid concern (it's 
> always good to get fresh eyes on documents!).
> 
>> 
>> 
>> For the integration of the technical aspect into the base document, I think
>> this is an idea worth to discuss. At the end what you need is to add the 
>> rule
>> for the zero discriminator to the reflector behaviour; we managed this for
>> standard BFD, we should be able to do this for the reflector BFD as well 
>> :-)
> 
> Whether the S-BFD packets with alert discriminator are handled in HW or SW 
> is an implementation choice. Similar to how IP router alert option & router 
> alert label are handled, I do see handling of S-BFD packets with alert 
> discriminator in the SW to be a reasonable approach, in which case the HW 
> instruction for S-BFD packets with alert discriminator is to punt to SW for 
> processing.
> 
>> For the diagnostic codes I'm not sure; it will complicate hardware
>> implementations (probably not a no-go problem though) and seems
>> otherwise not add a real value IMHO.
> 
> If one really wants to handle them in the HW, that's a possibility. 
> Although as you stated, it does complicate HW implementations and this is 
> another reason for SW based implementations.
> 
>> 
>> So if there are already at this stage of S-BFD use case(s) for zero-
>> discriminator to bring up (some) sessions then I would propose to consider
>> the integration into the base document. This will also guarantee that the
>> zero-discriminator handling is as fast as the "normal" reflection and is 
>> not
>> on a slower exception path.
> 
> Personally, I tend to recommend that alert discriminators are handled in 
> the SW. Let's assume that you agree on this (hypothetically). In that case, 
> would you still recommend the alert discriminator mechanism to be moved to 
> the draft-ietf-bfd-seamless-base or is it reasonable to keep it in the 
> draft-akiya-bfd-seamless-alert-discrim?
> 
>> 
>> 
>> 
>> I have a question: so far S-BFD packets would be received, not "picked out
>> of the data stream". Receiving could be because the destination IP would
>> match or would be 127/8, the TTL would be zero and so on. In the security
>> section you say ...
>> 
>>    Conceptually the Alert Discriminator is similar to an IP Router Alert
>>    Option or an MPLS Router Alert Label.
>> 
>> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the
>> reflector) with an alert-discriminator out of the data stream that 
>> otherwise
>> would just pass this node?
>> I guess you don't want but I want to make sure I understand it correctly.
> 
> Ah, great catch. Yes we do not want "intermediate nodes" to pick up S-BFD 
> packets with alert discriminator. So the statement regarding "Conceptually 
> the Alert Discriminator is similar to an IP Router Alert Option or an MPLS 
> Router Alert Label" should be re-stated and clarified.
> 
> Thanks!
> 
> -Nobo
> 
>> 
>> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote:
>>> [Speaking as an individual S-BFD contributor]
>>> 
>>> Hi BFD WG,
>>> 
>>> There were couple of questions I need your input on
>>> draft-akiya-bfd-seamless-alert-discrim.
>>> 
>>> 
>>> (1) Should the "extended" S-BFD use cases move to
>>> draft-ietf-bfd-seamless-use-case?
>>> 
>>> My opinion is yes. Once the "extended" S-BFD use cases have been
>>> incorporated into draft-ietf-bfd-seamless-use-case, then we should try
>>> to move draft-ietf-bfd-seamless-use-case forward.
>>> 
>>> How does the WG feel about this?
>>> 
>>> 
>>> (2) Should the alert discriminator proposal move to
>>> draft-ietf-bfd-seamless-base?
>>> 
>>> My opinion is no . Instead we should position this as an optional
>>> feature of S-BFD (hence separate document than the base), especially
>>> considering we likely need to think through additional security concerns
>> raised by this.
>>> 
>>> A question was raised by Greg on how does a node find out if the
>>> target supports the optional alert discriminator or not. We can define
>>> a mandatory diagnostic value that must be implemented when the alert
>>> discriminator is implemented. One can send an S-BFD control packet
>>> with the alert discriminator with this diagnostic value to check if
>>> the target supports the alert discriminator mechanism.
>>> 
>>> How does the WG feel about this?
>>> 
>>> 
>>> Thanks!
>>> 
>>> -Nobo
>>> 
>