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 >
