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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 14 Nov 2014 04:04:08 +0000

[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

---

From: Santosh P K <[email-masked]>
Date: Fri, 14 Nov 2014 22:06:34 +0000

Nobo,
 
> 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.
> 

I agree. 

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

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 14 Nov 2014 22:22:50 +0000

Hi Santosh,

Many thanks for comments.

Speaking with couple of folks at IETF91, they were in agreement on the suggested approach for (1) and (2).
Hoping to hear further comments in response to this thread, so that we can close this off and move forward.

Please see in-line.

> -----Original Message-----
> From: Santosh P K [mailto:[email-masked]]
> Sent: Friday, November 14, 2014 12:07 PM
> To: Nobo Akiya (nobo); [email-masked]
> Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
> 
> Nobo,
> 
> > (1) Should the "extended" S-BFD use cases move to
> > draft-ietf-bfd-seamless- use-case?
> >
> > incorporated into draft-ietf-bfd-seamless-use-case, then we should try
> > to move draft-ietf-bfd-seamless-use-case forward.
> >

:)

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

Classical BFD vs. S-BFD will be differentiated with the UDP port. With that said, having some texts about how an initiator unambiguously determines whether or not a target node support S-BFD alert discriminator (and recommended sequences) is a good idea. I'll place this text in the next revision.

Thanks!

-Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 15 Nov 2014 07:57:05 +0000

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

	Regards,
		Greg

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

Hi BFD WG,

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

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

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Sat, 15 Nov 2014 12:33:20 +0000

Hi Nobo,

Replies inline

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 14 November 2014 9:34 am
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hi BFD WG,

Mallik>> Agree. Since this is another use case of SBFD it makes sense to have all in one place.

Mallik>> Agree. Since this is an optional feature using the base proposal of SBFD, we can have it as a separate document.

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 15 Nov 2014 19:34:42 +0000

Hi Greg,

Many thanks for taking time to provide your comments.

Thanks!

-Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Friday, November 14, 2014 9:57 PM
> 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
> 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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 15 Nov 2014 19:36:04 +0000

Hi Mallik,

Many thanks for providing your comments.

Thanks!

-Nobo

From: MALLIK MUDIGONDA (mmudigon)
Sent: Saturday, November 15, 2014 2:33 AM
To: Nobo Akiya (nobo); [email-masked]
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hi Nobo,

Replies inline

Regards
Mallik

Hi BFD WG,

Thanks!

-Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 16 Nov 2014 22:03:32 -0800

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:
> draft-ietf-bfd-seamless-use-case?
> 
> 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 
> discriminator with this diagnostic value to check if the target supports 
> the alert discriminator mechanism.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 21 Nov 2014 01:58:59 +0000

Hi Marc,

Thanks for providing your view.

Please see in-line.

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, November 17, 2014 1:04 AM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]
> improve the overall discussion and documentation, simply because the
> base S-BFD is already complex enough, as are the use cases.
> 
> 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!).

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

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

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

> > feature of S-BFD (hence separate document than the base), especially

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 21 Nov 2014 00:25:12 -0800

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:
> 
> (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:
> (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:
> 
> (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!).
> 
>> 
>> 
> 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.
> 
> 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.
> 
>> 
> 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?
> 
>> 
>> 
>> 
> 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
>> 
>> 
>> 
>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 23 Nov 2014 01:15:48 +0000

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
	
> Sent: Friday, November 21, 2014 3:25 AM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]
> > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and
> > keep the alert discriminator mechanism in the
> > (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.
> 
> 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.
> 
> 
> mentally aligned :-) with the base document and accordingly designed to
> allow implementations to cover the zero-reflector together with "normal"
> S-BFD
> > Ah, great catch. Yes we do not want "intermediate nodes" to pick up
> > S-BFD packets with alert discriminator.
> 
> >> 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
> > (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.
> >
> > Although as you stated, it does complicate HW implementations and this
> > is another reason for SW based implementations.
> >
> >>
> >> 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 ...
> >>
> >> reflector) with an alert-discriminator out of the data stream that
> >> otherwise would just pass this node?
> > 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
> >>
> >>
> >>
> >>
> >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should
> >>> try to move draft-ietf-bfd-seamless-use-case forward.
> >>>
> >>> 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.
> >>>

---

From: Santosh P K <[email-masked]>
Date: Sun, 23 Nov 2014 02:39:07 +0000

Nobo and Marc,
   I completely agree with having a separate document for alert discriminator and progress with use-case document.

Thanks
Santosh P K 

> Sent: Sunday, November 23, 2014 6:46 AM
> To: Marc Binderberger
> Cc: [email-masked]
> 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.
> 
> > > 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?
> >
> >
> > simplify the main idea of the draft so it _can_ easily be implemented
> > even in hardware.
> >
> > 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.
> >
> > 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
> > >> 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:
> > >
> > > 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
> > >> :-)
> > >
> > > Although as you stated, it does complicate HW implementations and
> > > this is another reason for SW based implementations.
> > >
> > >>
> > >> 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?
> > >
> > >>
> > >>
> > >>
> > > "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
> > >>
> > >>
> > >>
> > >>
> > >>> feature of S-BFD (hence separate document than the base),
> > >>> especially considering we likely need to think through additional
> > >>> security concerns
> > >> raised by this.
> > >>>

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 23 Nov 2014 04:14:58 +0000

