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

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Hi John

Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 (ietf.org)<https://mailarchive.ietf.org/arch/msg/idr/5KVXxHnyev4_IPEjLVHJmH4r1v8/>


Regards

Matthew

From: John Scudder via Datatracker <[e-mail]>
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)
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.)