Hi Ketan, > On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[email protected]> wrote: > >> 2. One area of concern I would have hoped IDR might have looked into is, the >> document makes a creative use of the MPLS Label field of the NLRI to carry >> the >> Function part of the SID. This means the SID is effectively split across the >> NLRI and the Prefix-SID attribute. What are the potential error modes if the >> Prefix-SID attribute should be lost from the route, while the NLRI is >> retained? >> >> (An obvious way of addressing this particular concern would be to define a >> new >> NLRI type with the desired semantics, instead of creatively repurposing >> fields >> within an existing NLRI type contrary to their definitions. Such an NLRI type >> would, for example, presumably state in its specification that if it was >> received without an accompanying Prefix-SID attribute, that would constitute >> an >> error.) >> > KT> This document follows the approach similar as taken for extending MPLS > EVPN RFC7432 by RFC8365.
I take it you’re referring to RFC 8365 §5.1.3 which talks about using the MPLS Label field (or MPLS1 Label field) to carry the VNI in the presence of a BGP Encapsulation Extended Community? Yes, that seems like a pretty close analogue. And given this particular trick is only with VPN-type address families one can also argue that there’s not a risk of affected routes leaking into the big-I Internet, which is the typical associated concern. Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI registry. Shouldn’t this be renamed? I mean, I guess it should have been renamed as of RFC 8365, but better late than never. I’m not sure quite what the name should become, but “MPLS-labeled” is manifestly wrong. Even “labeled” is wrong since the thing you’re stuffing in there isn’t a label. Since you’re the last one to touch it :-) if we can agree a better name for the SAFI I think it would be appropriate to add that to your IANA Considerations. Thanks, —John P.S.: Thank you for your diplomacy in not pointing to RFC 9012 as your example of a prior use of this pattern. ;-) _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
