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

[John Scudder <[e-mail]>]

Hi Robert,

> On Feb 16, 2022, at 5:02 PM, Robert Raszuk <[e-mail]> 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 <[e-mail]> 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.)
>> 
>> 
>> 
>