Hi Robert, > On Feb 16, 2022, at 5:02 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > Hi John, > > As you have quoted my note in point #4 I feel that I need to comment on it.
Thank you for doing so! > So yes original discussions and major contributions of this work were > focusing on VPN use case and I admit when carefully re- reading it to find > some text there beyond VPN use case. > > So we discussed it among co-authors. The point of adding 5.3 & 5.4 is > targeting the networks where Internet routes are not present at each node and > network uses summarization of infrastructure routes (no end to end /128 > leaking in the IGP). > > The text perhaps may require some clarification that use of SAFI 1 is left > for the operators to choose if the attribute should be attached to Internet > routes - when operator is offering an IP transit or it can be attached just > to next hops which are part of the infrastructure. Let's also not forget that > if this is IP transit in most networks you can reach all hops along the path > anyway (modulo transit SP/ISP policy). It’s not 100% clear from your reply, so let me try to paraphrase and you can correct any misunderstandings: you’re now in agreement that Sections 5.3 and 5.4 should be retained, provided that some clarification (that you briefly sketch above) is added to the document. Should we expect a revision with the clarifications you are talking about? Assuming that’s the plan, I agree this point can be closed pending the revised text. > I think major concern expressed from Warren was the potential compromise to > the VPNs when SID demuxing it would leak. Well as we know SAFI 128 or 70 are > not public. Yes customer may advertise his routes to SAFI 1 and leak but no > one has control over it and it is orthogonal to what happens in the SP > network. This is discussed in my previous reply, to Ketan. Thanks, —John > With that I think that #3 and #4 are no longer a concern. > > Best regards, > Robert > > > On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker > <nore...@ietf.org> wrote: >> John Scudder has entered the following ballot position for >> draft-ietf-bess-srv6-services-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> 1. The shepherd writeup for this document says “It also received an RTG DIR >> review and cross-reviewed with the IDR working group”. Searching in my IDR >> inbox and the IDR mailing list archives, I don’t find any sign of the >> cross-review — can you please point me to it? >> >> 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.) >> >> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent >> discussion turned quickly to the assertion that no, they don’t, in VPN >> address >> families. Let’s accept that claim for the sake of conversation. It’s still >> the >> case that sometimes (often?) routes are distributed from VPN address families >> into the Global Internet table. When this is done, by default, all the path >> attributes come along for the ride. Anyone who thinks this is just a >> hypothetical case might want to look back to (for example) significant >> network >> outages that were caused around a decade ago by leakage of BGP Attribute 128 >> (ATTR_SET, RFC 6368) into the global Internet. >> >> The SIDs contained in these if-they-were-to-leak routes potentially give an >> attacker a means of directing packets into a VPN customer’s internal network. >> >> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG] >> consensus”; however, there doesn’t seem to be consensus even amongst the >> authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly >> fundamental disagreement! An illustration of the disagreement is >> https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/: >> >> “So I can see why some people may have thought oh since transport in SRv6 >> comes >> for free let's load it with services in an attribute and be done. Yes I can >> see >> that flattening this make it potentially easier (one less SAFI to enable), >> *but >> I am not sure we have reached a broad agreement here.* This comes as a >> consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format >> and new SAFI) to an attribute.” >> >> (Emphasis added.) >> >> It's of course possible for an author to be in the rough as regards >> consensus, >> just as any other WG contributor, but it's a little unusual, and this >> disagreement doesn't even seem to have been previously aired. For this >> reason, >> I have to question the strength of the consensus behind this document, and >> ask >> the WG chairs to weigh in regarding whether consensus on at least this point >> needs to be checked before we proceed forward. >> >> 5. Finally, I have to question the length of the author list. As I’m sure you >> know, the guidance is to limit author lists to no more than five, other than >> under unusual circumstances. I would have expected to find an explanation of >> the circumstances around the author list of this document in the shepherd >> writeup; there is none. (It’s a specific check item in Guidelines to Authors >> of >> Internet-Drafts, https://www.ietf.org/how/ids/guidelines/) >> >> The easiest way to resolve this would be to trim the author list per the >> suggestions in RFC 7322 §4.1.1, of course. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1. I support Warren Kumari’s DISCUSS. >> >> 2. (Further comments TBD and I apologize for not providing them now; I wanted >> to get this sent off though.) >> >> >> > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
