I support WGLC of this draft. Regards Mallik
On 17/06/15 12:45, "Srihari Raghavan (srihari)" <[email protected]> wrote: >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 protected]> 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 protected]] >>> Sent: Wednesday, May 20, 2015 6:12 PM >>> To: Santosh P K; [email protected] >>> Cc: Jeffrey Haas; Nobo Akiya; [email protected] >>> 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 protected]] >>> Sent: Thursday, May 14, 2015 7:44 PM >>> To: [email protected] >>> 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 protected]] On Behalf Of Jeffrey >>> > Haas >>> > Sent: Tuesday, May 05, 2015 1:28 AM >>> > To: [email protected] >>> > Cc: [email protected] >>> > 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 >> >
