Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)

From: Marc Binderberger <[email-masked]>
Date: Mon, 1 Dec 2014 00:11:20 -0800

Hello Prasad and authors,

okay, I see our differences come from the wording and the interpretation of 
RFC5884. In section 1 you write ...

                                             [...] While Section 4 of
   [RFC5884] specifies that multiple BFD sessions can be established for
   a <MPLS FEC, LSP> tuple, [...]

... and I do not agree that 5884 make this statement for one LSP. For one FEC 
and "multiple alternate paths", yes. That's exactly the ambiguity you mention 
:-) : what does "multiple alternate paths" mean?  At the time RFC5884 was 
written you either had the ECMP decision at the ingress LSR - then you have 
different <egress label, interface>, i.e. LSPs - or you had to use explicit 
LSPs (plural) when the ECMP was somewhere along the path behind the ingress 
LSR.

A bit nitpicking from my side but I don't think your draft clarifies RFC5884, 
it adds new details (which is perfectly fine, IMHO).

Anyway, the procedure you describe in section 2.1 seems okay to me, although 
you create a new question:

                             [...] Since the BFD local discriminator of
      either ends cannot change as long as the session is in the UP
      state, a new discriminator received in the LSP ping unambiguously
      conveys the intent of the LSR ingress to bootstrap a new BFD
      session for the FEC specified in the LSP ping.

so how do I interpret a new discriminator when one of the other, already 
existing sessions, is in Down state?  My assumption is you want _always_ the 
interpretation above?

You also mention in section 1

                     [...] is useful in scenarios such as Segment
   Routing based LSPs or LSPs having Equal-Cost Multipath (ECMP).

maybe these scenarios are obvious to you but e.g. for Segment Routing, when 
would I want multiple BFD sessions for the same <FEC, LSP> ?  And when for 
ECMP?  This may be described in use-case documents - could you add references 
then?

For section 2.3 you write:

      The BFD session MAY be removed in the egress LSR if the BFD
      session transitions from UP to DOWN.  This can be done after the
      expiry of a configurable timer started after the BFD session state
      transitions from UP to DOWN at the egress LSR.

My guess is what you mean is if a session is long enough in Down state then 
one can assume it's being "obsolete" and remove it?  Or is there a reason to 
limit the removal procedure to sessions that have been in Up state before?

The other method in section 2.3 you describe as

      The BFD session on the egress LSR MAY be gracefully removed by the
      ingress LSR by using the BFD diagnostic code AdminDown(7)
      specified in [RFC5880].  When the ingress LSR wants to gracefully
      remove a session, it MAY transmit BFD packets containing the
      diagnostic code AdminDown(7) detectMultiplier number of times.
      Upon receiving such a packet, the egress LSR MAY remove the BFD
      session gracefully, without triggering a change of state.

Do you mean sending packets with state AdminDown and diagnostic code 7 or do 
you mean literally that the diagnostic code controls the removal alone, e.g. 
send detectMultiplier Up packets with diagnostic code 7 and the egress LSR 
still removes the session?

If the latter: this creates more questions, especially if the ingress LSR 
must keep the current state unchanged or if e.g. a state change on the 
ingress LSR to AdminDown together with a diagnostic code of AdminDown is 
something the egress LSR must support as well (in a graceful way, without 
triggering the client) ?

Regards, Marc

