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

[Ketan Talaulikar <[e-mail]>]

Hi John,

Thanks for your review and please check inline below for responses.


On Thu, Feb 17, 2022 at 3:09 AM 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.)
>

KT> This document follows the approach similar as taken for extending MPLS
EVPN RFC7432 by RFC8365.


>
> 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.
>

KT> I believe we are getting now into implementation aspects when you bring
up handling of attributes during redistribution from VPN tables into the
default table. We can add some text in the security considerations to
discuss this.


>
> 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.
>

KT> My co-author Robert has clarified. One other way to look at consensus
is based on the multivendor implementations, interoperability, and
deployments.


>
> 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.
>

KT> We will discuss this amongst the authors.

Thanks,
Ketan



>
>
> ----------------------------------------------------------------------
> 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.)
>
>
>
>