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

[Marc Binderberger <[e-mail]>]

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.


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 :-)  
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.

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.



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.


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
>