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

["MALLIK MUDIGONDA (mmudigon)" <[e-mail]>]

Hi Nobo,

Agree that the Alert Discriminator must be described in a separate document. Since the SBFD use case document is listing out all the use cases of SBFD don’t you think we should at least mention  the alert discriminator function as on of the use cases and place a reference to the alert discriminator document in the use cases.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 23 November 2014 6:45 am
To: Marc Binderberger <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hello BFD WG,

Marc and I had some conversation on the topic of S-BFD alert discriminator document structure, and converged on a direction.

- We think that it is useful to describe both the problems and the solution for the S-BFD alert discrimintor in a single document.
- We also think the S-BFD alert discriminator is more like an exception mechanism, thus the mechanism should remain outside of the S-BFD base document.

Therefore, our converged recommendation to the WG is to keep the extended use-cases and the alert discriminator mechanism in the draft-akiya-bfd-seamless-alert-discrim.

This also means that no further changes are needed in draft-ietf-bfd-seamless-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forward if authors feel that it is ready.

We would appreciate it if folks can chime in and state whether or not this is an acceptable way forward.

Thanks!

-Nobo & Marc
-----Original Message-----
From: Marc Binderberger [mailto:[e-mail]]
Sent: Friday, November 21, 2014 3:25 AM
To: Nobo Akiya (nobo)
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
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]<mailto:[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
>>>
>