On Thu, 27 Nov 2014 12:54:53 +0000, Vengada Prasad Govindan (venggovi) wrote:
> Hello Marc,
>  Thank you for the note, please see replies inline marked with GVP1>. I 
> would be happy to discuss further comments you may have regarding the draft.
> Thanks
> Prasad
> 
> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc 
> Binderberger
> Sent: Wednesday, November 26, 2014 1:13 PM
> To: Jeffrey Haas
> Cc: [email-masked]
> Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends 
> December 12, 2014)
> 
> Hello Jeff et al.,
> 
> hmm. I'm not against the adoption of this draft as a workgroup draft but - 
> and I hope I don't step on anybodies toes - the draft seems to be in an 
> early stage. Nor can I see much of a discussion on this list about the 
> topic.
> 
> There are for sure some interesting aspects. If enough people consider the 
> BFD session removal as relevant for RFC5884 then we have a good reason as a 
> workgroup to move on.
> GVP1> The issue of BFD session removal at the egress is one of the issues 
> that the draft attempts to clarify. But more importantly clarifying the 
> mechanisms for establishing and maintaining multiple sessions per <FEC, 
> LSP> is the main motivation. Please see next point as well.
> 
>  I have my doubts about the multiple session per <FEC, LSP> as I don't see 
> how you tackle ECMP without multiple <LSP>. In other words while section 
> 2.1 may be a correct procedure for multiple BFD sessions I wonder what 
> problem you try to solve? Maybe this needs more discussion.
> GVP1> There are no new problems that this draft attempts to solve. In 
> particular, no claim is made to solve the problem of connectivity/ fault 
> monitoring for ECMP paths. However, the draft provides clarifies the 
> mechanisms to establish multiple sessions for the <FEC, LSP> already 
> specified in RFC5884. Some implementations assumed the presence of only one 
> session per <FEC, LSP> partly due to the notion that discriminators cannot 
> be changed after a session was established. This draft was an attempt at 
> clarifying these (mis)understandings.  Please note that the concept of 
> establishing multiple sessions to (possibly) track non-congruent paths was 
> outlined in RFC5884 itself. 
> ---snip from RFC5884---
>    If there are multiple alternate paths from an ingress LSR to an
>    egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to
>    determine each of these alternate paths.  A BFD session SHOULD be
>    established for each alternate path that is discovered.
> ---snip from RFC5884---
> 
> Long story short: while I can see this draft becoming a workgroup draft I 
> find the poll - well - premature.
> 
> 
> Regards, Marc
>  
> 
> 
> 
> On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote:
>> Working Group,
>> 
>> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was
>> presented at IETF-91 in Honolulu and was positively received.  We'd like to
>> ask the Working Group whether we should formally adopt this draft as a
>> Working Group item.
>> 
>> Please indicate your support or lack thereof to the mail list by 
>> December 12, 2014.  
>> 
>> Also, please supply feedback to the authors.  I believe the perception of
>> this document is that it's very nearly complete and thus should have a 
>> short
>> lifetime prior to publication as an RFC.
>> 
>> -- Jeff & Nobo.
>> 
>

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 2 Dec 2014 10:06:24 +0000

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Monday, December 01, 2014 1:41 PM
To: Vengada Prasad Govindan (venggovi)
Cc: Jeffrey Haas; [email-masked]
Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)

okay, I see our differences come from the wording and the interpretation of RFC5884. In section 1 you write ...

                                             [...] While Section 4 of

... and I do not agree that 5884 make this statement for one LSP. For one FEC and "multiple alternate paths", yes. That's exactly the ambiguity you mention
:-) : what does "multiple alternate paths" mean?  At the time RFC5884 was written you either had the ECMP decision at the ingress LSR - then you have different <egress label, interface>, i.e. LSPs - or you had to use explicit LSPs (plural) when the ECMP was somewhere along the path behind the ingress LSR.

A bit nitpicking from my side but I don't think your draft clarifies RFC5884, it adds new details (which is perfectly fine, IMHO).

so how do I interpret a new discriminator when one of the other, already 
existing sessions, is in Down state?  My assumption is you want _always_ the 
interpretation above?
GVP1> Agreed, the behavior need not be influenced by the state of the existing BFD session(s). The text in this section has scope for improvement. The egress node needs some freedom in accepting new session requests. It could apply policy to limit resources (e.g. pps budget, memory etc) being allocated to new session request. While the notion of applying the policy could be a local matter, the behavior of the egress LSR needs to defined for cases where the new discriminator request is not accepted. Could it simply drop the LSP Echo request until it is ready to create the BFD session? (I assume that the ingress LSR will continue re-transmission of the LSP ping for the new session until it becomes successful or give-up creating the BFD session after a given number of retries). Comments are welcome about this aspect. 

GVP1> I do not know if this draft is required to establish the need for multiple sessions per <FEC, LSP> since the base RFC5884 already saw the need for multiple sessions for the <FEC, LSP>. But, I will try and find references as you suggest. 

My guess is what you mean is if a session is long enough in Down state then 
one can assume it's being "obsolete" and remove it?  Or is there a reason to 
limit the removal procedure to sessions that have been in Up state before?
GVP> The intent here is to conserve resources by maintaining the optimal number of BFD sessions. Sessions that have transitioned from UP->DOWN and remained in DOWN are candidates for removal. Sessions that have always remained DOWN for a long enough time are also candidates for removal. However the latter is currently an open item (please see Sec 2.3, Ed Note).

