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

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Wed, 17 Jun 2015 07:15:52 +0000

As one of the implementors of RFC 5884 and involved in the internal
discussions of the clarifications draft, I support to take the draft
further along.

Thanks
Srihari

On 25/05/15 3:43 pm, "Santosh P K" <[email-masked]> wrote:

>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.
>> Please suggest your thoughts on making the above text better.
>
>
>
>Thanks
>Santosh P K 
>
>> -----Original Message-----
>> 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]
>> Subject: RE: Working Group Last Call for
>>draft-ietf-bfd-rfc5884-clarifications
>> 
>> 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
>> 
>> > -----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
>> >
>> > 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
>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 17 Jun 2015 13:11:06 +0000

I support WGLC of this draft.

Regards
Mallik

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sun, 21 Jun 2015 21:58:00 +0000

Hi,

Support.

(Sorry for the delay)

-Nagendra

On 5/4/15, 3:58 PM, "Jeffrey Haas" <[email-masked]> wrote:

>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.
>
>-- Jeff and Nobo
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 23 Jun 2015 19:08:10 +0000

Jeff,

Late reply — I support advancing this document as it provides useful clarifications for RFC 5884.

Thanks,

— Carlos.

> On May 4, 2015, at 3:58 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> The BFD mailing list has been quiet since shortly after IETF 92.  We have a