Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

[Greg Mirsky <[e-mail]>]

Hi Alvaro,
thank you for your analysis and detailed questions. Please find my notes
below tagged GIM>>.

Regards,
Greg

On Mon, Apr 15, 2024 at 5:48 PM Alvaro Retana <[e-mail]>
wrote:

> On January 27, 2024 at 3:00:04 PM, Greg Mirsky wrote:
>
>
> Greg/authors:
>
> Hi!
>
> > The draft is stable, and the authors believe that it is ready for the WG
> LC.
> > We appreciate your consideration of moving this work forward to the WG
> LC.
>
>
> I took a quick look at this document, and we need to address a couple
> of dependency-issues before moving closer to WGLC.
>
> [I will provide a more detailed review as we move forward.]
>
>
> (1) I-D.ietf-spring-mpls-anycast-segments
>
> I-D.ietf-spring-mpls-anycast-segments is listed as an Informative
> reference, but it needs to be Normative because it is required in §2:
>
>    If the target segment is an anycast prefix segment
>    ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast
>    SID MUST be included in the Target TLV as the very last sub-TLV.
>    Also, for BFD Control packet the ingress SR node MUST use precisely
>    the same label stack encapsulation, especially Entropy Label
>    ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV
> that bootstrapped the BFD session. Other operational aspects of using
> BFD
>    to monitor the continuity of the path to the particular Anycast SID,
>    advertised by a group of SR-MPLS capable nodes, will be considered in
>    the future versions of the document.
>
> I-D.ietf-spring-mpls-anycast-segments expired almost 4 years ago! :-(
>
> Before we try to revive it, is the reference needed?  This paragraph
> is the only one that talks about anycast.  Also, it sounds (from the
> last sentence) as if more could be said about anycast, so perhaps all
> the considerations can be handled in a future document. (?)
>

GIM>> I somehow missed that in idnits report. Apologies. I've looked up any
current IETF document that references the Anycast SID.  The only one I have
found is in Section 5.5 of draft-ietf-idr-bgp-car
<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-car/07/>. Would
changing the reference to that draft address your concern?

>
>
> (2) I-D.ietf-mpls-bfd-directed
>
> I-D.ietf-mpls-bfd-directed is a Normative reference and is listed as
> one of the options in §3 (Use BFD Reverse Path TLV over Segment Routed
> MPLS Tunnel).  However, that document is Experimental, and this one is
> on the standards track.
>
> While downrefs are possible, using I-D.ietf-mpls-bfd-directed is
> premature.  Not only has the document not become an RFC yet, allowing
> for experience on the experiment to be collected, but the reason for
> its Experimental status is precisely that the "return path that this
> session might be less stable than the
> tunnel being tested" [1].
>
> Is the reference required?
>
GIM>> In my opinion, if we remove that reference and all that is anchored
on it, then the document should be changed to Informational because we have
taken out the Non-FEC TLV and all the IANA requests. Do you see any
reasonable way forward with that reference? On a somewhat brighter side,
draft-ietf-mpls-bfd-directed is close to IESG Telechat. And I don't agree
(although that is in Shepherd's review) with the "return path that this
session might be less stable than the tunnel being tested," as that came
from RtgDir's early review without any substantive evidence but as a
personal assertion. The reverse path is likely another tunnel that is no
less stable than the one chosen in the forwarding direction. Also, the
reported implementation has been in service for several years without any
problems reported. What would you suggest we do?

>
>
> Thanks!
>
> Alvaro.
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/shepherdwriteup/
>