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

[Santosh P K <[e-mail]>]

Nobo,
 
> (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?
> 

I agree. 


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

I agree with making this as optional feature and not merging with use case document. This also assumes that all the nodes on the path MUST have S-BFD implemented. What even if we mandate diag bit and intermediate router does not understand that diag bit as that box is with old BFD implementation? There should be something suggested in this document that ingress should try for only finite time or retries?


Thanks
Santosh P K