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

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 13:39:34 -0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Feb 2022 23:02:08 +0100

Hi John,

As you have quoted my note in point #4 I feel that I need to comment on it.

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

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.

With that I think that #3 and #4 are no longer a concern.

Best regards,
Robert

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 13:49:53 +0530

Hi John,

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

> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/

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

> attacker a means of directing packets into a VPN customer’s internal

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.

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

> suggestions in RFC 7322 §4.1.1, of course.

KT> We will discuss this amongst the authors.

Thanks,
Ketan

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 17 Feb 2022 10:52:49 +0000

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 <[email-masked]>
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
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

(Emphasis added.)

---

From: John Scudder <[email-masked]>
Date: Thu, 17 Feb 2022 19:15:56 +0000

Thanks, Matthew. I didn’t think of searching for it under the individual submission name; when I read “cross-reviewed” I interpreted that as WGLC, not WG adoption. 

It looks to me as though there was no reply to the notification message you reference, do you agree? (Of course there might have been people who commented on the BESS list, but I don’t see anything cc’d to IDR.)

It does seem to me as though, considering the unusually close association between this spec and an active IDR draft, it would have made sense to cross-WGLC it, including a specific pointer to the overlap. I mean, I acknowledge that might have come to nothing since there’s considerable overlap between the groups — but it’s not universal overlap. Anyway, it’s water under the bridge now.

I’ve added the IDR chairs to the cc just in case any of them want to comment. 

Regards,

—John

> On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> 
> 
> 
> Hi John
>  
> [Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 (ietf.org)
>  
>  
> Regards
>  
> Matthew
>

---

From: John Scudder <[email-masked]>
Date: Fri, 18 Feb 2022 17:29:57 +0000

After sleeping on it I was too hasty in saying “water under the bridge” and moving on.

I’d like to request that you correct the oversight and seek input from IDR — what would have happened if the document had been cross-WGLC’d with IDR. Possibly this will result in no input (that happens sometimes) of course. But, if you start now, I don’t anticipate it will turn into the long pole for moving the document forward.

Thanks,

—John

On Feb 17, 2022, at 2:15 PM, John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>> wrote:

Regards,

—John

On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Hi John

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 (ietf.org<http://ietf.org>)

Regards

Matthew

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

Please refer to https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMMUd9RiSA$
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMPLJdcbPg$

https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMO5LL82ag$ :

(Emphasis added.)

Internet-Drafts, https://urldefense.com/v3/__https://www.ietf.org/how/ids/guidelines/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMPZa04p_w$ )

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Fri, 18 Feb 2022 17:44:06 +0000

Hi John

I’ll send a note to the IDR list requesting review - is a couple of weeks sufficient?

Matthew

________________________________
From: John Scudder <[email-masked]>
Sent: Friday, February 18, 2022 5:29:57 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; The IESG <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

Thanks,

—John

Regards,

—John

Hi John

Regards

Matthew

(Emphasis added.)

---

From: John Scudder <[email-masked]>
Date: Fri, 18 Feb 2022 17:49:38 +0000

Thanks. A couple weeks is just fine.

—John

On Feb 18, 2022, at 12:44 PM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Hi John

Matthew

________________________________
From: John Scudder <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 18, 2022 5:29:57 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

Thanks,

—John

Regards,

—John

Hi John

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 (ietf.org<https://urldefense.com/v3/__http://ietf.org__;!!NEt6yMaO-gk!UAh5UC9C3pEZ99I25B87VK1Y_8yOFxwZyUGOV2ltRjdC6YYdcDGRbEQ060DDuA$>)

Regards

Matthew

(Emphasis added.)

---

From: John Scudder <[email-masked]>
Date: Fri, 18 Feb 2022 20:32:03 +0000

Hi Ketan,

> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 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. 

Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI registry. Shouldn’t this be renamed? I mean, I guess it should have been renamed as of RFC 8365, but better late than never. I’m not sure quite what the name should become, but “MPLS-labeled” is manifestly wrong. Even “labeled” is wrong since the thing you’re stuffing in there isn’t a label. Since you’re the last one to touch it :-) if we can agree a better name for the SAFI I think it would be appropriate to add that to your IANA Considerations.

Thanks,

—John

P.S.: Thank you for your diplomacy in not pointing to RFC 9012 as your example of a prior use of this pattern. ;-)

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Feb 2022 22:48:26 +0100

Hi John,

Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI
> registry. Shouldn’t this be renamed? I mean, I guess it should have been
> renamed as of RFC 8365, but better late than never. I’m not sure quite what
> the name should become, but “MPLS-labeled” is manifestly wrong. Even
> “labeled” is wrong since the thing you’re stuffing in there isn’t a label.
> Since you’re the last one to touch it :-) if we can agree a better name for
> the SAFI I think it would be appropriate to add that to your IANA
> Considerations.
>

