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

[Mach Chen <[e-mail]>]

Hi Nobo and Marc,

I totally agree with the proposal to keep the extended use-cases and the alert discriminator mechanism in draft-akiya-bfd-seamless-alert-discrim.

Best regards,
Mach

> -----Original Message-----
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Nobo Akiya (nobo)
> Sent: Sunday, November 23, 2014 9:16 AM
> To: Marc Binderberger
> Cc: [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]
> > 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
> > >>>
> > >