Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Ketan,

> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[e-mail]> 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. ;-)