Hi Nobo, Marc, Santosh, et. al,
there're many ways to slice the bread.
I agree with the proposed course of actions.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, November 22, 2014 5:16 PM
To: Marc Binderberger
Cc: [email-masked]
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hello BFD WG,

Thanks!

-Nobo & Marc
	
> > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draft-akiya-bfd-seamless-alert-discrim?
> 
> 
> instead of a software punt would maintain the ability of S-BFD to go up very quickly.
> 
> 
> accordingly designed to allow implementations to cover the zero-reflector together with "normal"
> S-BFD
> >> because the base S-BFD is already complex enough, as are the use cases.
> >>
> >> into the base document, then obviously you use the use-case document.
> >
> > Your view is then:
> >
> > Instead of:
> >
> > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draft-akiya-bfd-seamless-alert-discrim?
> >
> >>
> >>
> >>
> > Alert Option or an MPLS Router Alert Label" should be re-stated and clarified.
> >
> > Thanks!
> >
> > -Nobo
> >
> >>
> >>
> >> Regards, Marc
> >>
> >>
> >>
> >>

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 24 Nov 2014 08:24:20 +0530

I agree that alert-discrim use case and mechanism should go in a
separate draft and must not be combined with the base s-bfd drafts.

Cheers, Manav

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Mon, 24 Nov 2014 05:49:15 +0000

Hi Nobo,

Agree that the Alert Discriminator must be described in a separate document. Since the SBFD use case document is listing out all the use cases of SBFD don’t you think we should at least mention  the alert discriminator function as on of the use cases and place a reference to the alert discriminator document in the use cases.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 23 November 2014 6:45 am
To: Marc Binderberger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hello BFD WG,

Thanks!

-Nobo & Marc
-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Friday, November 21, 2014 3:25 AM
To: Nobo Akiya (nobo)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
Hello Nobo,
base.
yes, exactly.
Good - makes life simpler :-)
Regards, Marc
On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote:
>> Cc: [email-masked]<mailto:[email-masked]>
draft.
base.

---

From: Mach Chen <[email-masked]>
Date: Mon, 24 Nov 2014 10:03:15 +0000

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

> Sent: Sunday, November 23, 2014 9:16 AM
> To: Marc Binderberger
> Cc: [email-masked]
> - 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
> 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.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 24 Nov 2014 13:55:50 +0000

Thanks for chiming in Manav, Mallik, Mach!

Mallik, please see one comment in-line.

From: MALLIK MUDIGONDA (mmudigon)
Sent: Monday, November 24, 2014 12:49 AM
To: Nobo Akiya (nobo); Marc Binderberger
Cc: [email-masked]
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hi Nobo,

Agree that the Alert Discriminator must be described in a separate document. Since the SBFD use case document is listing out all the use cases of SBFD don't you think we should at least mention  the alert discriminator function as on of the use cases and place a reference to the alert discriminator document in the use cases.

[NOBO] Normally:

1.      Use case document exists.

2.      Solution document exists and references the use case documents.

3.      Extension document exists and references the solution document (and possibly the use case document).
So the S-BFD use case document referencing the alert discriminator document will be backwards IMO. I think it is reasonable to not make any updates to the S-BFD use case document, wrt mentioning of the alert discriminator use-cases/problems since those will be described in the alert discriminator document.

Thanks!

-Nobo

Thanks

Regards
Mallik

Hello BFD WG,

Thanks!

-Nobo & Marc

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Friday, November 21, 2014 3:25 AM
To: Nobo Akiya (nobo)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
Hello Nobo,
base.
yes, exactly.
draft.
base.

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 24 Nov 2014 17:29:16 -0800

[resending as mailer complained, mail is too long; removed earlier content
as well)
Hi Nobo et al,

I have finally read the 'alert discriminator' document.

Keeping the solution aside, what makes it special that the use case cannot
be documented in 'use case' ID?
Irrespectively, while explaining the solution, the problem has to be
explained anyway.
But, when there is use case document, like other use cases, adding the use
case will be good, doesn't it?

I know it will only delay the use-case document, which I am an editor of
it.
Want to understand the rationale behind it. (Read emails, but don't think I
am convinced).

Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2).
I am not sure if it is indeed needed as BFD was not used so far like this.
Just a simple extension or not is different matter. Whether we should be
doing it with BFD (not just S-BFD) is more important and needs to be
discussed.
And I do not think that it should be part of S-BFD use case at this point.

cheers
sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 26 Nov 2014 01:55:28 +0000

Hi Sam,

Good points, please see in-line with [NOBO].

> From: Sam Aldrin [mailto:[email-masked]]
> Sent: Monday, November 24, 2014 8:29 PM
> To: Nobo Akiya (nobo)
> Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; [email-masked];
> [email-masked]

[NOBO] Thanks!

