Subject: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 May 2015 15:58:05 -0400

The BFD mailing list has been quiet since shortly after IETF 92.  We have a
number of documents that seem stable and ready to advance.

This email begins a two week Working Group Last Call for
draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884.

This last call will end on May 15.

Simultaneously, the authors of this draft should state to the mailing list
whether there is any IPR associated with this draft or not.

This WGLC is also being cc'd to mpls@ietf to permit additional commentary.

-- Jeff and Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 May 2015 19:59:08 +0000

I'm not aware of any IPR related to this document.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, May 04, 2015 12:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

The BFD mailing list has been quiet since shortly after IETF 92.  We have a number of documents that seem stable and ready to advance.

This email begins a two week Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884.

Simultaneously, the authors of this draft should state to the mailing list whether there is any IPR associated with this draft or not.

-- Jeff and Nobo

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 5 May 2015 02:20:55 +0000

I am not aware of any IPR related to this document.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, May 05, 2015 1:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

-- Jeff and Nobo

---

From: Nobo Akiya <[email-masked]>
Date: Wed, 6 May 2015 21:37:38 -0700

Hi Jeff,

Thanks!

-Nobo

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 15 May 2015 16:26:04 -0400

We've gotten good responses about IPR declarations.  However, there have no
comments about support for last call. :-)

As this is likely an oversight, the last call will continue for another
several days.

Note that Santosh PK has submitted some comments that will need to be
addressed prior to the document moving forward.

-- Jeff

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 20 May 2015 12:41:57 +0000

Hello Santosh,
  Thanks for your careful review. You bring up a valid point, that needs clarification. Even without multiple BFD sessions on the <FEC, LSP> if the egress were to inform about a BFD session going to DOWN (potentially using the diag code 0x4 - Neighbor Signalled Down), the YourDisc field needs to be non-zero, so the ingress can demux the packet to the correct session. With multiple sessions per FEC, LSP, this becomes absolutely needed, as you remark below. Could we consider adding the following statement:
The egress MUST use the discriminators exchanged when the session was brought to indicate a session DOWN back to the ingress. The egress SHOULD reset this to zero after transmitting detectMult number of packets.
Please suggest your thoughts on making the above text better.
Thanks
Prasad
Copying the list for their inputs as well.

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Thursday, May 14, 2015 7:44 PM
To: [email-masked]
Cc: Jeffrey Haas; Nobo Akiya
Subject: RE: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications

Hello Authors,
     Sorry for being so late in the game. I had few points which are not clear from draft. 

As per RFC 5880 section 6.8.1 it says that when BFD session goes down due to control timer expiry then remote discr MUST be set to 0. 

<SNIP>
"   bfd.RemoteDiscr

      The remote discriminator for this BFD session.  This is the
      discriminator chosen by the remote system, and is totally opaque
      to the local system.  This MUST be initialized to zero.  If a
      period of a Detection Time passes without the receipt of a valid,
      authenticated BFD packet from the remote system, this variable
      MUST be set to zero."

<SNIP>

As per RFC 5884 it says that all the demux MUST happen with remote Discriminator and also it talks about Discr not changing only when session is UP.

<SNIP>
Section 7:

   Note that once the BFD session for the MPLS LSP is UP, either end of
   the BFD session MUST NOT change the source IP address and the local
   discriminator values of the BFD Control packets it generates, unless
   it first brings down the session.
<SNIP>

As per  clarification draft " draft-ietf-bfd-rfc5884-clarifications" section 2.4 iterates the same statement. 

<SNIP>
Section 2.4:

The discriminators of a BFD session established over an MPLS LSP
   cannot be changed when it is in UP state.
<SNIP>

Problem:

Now for example if we have multiple LSP's with the same FEC  then at egress it might be sending packet to same designation address. In this case if one of the BFD session goes down on egress then it would send BFD packet with down state with 0 discr. Seeing this ingress would try to demux with IFL and source address on the packet, this will lead to multiple sessions. I think this needs to be clarified as well.

I am not sure if this point is already covered or not. Do you think it is worth clarifying this point? I think it plays very important role in bringing down the BFD session in MPLS environment. Any thoughts? 

Thanks
Santosh P K 

> The BFD mailing list has been quiet since shortly after IETF 92.  We 
> have a number of documents that seem stable and ready to advance.
> 
> draft-ietf-bfd- rfc5884-clarifications-01, Clarifications to RFC 5884.
> 
> Simultaneously, the authors of this draft should state to the mailing 
> list whether there is any IPR associated with this draft or not.
> 
> This WGLC is also being cc'd to mpls@ietf to permit additional 
> commentary

---

From: IETF <[email-masked]>
Date: Thu, 21 May 2015 12:12:53 -0700

Sorry for the delayed response.

Support the last call of this draft.

-sam
> On May 4, 2015, at 12:58 PM, Jeffrey Haas <[email-masked]> wrote:
>

---

From: Santosh P K <[email-masked]>
Date: Mon, 25 May 2015 10:13:36 +0000

Prasad,
    Sorry for delayed response. Below text looks good to me. 

> The egress MUST use the discriminators exchanged when the session was
> brought to indicate a session DOWN back to the ingress. The egress SHOULD
> reset this to zero after transmitting detectMult number of packets.

Thanks
Santosh P K 

> From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]]
> Sent: Wednesday, May 20, 2015 6:12 PM
> To: Santosh P K; [email-masked]
> Cc: Jeffrey Haas; Nobo Akiya; [email-masked]
>   Thanks for your careful review. You bring up a valid point, that needs
> clarification. Even without multiple BFD sessions on the <FEC, LSP> if the
> egress were to inform about a BFD session going to DOWN (potentially using
> the diag code 0x4 - Neighbor Signalled Down), the YourDisc field needs to be
> non-zero, so the ingress can demux the packet to the correct session. With
> multiple sessions per FEC, LSP, this becomes absolutely needed, as you
> remark below. Could we consider adding the following statement:
> The egress MUST use the discriminators exchanged when the session was
> brought to indicate a session DOWN back to the ingress. The egress SHOULD
> reset this to zero after transmitting detectMult number of packets.
> As per RFC 5880 section 6.8.1 it says that when BFD session goes down due to
> control timer expiry then remote discr MUST be set to 0.
> 
> <SNIP>
> "   bfd.RemoteDiscr
> 
> As per RFC 5884 it says that all the demux MUST happen with remote
> Discriminator and also it talks about Discr not changing only when session is
> UP.
> 
> <SNIP>
> Section 7:
> 
> Now for example if we have multiple LSP's with the same FEC  then at egress
> it might be sending packet to same designation address. In this case if one of
> the BFD session goes down on egress then it would send BFD packet with
> down state with 0 discr. Seeing this ingress would try to demux with IFL and
> source address on the packet, this will lead to multiple sessions. I think this
> needs to be clarified as well.
> 
> I am not sure if this point is already covered or not. Do you think it is worth
> clarifying this point? I think it plays very important role in bringing down the
> BFD session in MPLS environment. Any thoughts?
> 
> 
> Thanks
> Santosh P K
>