> On Aug 15, 2017:11:20 AM, at 11:20 AM, Kireeti Kompella <kire...@juniper.net>
> wrote:
>
> As a co-author, I can say that the intent was that the LSP ping reply be
> sent, but the BFD discriminator be optional. Not sending an LSP ping reply
> could lead to the LSP being torn down.
>
> The basic idea here is to use LSP ping to bootstrap a bfd session. But the
> semantics of LSP ping don't change; not sending a reply indicates that the
> LSP is down.
>
> Kireeti
That is exactly my recollection of how we designed (and implemented)
this too.
—Tom
>
>> On Aug 11, 2017, at 10:39, 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
