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

["Nobo Akiya (nobo)" <[e-mail]>]

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