Greg,
> On Aug 11, 2017, at 2:12 PM, Greg Mirsky <gregimir...@gmail.com> wrote:
>
> Re-sending to the corrected list (apologies for duplicates).
>
> Dear All,
> I suggest to reject this proposal. The current text is clear and the
> mechanics of bootstrapping BFD session over MPLS LSP is well understood -
> remote peer MUST start sending BFD control packets first and BFD peer MAY
> send Echo Reply with its Local Discriminator as value in BFD Discriminator
> TLV.
>
This seems to repeat the text in 5884 without explaining why you feel a
particular interpretation is the correct technical one.
The text you include:
“MAY send Echo Reply with its Local Discriminator as value in BFD
Discriminator TLV”
suffers from the ambiguity that this Errata is trying to clarify. Which one is
it?
* (MAY send Echo Reply with its Local Disc)
* (MAY send Echo Reply), with its Local Disc.
The actual text is:
The egress LSR MAY respond with an LSP Ping Echo
! reply message that carries the local discriminator assigned by it for
the BFD session.
And NOT:
The egress LSR MAY respond with an LSP Ping Echo
! reply message, which carries the local discriminator assigned by it for
the BFD session.
Based on restrictive versus non-restrictive clause, I feel it is correct to
accept the errata.
And by the way, RFC 5884 is not say what happens if the LSP Ping Reply has a
different discriminator value!
Thanks,
Carlos.
> Regards,
> Greg
>
>
> On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <jh...@pfrc.org> wrote:
> [Note that I have adjusted the addresses in the headers to try to catch the
> RFC authors' current accounts.]
>
>
> The 5884 interop issue keeps bubbling up. Balaji submitted an errata, which
> provides us with a good place to start technical discussion.
>
> Please note I also spent some time off-list discussing this errata with
> Balaji.
>
>
> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> > Section: 6
> >
> > Original Text
> > -------------
> > The egress LSR MAY respond with an LSP Ping Echo
> > reply message that carries the local discriminator assigned by it for
> > the BFD session.
> >
> > Corrected Text
> > --------------
> > The egress LSR MUST respond with an LSP Ping Echo reply message that
> > MAY carry the local discriminator assigned by it for the BFD session.
> >
> >
> > Notes
> > -----
> > It is not clear from the original text which of the following is optional:
> > - The egress MUST send a reply, but the discriminator in the reply is
> > optional
> > - The reply itself is optional
> >
> > Technically, the reply cannot be optional, because the egress needs to
> > report LSP-Ping verification status to the ingress.
> >
> > The proposed text recommends to include BFD discriminator in the reply.
> > This was the intent of the original text.
>
> My opinion follows:
>
> In section 6 -
>
> : On receipt of the LSP Ping Echo request message, the egress LSR MUST
> : send a BFD Control packet to the ingress LSR, if the validation of
> : the FEC in the LSP Ping Echo request message succeeds. This BFD
> : Control packet MUST set the Your Discriminator field to the
> : discriminator received from the ingress LSR in the LSP Ping Echo
> : request message. The egress LSR MAY respond with an LSP Ping Echo
> : reply message that carries the local discriminator assigned by it for
> : the BFD session. The local discriminator assigned by the egress LSR
> : MUST be used as the My Discriminator field in the BFD session packets
> : sent by the egress LSR.
>
> In the text above, I consider it quite clear that the receipt of the BFD
> packet contains sufficient state to bring up the BFD session. The receipt
> of the same Discriminator in the LSP Ping Echo Reply is optional.
>
> This makes sense partially because the reply may be dropped and we want the
> BFD session to come up as fast as possible.
>
> The point of contention appears to be what to do if we *never* get such
> replies. It's worth pointing out additional text in RFC 5884, section 3.2.
>
> : Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
> : detection:
> :
> : i) LSP Ping is used for bootstrapping the BFD session as described
> : later in this document.
> :
> : ii) BFD is used to exchange fault detection (i.e., BFD session)
> : packets at the required detection interval.
> :
> : iii) LSP Ping is used to periodically verify the control plane
> : against the data plane by ensuring that the LSP is mapped to
> : the same FEC, at the egress, as the ingress.
>
> iii above reminds us that the LSP may be torn down because LSP Ping fails.
> Thus, it seems problematic that we do not get a reply ever.
>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up. Thus we have contradictory intent.
>
> ---
>
> My opinion is that the MAY in the RFC 5884 procedures is intended to have
> the BFD session come up by the most expedient means. I do not believe the
> likely intent was to say "don't send Echo Reply". Among other things, that
> seems contrary to the intent of the general LSP Ping procedures.
>
> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.
>
> -- Jeff
>
>
—
Carlos Pignataro, car...@cisco.com
“Sometimes I use big words that I do not fully understand, to make myself sound
more photosynthesis."