GVP1> We do not intend to redefine states or diagnostic codes specified in RFC 5880. The draft proposes a method of gracefully removing the BFD sessions at the egress (from the LSR ingress) by sending packets with diag code 7, State=Down. If you think this text needs clarification or do not agree with the proposal, please let me know.

Regards, Marc

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 2 Dec 2014 10:07:06 +0000

Hello Marc,
  Sorry for pressing the send button early, please find a few replies inline with GVP1>
Thanks
Prasad

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) 
Sent: Tuesday, December 02, 2014 3:36 PM
To: 'Marc Binderberger'
Cc: Jeffrey Haas; [email-masked]
Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Monday, December 01, 2014 1:41 PM
To: Vengada Prasad Govindan (venggovi)
Cc: Jeffrey Haas; [email-masked]
Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)

                                             [...] While Section 4 of

Anyway, the procedure you describe in section 2.1 seems okay to me, although you create a new question:

so how do I interpret a new discriminator when one of the other, already existing sessions, is in Down state?  My assumption is you want _always_ the interpretation above?
GVP1> Agreed, the behavior need not be influenced by the state of the existing BFD session(s). The text in this section has scope for improvement. The egress node needs some freedom in accepting new session requests. It could apply policy to limit resources (e.g. pps budget, memory etc) being allocated to new session request. While the notion of applying the policy could be a local matter, the behavior of the egress LSR needs to defined for cases where the new discriminator request is not accepted. Could it simply drop the LSP Echo request until it is ready to create the BFD session? (I assume that the ingress LSR will continue re-transmission of the LSP ping for the new session until it becomes successful or give-up creating the BFD session after a given number of retries). Comments are welcome about this aspect. 

maybe these scenarios are obvious to you but e.g. for Segment Routing, when would I want multiple BFD sessions for the same <FEC, LSP> ?  And when for ECMP?  This may be described in use-case documents - could you add references then?

My guess is what you mean is if a session is long enough in Down state then one can assume it's being "obsolete" and remove it?  Or is there a reason to limit the removal procedure to sessions that have been in Up state before?
GVP> The intent here is to conserve resources by maintaining the optimal number of BFD sessions. Sessions that have transitioned from UP->DOWN and remained in DOWN are candidates for removal. Sessions that have always remained DOWN for a long enough time are also candidates for removal. However the latter is currently an open item (please see Sec 2.3, Ed Note).

Do you mean sending packets with state AdminDown and diagnostic code 7 or do you mean literally that the diagnostic code controls the removal alone, e.g. 
send detectMultiplier Up packets with diagnostic code 7 and the egress LSR still removes the session?
GVP1> We do not intend to redefine states or diagnostic codes specified in RFC 5880. The draft proposes a method of gracefully removing the BFD sessions at the egress (from the LSR ingress) by sending packets with diag code 7, State=Down. If you think this text needs clarification or do not agree with the proposal, please let me know.

Regards, Marc

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 7 Dec 2014 18:50:09 -0800

Hello Prasad,

sorry for my late reply. 

>   Sorry for pressing the send button early, please find a few replies 

:-)

> existing sessions, is in Down state?  My assumption is you want _always_ 
> the interpretation above?
> GVP1> Agreed, the behavior need not be influenced by the state of the 
> existing BFD session(s).

Ok.

> The text in this section has scope for 
> improvement. The egress node needs some freedom in accepting new session 
> requests. It could apply policy to limit resources (e.g. pps budget, memory 
> etc) being allocated to new session request. While the notion of applying 
> the policy could be a local matter, the behavior of the egress LSR needs to 
> defined for cases where the new discriminator request is not accepted. 
> Could it simply drop the LSP Echo request until it is ready to create the 
> BFD session? (I assume that the ingress LSR will continue re-transmission 
> of the LSP ping for the new session until it becomes successful or give-up 
> creating the BFD session after a given number of retries). Comments are 
> welcome about this aspect. 

I would be explicit and say that LSP ping must be send periodically when the 
state is not Up. Section 6.1 of 5884 seems to indicate this but if there is 
an agreement among implementors I would say so clearly.
In that case section 6

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.

can be updated to allow for the behaviour you describe. i.e. not sending a 
BFD packet if resources running low; I assume that is what implementations do 
anyway today?

> GVP1> I do not know if this draft is required to establish the need for 
> multiple sessions per <FEC, LSP> since the base RFC5884 already saw the 
> need for multiple sessions for the <FEC, LSP>. But, I will try and find 
> references as you suggest. 

