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

[Manav Bhatia <[e-mail]>]

I agree that alert-discrim use case and mechanism should go in a
separate draft and must not be combined with the base s-bfd drafts.

Cheers, Manav

On Sun, Nov 23, 2014 at 6:45 AM, Nobo Akiya (nobo) <[e-mail]> wrote:
> 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]
>> 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]
>> >> 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
>> >>>
>> >
>