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