As I said I disagree with the interpretation that 5884 talks about multiple 
sessions per <FEC, LSP>. But that's not my point here: you shortly mention SR 
and ECMP but without a bit more details or references I found this not very 
helpful, actually.

And while no draft is required to establish a reason for it's existence it's 
usually done ;-)

> GVP> The intent here is to conserve resources by maintaining the optimal 
> number of BFD sessions. Sessions that have transitioned from UP->DOWN and 
> remained in DOWN are candidates for removal. Sessions that have always 
> remained DOWN for a long enough time are also candidates for removal. 
> However the latter is currently an open item (please see Sec 2.3, Ed Note).

okay, can you shed some light on the Ed Note? What is the problem with 
sessions that haven't been Up?  As you say yourself, if they are long enough 
Down they are also candidates for removal.

> Do you mean sending packets with state AdminDown and diagnostic code 7 or 
> do you mean literally that the diagnostic code controls the removal alone, 
> e.g. 
> GVP1> We do not intend to redefine states or diagnostic codes specified in 
> RFC 5880.

Good ;-)

> The draft proposes a method of gracefully removing the BFD 
> sessions at the egress (from the LSR ingress) by sending packets with diag 
> code 7, State=Down.

Wasn't obvious to me you talk about state=Down. Actually, I would have 
expected a state of AdminDown for a graceful shutdown (RFC5882, section 3.2)

> If you think this text needs clarification or do not 
> agree with the proposal, please let me know.

I would expect more details, like the state you expect to be sent. And I 
would have thought of AdminDown, not Down.

A nitpick but as we discuss this:

"the egress LSR MAY remove the BFD session gracefully"

I guess you want the say the LSR MAY remove the BFD session and that such a 
removal should be done gracefully? The "may" is about the removal, not the 
gracefullness?

Thanks & Regards,
Marc

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 9 Dec 2014 16:19:13 +0000

Hello Jeff/ WG,
  Support the adoption of this document as co-author.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 26, 2014 6:20 AM
To: [email-masked]
Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)

Working Group,

Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was presented at IETF-91 in Honolulu and was positively received.  We'd like to ask the Working Group whether we should formally adopt this draft as a Working Group item.

Please indicate your support or lack thereof to the mail list by December 12, 2014.  

Also, please supply feedback to the authors.  I believe the perception of this document is that it's very nearly complete and thus should have a short lifetime prior to publication as an RFC.

-- Jeff & Nobo.

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 10 Dec 2014 16:16:16 +0000

Hello Jeff,
   I am not aware of any IPR related to this draft.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Saturday, November 29, 2014 1:14 AM
To: [email-masked]
Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014))

The chairs would like to take this opportunity to remind everyone that if you have IPR on this Internet-draft - or any other draft - to disclose it as soon as possible.

-- Jeff & Nobo

On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote:
> Working Group,
> 
> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, 
> was presented at IETF-91 in Honolulu and was positively received.  
> We'd like to ask the Working Group whether we should formally adopt 
> this draft as a Working Group item.
> 
> Also, please supply feedback to the authors.  I believe the perception 
> of this document is that it's very nearly complete and thus should 
> have a short lifetime prior to publication as an RFC.
> 
> -- Jeff & Nobo.

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 10 Dec 2014 08:48:03 -0800

Not aware of any IPR related to this draft.

-sam
> On Dec 10, 2014, at 8:16 AM, Vengada Prasad Govindan (venggovi) <[email-masked]> wrote:
> 
> Hello Jeff,

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 11 Dec 2014 02:33:33 +0000

I am not aware of any IPR that is related to this draft.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Saturday, November 29, 2014 3:44 AM
To: [email-masked]
Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014))

-- Jeff & Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 11 Dec 2014 02:41:56 +0000

I am not aware of any IPR that applies to this document.

Thanks!

-Nobo

> Sent: Friday, November 28, 2014 2:44 PM
> To: [email-masked]
> The chairs would like to take this opportunity to remind everyone that if
> you have IPR on this Internet-draft - or any other draft - to disclose it as soon
> as possible.
> 
> -- Jeff & Nobo
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 17 Dec 2014 15:38:31 -0500

> Please indicate your support or lack thereof to the mail list by 

[This chair is rather behind in his IETF email. Sorry.]

We had good response along with the feedback in the room during the IETF
session.  This document is adopted as a WG item.

Authors, please re-submit as draft-ietf-bfd-rfc5884-clarifications.  Also,
please consider what a reasonable milestone would be for completing the work
in this draft.

-- Jeff