Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-bfd-directed-07

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 May 2021 09:05:17 -0700

Hi Jeff,
I've checked this discussion thread and realized that I've missed
highlighting updates that I've made following our discussion on the use of
the LSP Ping with BFD Discriminator TLV. Below, please find the text added
to Section 3.1:
NEW TEXT:

   The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
   session process described in Section 6 [RFC5884].  A system that
   supports this specification MUST support using the BFD Reverse Path
   TLV after the BFD session has been established.  If a system that
   supports this specification receives an LSP Ping with the BFD
   Discriminator TLV and no BFD Reverse Path TLV even though the reverse
   path for the specified BFD session has been established according to
   the previously received BFD Reverse Path TLV, the egress LSR MUST
   transition to transmitting periodic BFD Control messages as defined
   in Section 7 [RFC5884].

Please let me know if this text addresses your concerns.

Best regards,
Greg

On Mon, Jul 17, 2017 at 2:13 AM Jeffrey Haas <[email-masked]> wrote:

> On Mon, Jul 17, 2017 at 02:06:01AM -0700, Greg Mirsky wrote:
> > true, the RFC 5884 does not discuss handling of subsequent LSP Ping with
> > the same BFD Discriminator value in BFD Discriminator TLV. My reference
> to
> > RFC 5884 is to point that the default, implied path for the reverse
> > direction of the BFD session is over IP network and that how this draft
> > interprets BFD Reverse Path TLV with none- sub-TLVs included. And yes,
> > nodes that would support this draft MUST handle subsequent LSP Ping Echo
> > Request with BFD Discriminator and BFD Reverse TLVs.
> >
>
> I don't believe the procedure updating 5884 to change existing session
> properties is called out in the -directed document.  I don't have a strong
> opinion about the use case of whether such updates are desired or not.
> That's a decision for the MPLS WG.  However, I do think such procedure
> needs
> to be clear if it's desired.  This is part of Carlos' point.
>
> -- Jeff
>