> be documented in 'use case' ID?

[NOBO] I have flip-flopped on the document structure but here's my current thoughts.

Currently the S-BFD use case document describes the use cases for the core S-BFD functionality described in the S-BFD base document. 

As you described below, we do not yet have the WG consensus on the alert discriminator use cases nor the mechanism, and this is something which needs to get discussed more.

However, there is no reason to halt the progress of S-BFD use-case/base/ip documents as there is no dependency from them to the alert discriminator.

Therefore at this point it makes sense [to me] that we:
1) Progress S-BFD use-case document.
2) Progress S-BFD base/ip documents.
3) Discuss the use-cases/mechanism of the alert discriminator, without creating a dependency from (1, 2) to the alert discriminator.

> Irrespectively, while explaining the solution, the problem has to be

[NOBO] Agree.

> case will be good, doesn't it?

[NOBO] If they are use cases for the base functionality, then definitely yes. If there are use cases that require further extensions to the base functionality, then I think the answer really depends (like where we are).

> 
> I know it will only delay the use-case document, which I am an editor of it.

[NOBO] I hope above provides more context on where we are?

> doing it with BFD (not just S-BFD) is more important and needs to be

[NOBO] Fully agree that we need to discuss above further.

> And I do not think that it should be part of S-BFD use case at this point.

[NOBO] Excellent! So we are in sync about the document structure then. Let push proceed with this path, and spawn off a separate thread to discuss the validity of the alert discriminator use-cases and the mechanism. Sounds like a plan?

Thanks!

-Nobo

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 26 Nov 2014 03:59:10 +0000

Hi Nobo,

I am convinced. If Sam doesn’t have any further comments I think we are good to go.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 26 November 2014 7:25 am
To: Sam Aldrin <[email-masked]<mailto:[email-masked]>>
Cc: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Marc Binderberger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hi Sam,

-----Original Message-----
From: Sam Aldrin [mailto:[email-masked]]
Sent: Monday, November 24, 2014 8:29 PM
To: Nobo Akiya (nobo)
Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
[resending as mailer complained, mail is too long; removed earlier content
as well)
Hi Nobo et al,
I have finally read the 'alert discriminator' document.

[NOBO] Thanks!

[NOBO] Agree.

Thanks!

-Nobo

cheers
sam

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 25 Nov 2014 20:07:10 -0800

Hi Nobo,

Thank you for the reply.

Inline for my comments.

-sam
> On Nov 25, 2014, at 5:55 PM, Nobo Akiya (nobo) <[email-masked]> wrote:
> Hi Sam,
> 
Ah ok! I didn't know there would much worry about Alert Discriminator as a use case. If you say, it was not discussed much, then I am ok with your reasoning.
> 3) Discuss the use-cases/mechanism of the alert discriminator, without creating a dependency from (1, 2) to the alert discriminator.
Sounds fair. Additionally, you should start discussion on alert discriminator as well. Feel it has usefulness. 

> [NOBO] If they are use cases for the base functionality, then definitely yes. If there are use cases that require further extensions to the base functionality, then I think the answer really depend…
Nod. 
> [NOBO] I hope above provides more context on where we are?
Affirm. clear now.

> [NOBO] Excellent! So we are in sync about the document structure then. Let push proceed with this path, and spawn off a separate thread to discuss the validity of the alert discriminator use-cases…
Yes, indeed is a plan.

-sam

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 25 Nov 2014 22:37:33 -0800

Hello Sam,

> [resending as mailer complained, mail is too long; removed earlier content 

complained but still delivered the long email too :-)

> be documented in 'use case' ID?

I would say it's the other way around: what makes S-BFD base and use-case so 
special that we separated them?

And sure, there is a good answer: size and focus. Especially keeping focus on 
both topics - protocol and use cases - is probably easier with two documents.
But for something the size of the alert-discriminator the size is not a 
problem and for being focused it's then in favour of one single document 
(IMHO).

Splitting a small document makes it just fuzzy (my very personal opinion ;-)

> doing it with BFD (not just S-BFD) is more important and needs to be 

Interesting point.  

Regards, Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 26 Nov 2014 13:01:16 +0000

Hi Sam, Marc, Mallik,

Many thanks for healthy discussions.

To summarize:
- I will spawn off a separate thread for the alert discriminator soon.
- I [as individual contributor] believe draft-ietf-bfd-seamless-use-case document is now ready to progress. Authors have the ball to poke the chairs :)

Thanks!

-Nobo

> Sent: Wednesday, November 26, 2014 1:38 AM
> To: Sam Aldrin
> Cc: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); [email-masked];
> [email-masked]
> > [resending as mailer complained, mail is too long; removed earlier
> > content as well)
> 
> > Keeping the solution aside, what makes it special that the use case
> > cannot be documented in 'use case' ID?
> 
> I would say it's the other way around: what makes S-BFD base and use-case
> so special that we separated them?
> 
> > Just a simple extension or not is different matter. Whether we should
> > be doing it with BFD (not just S-BFD) is more important and needs to
> > be discussed.
> 
> Interesting point.
> 
> 
> Regards, Marc