My suggestion would be: "VPN address & context"  or "Context & VPN address"

Thx,
R.

---

From: John Scudder <[email-masked]>
Date: Fri, 18 Feb 2022 22:19:39 +0000

Hi Ketan,

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

I don’t think we can sweep this easily under the “it’s an implementation detail” rug — the fact is, AFAIK this *is* what implementations do (redistribute optional transitive attributes from VPN to default tables). This “implementation detail” is not, itself, an issue for draft-ietf-bess-srv6-services. What it is, is a perspective on "Precaution should be taken to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain.” The argument was previously advanced that this is trivially achieved for VPN address families, I’m saying that’s not so, for the reasons given, and therefore the ramifications of leaks of the information you identify as sensitive, need to be considered (at minimum).

> We can add some text in the security considerations to discuss this.

Looking forward to seeing it, thank you.

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 18 Feb 2022 22:26:21 +0000

Hi Robert,

> On Feb 16, 2022, at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi John,
> 

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

> On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker <[email-masked]> wrote:

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Feb 2022 01:04:21 +0000

Further to this point:

> On Feb 18, 2022, at 3:32 PM, John Scudder <[email-masked]> wrote:
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Feb 2022 11:12:26 +0100

Hi John,

You have highlighted below a very important point. It was discussed among
co-authors, but perhaps not sufficiently during the BESS process as the
issue is really not a BESS WG problem.

In BGP protocol any new service deployment using existing AFI/SAFI is not
easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
NLRI attributes. Main reason being is that using capabilities only goes one
hop. In full mesh it all works perfect, but the moment you put RR in
between BGP speakers things are getting ugly as capabilities are not
traversing BGP nodes. /* Even in full mesh mixing transports for the same
service is a serious challenge for routers when say multihomes sites are
advertised from different PEs with different transport options */.

Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
sends a new format of the UPDATE messages. Well as today we also do not
have a notion of conditional capabilities (only send when received from
all) so if some of the RR peers do not support it you end up in partial
service. One can argue that in this case the only deterministic model is to
push the configuration from the management station and control partial
deployment of the new service from mgmt layer.

The natural alternative would be to never modify NLRI format once shipped
by RFC. When needed issue a new SAFI. Yes that is an option (and has always
been) but it also comes with its own set of issues. New SAFI is really
great to define for new service/feature etc ... Here however in the context
of this discussion we are changing transport for existing service.  And
just like it was the case with MPLS over UDP or  tunnel attribute etc ...
using a new SAFI would be very hard to deploy as there would need to be
well defined behaviour of BGP speakers receiving duplicate information for
the same VPN prefixes or receiving at one time only from single SAFI then a
bit later from the other one .. Of course one solution is to permit only
one SAFI for a given service at any given time, but that seems way too
restrictive too.

So to summarize while I am personally a huge proponent of new SAFI and new
capabilities to be defines for new service here I do have  some
reservations. It seems to me that deployment of new transport for VPN
service should be either network management driven or enabled when all
participating PEs support it. Enabling it automagically with one hop
capabilities seems to me like not a good thing as the data being sent in
the UPDATES is not optional and dropping it means dropping actual routes.

So at the current time the subject draft took a management approach.

Many thx,
Robert.

On Thu, Feb 24, 2022 at 2:04 AM John Scudder <[email-masked]> wrote:

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