Further to this point: > On Feb 18, 2022, at 3:32 PM, John Scudder <j...@juniper.net> wrote: > >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <ketant.i...@gmail.com> 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.
In a separate reply, the authors of draft-lz-bess-srv6-service-capability-02 pointed out that it provides a critique of bess-srv6-services which is similar to this discuss point. (The authors dropped the IESG from the cc, so I’m following up here instead of to their original note.) On first reading, the critique in draft-lz-bess-srv6-service-capability-02 seems well argued and responsive to my question above about potential error modes. In section 3 of their draft, the authors provide a worked scenario where a VPN route carrying a SRv6 service SID using the Transposition scheme, if received by an MPLS-only PE, could result in misdelivered traffic. At minimum, that seems worth surfacing in the Security Considerations section, since historically we’ve considered misdelivered VPN traffic to be a Bad Thing that could expose confidential information. The authors do acknowledge that bess-srv6-services proposes a mitigation: To avoid these problems, [I-D.ietf-bess-srv6-services] specifies that implementations SHOULD provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis. but they go on to argue that this mitigation isn’t fit for purpose: The above method may be feasible in small-scale networks, but are not applicable to large-scale networks. [etc] It’s not my preference to get into the minutiae of this argument as part of this discuss. However, I’d like to ask: was this consideration something the WG discussed? I looked for discussion of draft-lz-bess-srv6-service-capability in the archives and didn’t find much — - When an earlier version was posted to the list it resulted only in discussion between the original author, Liu Yao, and Eduard Metz, who became co-author, but there wasn’t any discussion I saw of the actual issue that the draft identified, but rather refinement of the mitigation it proposes (which I don’t want to discuss in this note). - There was an agenda slot request for the draft at IETF-111. It was on the agenda in the “if time allows” section. I assume time did NOT allow because I don’t see mention of it in the minutes. (I did find the slides, slides 3 and 4 summarize the critique, https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-srv6-service-capability-00). But of course, the issue raised might have been discussed by the WG in a different thread, that doesn’t match a search for draft-lz-bess-srv6-service-capability. If so, I’d appreciate a pointer to it. If there wasn’t any discussion in the WG of the authors’ critique, I think it deserves to be discussed a bit as part of this thread. In particular, does the “this is the same as the trick EVPN does in RFC 8365” reply apply equally? Probably it does, although that might boil down to “gosh, we should have caught this when publishing 8365, shouldn’t we?” Even if the outcome of the discussion is that the limitation was discussed by the WG/isn’t a big deal because reasons/maybe it’s a big deal but we’ll fix it in a followup… as I mentioned earlier, covering it in the Security Considerations seems worthwhile. Thanks, —John _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
