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

[Greg Mirsky <[e-mail]>]

Hi Alvaro,
my follow-up notes below tagged by GIM2>>.

Regards,
Greg

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

> On April 15, 2024 at 5:16:35 PM, Greg Mirsky wrote:
>
>
> Greg:
>
> ...
> > > (1) I-D.ietf-spring-mpls-anycast-segments
> ...
> > > 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?
>
> No.
>
> The mention in draft-ietf-idr-bgp-car is to describe "how Anycast SID
> complements and improves the scaling" of the CAR proposal.  It is not
> a definition, which is what you need.
>
GIM2>> You're right; the IDR document does not define an Anycast SID (and
has no reference to the document that does, but that is not our problem
now). Could we use RFC 8402  <https://datatracker.ietf.org/doc/rfc8402/> as
the informational reference? AFAICS, it defines an Anycast SID in
Terminology section through IGP-Anycast Segment construct:
   IGP-Anycast Segment: an IGP-Anycast segment is an IGP-Prefix segment
   that identifies an anycast prefix advertised by a set of routers.

   Anycast-SID: the SID of the IGP-Anycast segment.

>
>
>
> > > (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?
>
> If the dependency on I-D.ietf-mpls-bfd-directed is so strong, then the
> simpler way forward would be to change the status to Experimental (so
> they match).
>
> An alternative would be to change the status to Informational, and
> leave in the dependency to I-D.ietf-mpls-bfd-directed.  The downref
> rules only apply to documents on the standards track.
>
> The IANA registries have ranges that can be used by
> Informational/Experimental.
>
> In both cases, the only "strange" detail would be that the new
> registry would have a couple of "Standards Action" ranges, but I
> didn't see anything in rfc8126 that would prohibit that.
>
>
>
> > 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?
>
> The fact that I-D.ietf-mpls-bfd-directed is being processed as
> Experimental remains.
>
> The only two choices to leave the document "intact" is to change its
> intended status.
>
GIM2>> Thank you for the detailed explanation of the options in front of
us. Let us think about that and we'll get back with the next step.

>
>
> Alvaro.
>