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

[Gregory Mirsky <[e-mail]>]

Hi Nobo, et. al,
please find my notes in-line and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Nobo Akiya (nobo)
Sent: Thursday, November 13, 2014 8:04 PM
To: [e-mail]
Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

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

GIM>> I think it makes sense to have use cases related to S-BFD in one document. Support.

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

GIM>> After discussing structure of BFD for multi-point networks document I realized that keeping protocol extensions in separate documents has its value, especially if an extension is optional. Hence I change my previously stated position and support progress alert discriminator document separately from S-BFD base.

Thanks!

-Nobo