Hi Alvaro, my follow-up notes below tagged by GIM2>>. Regards, Greg
On Mon, Apr 15, 2024 at 11:51 PM Alvaro Retana <aretana.i...@gmail.com> 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. >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
