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. > > (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. Alvaro. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
