BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
draft-ietf-bess-srv6-services-15

[Ballot comment]
Thanks for working through the issues in my DISCUSS. While I continue to be unexcited about the failure modes discussed in #2, I accept that this is long-standing practice. I hope we might aspire to do better in the future.

---old discuss for posterity:

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

[Ballot comment]
Thanks for working through the issues in my DISCUSS.

---old discuss for posterity:

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

[Ballot comment]
Having received a response to my DISCUSS, it's apparently common practice in this area to have routers be non-interoperable without a priori knowledge of neighbor capabilities. I still support John Scudder's second DISCUSS, but if he's happy, I'm happy.

This document was very difficult to follow without a thorough grounding in the references, but I managed to have some comments anyway:

- I support John Scudder's second DISCUSS.

- Please expand VRF, SLA, RIB, NLRI, and all other acronyms on first use.

(3.2.1) "      The Transposition Offset MUST be less than LBL+LNL+FL+AL

      The sum of Transposition Offset and Transposition Length MUST be
      less than LBL+LNL+FL+AL"

The second condition makes the first redundant for all Transposition Length >= 0!
It makes me think there's a typo.

(5) and (6) "The SRv6 Service SID SHOULD be routable within the AS of the egress
  PE"

SHOULD? Under what circumstances would it be OK for it not to be routable? [I see Alvaro also commented on this, but I'd like to call out that Sec 6 does the same thing]

[Ballot comment]
With the updated text in the Security Considerations in Version 12, I'm clearing my DISCUSS.

I still don't love this (hence the Abstain), but my disquiet is caused caused by the security considerations in SRv6, not this document itself.

I'd like to specifically call out and thank Ketan Talaulikar, who did an outstanding job at communicating, addressing the concerns, and defusing the situation in general.

[Ballot comment]
Hi,

Thanks for this document.  I have no comments on this document that haven't previously been captured in other ballot positions.

I find the security section in the latest revision of the document to be significantly improved and more helpful than the previous telechat revision, so thank you for your efforts in this regard.

Rob

[Ballot discuss]
(3.2.1)
"BGP speakers that do not support this specification may misinterpret,
  on the reception of an SRv6-based BGP service route update, the part
  of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
  for MPLS-based services.  Implementations supporting this
  specification MUST provide a mechanism to control the advertisement
  of SRv6-based BGP service routes on a per-neighbor and per-service
  basis.  The details of deployment designs and implementation options
  are outside the scope of this document."

The idea that BGP hosts are going to be made non-interoperable because you're re-purposing the MPLS label, and so hosts are just going to have to remember who it's OK to exchange this TLV with, sounds unsatisfactory to me. Is there no way to negotiate this? Perhaps the solution John Scudder proposes in his second DISCUSS would solve this problem too: just have a new type for these overloaded MPLS labels.

[Ballot comment]
This document was very difficult to follow without a thorough grounding in the references, but I managed to have some comments anyway:

- I support John Scudder's second DISCUSS.

- Please expand VRF, SLA, RIB, NLRI, and all other acronyms on first use.

(3.2.1) "      The Transposition Offset MUST be less than LBL+LNL+FL+AL

      The sum of Transposition Offset and Transposition Length MUST be
      less than LBL+LNL+FL+AL"

The second condition makes the first redundant for all Transposition Length >= 0!
It makes me think there's a typo.

(5) and (6) "The SRv6 Service SID SHOULD be routable within the AS of the egress
  PE"

SHOULD? Under what circumstances would it be OK for it not to be routable? [I see Alvaro also commented on this, but I'd like to call out that Sec 6 does the same thing]

[Ballot discuss]
I have little to add to the DISCUSSes held by others beyond my support.

However, I would like to discuss having SRv6 control plane information, i.e.
SIDs and their behaviours etc., being isolated by associating it with
a separate SAFI.  Any other protocol element that needs to refer to such
information can make reference to it through context-appropriate extensions.

{AFI=IPv6, SAFI=unicast} is a valid way to advertise an SRv6 locator prefix,
for example, as that's just IPv6 forwarding information.  If SRv6-specific
information where separately advertised as {AFI=IPv6, SAFI=SRv6} then I
suspect it would be simpler to filter out that information, detect leaks,
and generally help the SRv6 domain fail closed more easily.

But I'm prepared to learn why this wouldn't work or would be somehow worse.

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

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

Considering that the disagreement is amongst the authors and not just WG contributors at large, 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.

[Ballot 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

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

Considering that the disagreement is amongst the authors and not just WG contributors at large, 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.

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

Considering that the disagreement is amongst the authors and not just WG contributors at large, 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.

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

Considering that the disagreement is amongst the authors and not just WG contributors at large, 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.

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

[Ballot comment]
Thank you to Joseph Salowey for the SECDIR review.

Thank you to the authors for the implementation report pointer (draft-matsushima-spring-srv6-deployment-status)

I support Alvaro Retana’s DISCUSS position.

I also support Warren Kumari’s DISCUSS position.  In particular, discussing the magnitude of the exposure of an internal topology due to a BGP leak would be helpful to document.

** Section 8.  It would be worth repeating the two key security assumptions from RFC8402:

OLD
SRv6 operates within a trusted SR domain with filtering of traffic at
  the domain boundaries.

NEW
SRv6 operates within a trusted SR domain with filtering of traffic at the domain boundaries. Likewise, there is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so.

[Ballot discuss]
I am balloting DISCUSS because the document underspecifies the use of Endpoint
Behaviors. As a result, it is unclear when they should be checked, enforced,
or needed. Details follow.


The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint
behaviors which MAY be encoded, but not limited to, are...etc."

  The text above ends with "etc." which means there are other possible
  behaviors. That's not a great use of normative language, even if optional.
  My initial instinct was to ask you to be specific, BUT...

  The description of the SRv6 SID Information Sub-TLV (§3.1) says that "an
  unrecognized endpoint behavior MUST NOT be considered invalid", which seems
  to mean that any behavior is ok, AND...

  There's no validation specified, except for the description of the SRv6 SID
  Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length
  MUST be set to 0 for SIDs where the Argument is not applicable". AND...

  Several of the service descriptions in §5/§6 say that "The SRv6 Endpoint
  behavior of the SRv6 SID is entirely up to the originator of the
  advertisement. In practice, the SRv6 Endpoint behavior is..."


The result is that any endpoint behavior (even unrecognized) can be used,
while also requiring a specific setting for the argument length in some cases.

How can the argument length be validated if the endpoint behavior is unknown?

Clearly (from looking at rfc8986), not all endpoint behaviors apply to the
services defined in this document. Should a receiver accept any endpoint
behavior? What should a receiver do if a known but unrelated behavior (End,
for example) is received?

What should the receiver do if the endpoint behavior is known and applicable,
but the attribute length is not set correctly?

For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick one),
should the behaviors used "in practice" be enforced? What if different behavior
is advertised? Can it safely be ignored?

Why is the Endpoint Behavior included in the Sub-TLV if (from the above) it
looks like it doesn't matter?

[Ballot comment]
(1) To make sure, the new "BGP SRv6 Service SID Flags" registry is
intended to document the allocations for the "SRv6 SID Flags" field in the
SRv6 SID Information Sub-TLV (§3.1), right?

Please say so somewhere.  It would also be nice if the name of the field (SRv6
SID Flags) and the registry (SRv6 Service SID Flags) matched.  I realize that
fitting the full name in the figure won't work, but you can either use multiple
lines (as you have already) or call the field simply "Flags," then extend
to the full name in the description of the field...or many other ways to avoid
confusion.


(2) §3.1:

      SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are
      currently defined.  SHOULD be set to 0 by the sender and MUST be
      ignored by the receiver.

If/when the flags are defined, the behavior specified here won't be compatible.
Instead, a behavior that assumes that some of the flags will be known in the
future would be better.  For example: any unknown flags MUST be ignored by the
receiver.


(3) §3.1: "SRv6 Endpoint Behavior...The opaque endpoint behavior (i.e., value
0xFFFF)...MUST NOT be considered invalid by the receiver."

Ok, but the opaque behavior is not defined as invalid in rfc8986 or anywhere
else (AFAIK).  rfc8986 includes a note specifically for the cases in
this document in §8.3. So this requirement is not needed. 


(4) §3.2.1: "Transposition Length of 0 ... In this case, the Transposition
Offset MUST be set to 0."

What should the receiver do if the offset is not set to 0?


(5) §3.2.1: According to rfc8986, the sum of the Loc + Func + Agr <= 128.  The
inclusion of the transposition fields changes the formula to add the new
length.  Please indicate the new constraints.  What should the receiver do if
the sum of the lengths is not <= 128?


(6) §3.2.1: "Arguments MAY be generally applicable for SIDs of only specific
SRv6 Endpoint behaviors"  In this case, "MAY" is just stating a fact (specified
in rfc8986): s/MAY/may


(7) §5: s/MUST choose to perform IPv6 encapsulation/MUST perform IPv6
encapsulation

To choose is not normatively enforceable; encapsulating is.


(8) §5:

  The SRv6 Service SID SHOULD be routable within the AS of the egress
  PE and serves the dual purpose of providing reachability between
  ingress PE and egress PE while also encoding the SRv6 Endpoint
  behavior.

Is it ever ok for the SID to not be routable?  If so, when?  The "purpose of
providing reachability" requires the SID to be routable.  IOW, why is this
behavior recommended and not required?


(9) Both §5/§6 say that the "ingress PE SHOULD perform resolvability check for
the SRv6 Service SID before considering the received prefix for the BGP best
path computation."

By "resolvability check", do you mean the "Route Resolvability Condition" from
§9.1.2.1/rfc4271??  If so, please be explicit.

Given that we're talking about services, which table should be used to resolve
the SID?  This question is something that rfc4271 doesn't cover [1]. Please add
something similar to this text from rfc9012 (where the resolvability condition
is mentioned):

  The reachability condition is evaluated as per [RFC4271].  If the IP
  address is reachable via more than one forwarding table, local policy is
  used to determine which table to use.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bestpath-selection-criteria


(10) [nits]

s/multiple instances...is encountered/multiple instances...are encountered/g

Please add figure numbers to all the packet formats, etc.

[Ballot comment]
[updating after the intdir review]

Thank you for the work put into this document. This protocol is important for scalable and deployable SRv6 services. With revised -10, all my blocking DISCUSS points are addressed, I am therefore clearing my DISCUSS ballot (the points are kept below for archiving). As replied by email, the -10 also addresses most of my previous COMMENTs.

Special thanks to Matthew Bocci for the shepherd's write-up including the section about the WG consensus and document history.

Thanks as well for Ron Bonica's INT directorate review (), I am satisfied to see the authors exchanging with Ron on his review.

I hope that this helps to improve the document,

Regards,

-éric


# previous DISCUSS (for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:


## Section 3.1

"IANA registry defined in section 9.2 of [RFC8986]" but there is no section 9.2 in RFC 8986. I guess it is section 10.2. Moreover, IANA registries are usually referred to via their name/URL, e.g., https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, and not by a section of the RFC that created them.

## Section 3.2.1

Where is "locator node" defined ? "locator block" is defined in section 3.1 of RFC 8986 but not the node (I can only guess that this is the "N" in the "B:N" notation used in RFC 8986).

## Section 6

Section 9 of draft-ietf-bess-evpn-igmp-mld-proxy-16 indeed defines route types 7 and 8 but it uses non IPv4-only wording. So, s/IGMP join sync route/Multicast Membership Report Synch Route/ + same for type 8.

# COMMENTS

## Section 1

More details on the encapsulation (plain IP in IPv6 ?) will be welcome in "The
  ingress PE encapsulates the payload in an outer IPv6 header where the
  destination address is the SRv6 Service SID provided by the egress
  Provider Edge (PE). "

## Section 3.2.1

The transposition field appears to be about "labels", which are not qualified. Should the reader assume that those are "MPLS labels" ? A reference to some text would be welcome. Not being a SRv6 expert (but somehow knowledgeable on the topic), all the text about transposition is completely opaque to me.

The section 4 appears to give some information, but there should at least be a forward reference to it in section 3.2.1 or even better the section 4 should be moved before section 3.2.1.

## Section 4

This section would benefit from examples & figures.

While the specification probably works well, mapping a 128-bit IPv6 SID into what looks like a 20-bit MPLS label looks like a smart kludge (for compression efficiency) but still...

## Section 5

"...optionally insert an SRH [RFC8754] when required..." looks like an oxymoron to me, i.e., if it is required then it is no more optional. Same issue in other places (notably section 6).

5th § "the ingress PE encapsulates the payload in an outer IPv6 header", is it "payload" of the ingress packet or the whole packet itself ?

## Section 10

The protocol defined in this document is a sibling of the EPVN and other layer-3 VPN using BGP as a control plane. I would have expected to have a mostly identical security section. The similarity is indeed indicated in the 2nd § but this 2nd § would benefit by also giving the RFC titles rather than a dry list of RFCs.

The 3rd § appears a little self-contradicting to my reading. The first part rightfully confirms that SRv6 domain should be closed and makes reference to SRH and network-programming security sections, i.e., isolation/protection in the data plane. Then, the last part of this § is "Therefore, precaution is necessary to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain. " which seems to contradict the first part. IMHO, the words "is necessary" is an overkill, something like "Precautions should be taken to ensure..." would be more appropriate.

To elaborate on the previous comment:

- isn't it *exactly* the same security issues as for EPVN and other BGP-based VPN ? So, already covered by the 2nd § ?

- even if there is yet-another BGP leak with SRv6 SID, then what are the consequences ? SRv6 data plane (as explained in the first sentences of this 3rd §) MUST be protected anyway and will protect the SRv6 domain completely, else the operator has more critical issues.

In short, readers will benefit from a shorter and clearer 3rd paragraph.

Final suggestion for the security section: what happens when the length of all sub-sub-TLVs exceeds the length of the sub-TLV ? And similar corner cases. This is of course more an implementation issue but should it be mentioned here ?

I note that the security directorate review result is "ready".

[Ballot comment]
I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it. Hopefully someone can help my understand how this doesn't expand the consequences of a BGP leak.

[Ballot comment]
I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it. Hopefully someone can help my understand how this doesn't expand the consequences of a BGP leak. (also, thanks to Andrew for discussions and review).

[Ballot discuss]
The Security Considerations section says: "The service flows between PE routers using SRv6 SIDs advertised via BGP are expected to be limited within the trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network).  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."
This is related to (from RFC8402): "Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain."

However, we all know that BGP leaks happen -- and when they do, the SID’s contained in the leak will be logged by various systems and hence available to the public into perpetuity.

While the document states that border filtering should protect against traffic injection, this does not cover the case of internal compromise. Sure, there is the argument that once there is an internally compromised system, all bets are off -- but with this, an attacker that knows the SIDs in e.g inject traffic into a VPN. This seems to me to significantly expand the attack surface to include the customer's networks too.

Not only does an operator have to ensure that BGP leaks never occur, they have to then ensure that at no point can there be any filter lapses at any border node, and be able to guarantee the security of every device, server and machine within the domain in order for a secure posture to be maintained. Simply saying that precautions should be taken to make sure that route leak don't occur, when the consequences of doing so are a: severe and b: hard to recover from seems to not really cover it. In addition, it seems that the blast radius from a missing ACL seems much larger if it allows injections.

[Ballot comment]
I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it. Hopefully someone can help my understand how this doesn't expand the consequences of leaking BGP.

[Ballot discuss]
The Security Considerations section says: "The service flows between PE routers using SRv6 SIDs advertised via BGP are expected to be limited within the trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network).  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."
This is related to (from RFC8402): "Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain."

However, we all know that BGP leaks happen -- and when they do, the SID’s contained in the leak will be logged by various systems and hence available to the public into perpetuity.

While the document states that border filtering should protect against traffic injection, this does not cover the case of internal compromise. Sure, there is the argument that once there is an internally compromised system, all bets are off -- but with this, an attacker that knows the SIDs in use can perform injection attacks in addition to routing traffic however they like.

So, not only does an operator have to ensure that BGP leaks never occur, they have to then ensure that at no point can there be any filter lapses at any border node, and be able to guarantee the security of every device, server and machine within the domain in order for a secure posture to be maintained.

[Ballot comment]
I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it, and hopefully I can understand how this doesn't increase the attack scope for e.g VPN use.

[Ballot comment]
Thank you for the work put into this document. This protocol is important for scalable and deployable SRv6 services. With revised -10, all my blocking DISCUSS points are addressed, I am therefore clearing my DISCUSS ballot (the points are kept below for archiving). As replied by email, the -10 also addresses most of my previous COMMENTs.

Special thanks to Matthew Bocci for the shepherd's write-up including the section about the WG consensus and document history.

Please also expect an INT directorate review before the IESG telechat (I may update this ballot accordingly).

I hope that this helps to improve the document,

Regards,

-éric


# previous DISCUSS (for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:


## Section 3.1

"IANA registry defined in section 9.2 of [RFC8986]" but there is no section 9.2 in RFC 8986. I guess it is section 10.2. Moreover, IANA registries are usually referred to via their name/URL, e.g., https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, and not by a section of the RFC that created them.

## Section 3.2.1

Where is "locator node" defined ? "locator block" is defined in section 3.1 of RFC 8986 but not the node (I can only guess that this is the "N" in the "B:N" notation used in RFC 8986).

## Section 6

Section 9 of draft-ietf-bess-evpn-igmp-mld-proxy-16 indeed defines route types 7 and 8 but it uses non IPv4-only wording. So, s/IGMP join sync route/Multicast Membership Report Synch Route/ + same for type 8.

# COMMENTS

## Section 1

More details on the encapsulation (plain IP in IPv6 ?) will be welcome in "The
  ingress PE encapsulates the payload in an outer IPv6 header where the
  destination address is the SRv6 Service SID provided by the egress
  Provider Edge (PE). "

## Section 3.2.1

The transposition field appears to be about "labels", which are not qualified. Should the reader assume that those are "MPLS labels" ? A reference to some text would be welcome. Not being a SRv6 expert (but somehow knowledgeable on the topic), all the text about transposition is completely opaque to me.

The section 4 appears to give some information, but there should at least be a forward reference to it in section 3.2.1 or even better the section 4 should be moved before section 3.2.1.

## Section 4

This section would benefit from examples & figures.

While the specification probably works well, mapping a 128-bit IPv6 SID into what looks like a 20-bit MPLS label looks like a smart kludge (for compression efficiency) but still...

## Section 5

"...optionally insert an SRH [RFC8754] when required..." looks like an oxymoron to me, i.e., if it is required then it is no more optional. Same issue in other places (notably section 6).

5th § "the ingress PE encapsulates the payload in an outer IPv6 header", is it "payload" of the ingress packet or the whole packet itself ?

## Section 10

The protocol defined in this document is a sibling of the EPVN and other layer-3 VPN using BGP as a control plane. I would have expected to have a mostly identical security section. The similarity is indeed indicated in the 2nd § but this 2nd § would benefit by also giving the RFC titles rather than a dry list of RFCs.

The 3rd § appears a little self-contradicting to my reading. The first part rightfully confirms that SRv6 domain should be closed and makes reference to SRH and network-programming security sections, i.e., isolation/protection in the data plane. Then, the last part of this § is "Therefore, precaution is necessary to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain. " which seems to contradict the first part. IMHO, the words "is necessary" is an overkill, something like "Precautions should be taken to ensure..." would be more appropriate.

To elaborate on the previous comment:

- isn't it *exactly* the same security issues as for EPVN and other BGP-based VPN ? So, already covered by the 2nd § ?

- even if there is yet-another BGP leak with SRv6 SID, then what are the consequences ? SRv6 data plane (as explained in the first sentences of this 3rd §) MUST be protected anyway and will protect the SRv6 domain completely, else the operator has more critical issues.

In short, readers will benefit from a shorter and clearer 3rd paragraph.

Final suggestion for the security section: what happens when the length of all sub-sub-TLVs exceeds the length of the sub-TLV ? And similar corner cases. This is of course more an implementation issue but should it be mentioned here ?

I note that the security directorate review result is "ready".

[Ballot discuss]
Thank you for the work put into this document. This protocol is important for scalable and deployable SRv6 services.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Matthew Bocci for the shepherd's write-up including the section about the WG consensus and document history.

Please also expect an INT directorate review before the IESG telechat (I may update this ballot accordingly).

I hope that this helps to improve the document,

Regards,

-éric


# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:


## Section 3.1

"IANA registry defined in section 9.2 of [RFC8986]" but there is no section 9.2 in RFC 8986. I guess it is section 10.2. Moreover, IANA registries are usually referred to via their name/URL, e.g., https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, and not by a section of the RFC that created them.

## Section 3.2.1

Where is "locator node" defined ? "locator block" is defined in section 3.1 of RFC 8986 but not the node (I can only guess that this is the "N" in the "B:N" notation used in RFC 8986).

## Section 6

Section 9 of draft-ietf-bess-evpn-igmp-mld-proxy-16 indeed defines route types 7 and 8 but it uses non IPv4-only wording. So, s/IGMP join sync route/Multicast Membership Report Synch Route/ + same for type 8.

[Ballot comment]
# COMMENTS

## Section 1

More details on the encapsulation (plain IP in IPv6 ?) will be welcome in "The
  ingress PE encapsulates the payload in an outer IPv6 header where the
  destination address is the SRv6 Service SID provided by the egress
  Provider Edge (PE). "

## Section 3.2.1

The transposition field appears to be about "labels", which are not qualified. Should the reader assume that those are "MPLS labels" ? A reference to some text would be welcome. Not being a SRv6 expert (but somehow knowledgeable on the topic), all the text about transposition is completely opaque to me.

The section 4 appears to give some information, but there should at least be a forward reference to it in section 3.2.1 or even better the section 4 should be moved before section 3.2.1.

## Section 4

This section would benefit from examples & figures.

While the specification probably works well, mapping a 128-bit IPv6 SID into what looks like a 20-bit MPLS label looks like a smart kludge (for compression efficiency) but still...

## Section 5

"...optionally insert an SRH [RFC8754] when required..." looks like an oxymoron to me, i.e., if it is required then it is no more optional. Same issue in other places (notably section 6).

5th § "the ingress PE encapsulates the payload in an outer IPv6 header", is it "payload" of the ingress packet or the whole packet itself ?

## Section 10

The protocol defined in this document is a sibling of the EPVN and other layer-3 VPN using BGP as a control plane. I would have expected to have a mostly identical security section. The similarity is indeed indicated in the 2nd § but this 2nd § would benefit by also giving the RFC titles rather than a dry list of RFCs.

The 3rd § appears a little self-contradicting to my reading. The first part rightfully confirms that SRv6 domain should be closed and makes reference to SRH and network-programming security sections, i.e., isolation/protection in the data plane. Then, the last part of this § is "Therefore, precaution is necessary to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain. " which seems to contradict the first part. IMHO, the words "is necessary" is an overkill, something like "Precautions should be taken to ensure..." would be more appropriate.

To elaborate on the previous comment:

- isn't it *exactly* the same security issues as for EPVN and other BGP-based VPN ? So, already covered by the 2nd § ?

- even if there is yet-another BGP leak with SRv6 SID, then what are the consequences ? SRv6 data plane (as explained in the first sentences of this 3rd §) MUST be protected anyway and will protect the SRv6 domain completely, else the operator has more critical issues.

In short, readers will benefit from a shorter and clearer 3rd paragraph.

Final suggestion for the security section: what happens when the length of all sub-sub-TLVs exceeds the length of the sub-TLV ? And similar corner cases. This is of course more an implementation issue but should it be mentioned here ?

I note that the security directorate review result is "ready".

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-srv6-services-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the BGP Prefix-SID TLV Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the early registrations for values 4, 5, and 6 will be made permanent and their references changed to [ RFC-to-be ].

Second, a new registry is to be created called the SRv6 Service Sub-TLV Types registry. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

The allocation policy for the new registry is:

0 : Reserved
1-127 : IETF Review
128-254 : First Come First Served
255 : Reserved

There is a single initial registration in the new registry as follows:

Value: 1
Type: SRv6 SID Information Sub-TLV
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the SRv6 Service Data Sub-Sub-TLV Types registry. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

The allocation policy for the new registry is:

0 : Reserved
1-127 : IETF Review
128-254 : First Come First Served
255 : Reserved

There is a single initial registration in the new registry as follows:

Value: 1
Type: SRv6 SID Structure Sub-Sub-TLV
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the BGP SRv6 Service SID Flags registry. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

The registry consists of eight bits and all bits are managed via IETF Review as defined by RFC8126. There are no initial registrations in the new registry.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2021-11-24):

From: The IESG
To: IETF-Announce
CC: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-srv6-services@ietf.org, martin.vigoureux@nokia.com, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SRv6 BGP based Overlay Services) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'SRv6 BGP based Overlay Services'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4520/
  https://datatracker.ietf.org/ipr/4521/
  https://datatracker.ietf.org/ipr/3795/

Document shepherd writeup for draft-ietf-bess-srv6-services-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
have traditionally been deployed over MPLS networks. However, there is a need to be
able to implement them on new SRv6 based networks. A solution was needed to allow
the advertisement of segment identifiers associated with layer 2 and layer 3 service endpoint
functions over SRv6.

This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and
EVPN. The document was developed over a period of time in the BESS WG, in parallel
with the development of SRv6 in the 6MAN and SPRING working groups.

Document Quality:

Segment routing using SRv6 is starting to be deployed. There is a requirement for a
standardised specification for how to deliver widely used VPN services such as provider
provisioned IP VPNs and EVPN over an SRv6 infrastructure, making use of functions available
in SRv6.

The draft received a number of comments during WG last call as well as an RTGDIR review
which were addressed.

I have no concerns about the quality of the document. A number of participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 6 of the draft and made a number of editorial comments which have been
addressed in version 7 to a sufficient extent.  It is clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are 3 IPR disclosures. There was no discussion or objection raised to these.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes. There are a couple of warnings about outdated informative references
to drafts where the published version number has incremented by one.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.

Document shepherd writeup for draft-ietf-bess-srv6-services-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
have traditionally been deployed over MPLS networks. However, there is a need to be
able to implement them on new SRv6 based networks. A solution was needed to allow
the advertisement of segment identifiers associated with layer 2 and layer 3 service endpoint
functions over SRv6.

This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and
EVPN. The document was developed over a period of time in the BESS WG, in parallel
with the development of SRv6 in the 6MAN and SPRING working groups.

Document Quality:

Segment routing using SRv6 is starting to be deployed. There is a requirement for a
standardised specification for how to deliver widely used VPN services such as provider
provisioned IP VPNs and EVPN over an SRv6 infrastructure, making use of functions available
in SRv6.

The draft received a number of comments during WG last call as well as an RTGDIR review
which were addressed.

I have no concerns about the quality of the document. A number of participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 6 of the draft and made a number of editorial comments which have been
addressed in version 7 to a sufficient extent.  It is clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are 3 IPR disclosures. There was no discussion on these in the WG.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes. There are a couple of warnings about outdated informative references
to drafts where the published version number has incremented by one.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.

Document shepherd writeup for draft-ietf-bess-srv6-services-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
have traditionally been deployed over MPLS networks. However, there is a need to be
able to implement them on new SRv6 based networks. A solution was needed to allow
the advertisement of segment identifiers associated with layer 2 and layer 3 service endpoint
functions over SRv6.

This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and
EVPN. The document was developed over a period of time in the BESS WG, in parallel
with the development of SRv6 in the 6MAN and SPRING working groups.

Document Quality:

Segment routing using SRv6 is starting to be deployed. There is a requirement for a
standardised specification for how to deliver widely used VPN services such as provider
provisioned IP VPNs and EVPN over an SRv6 infrastructure, making use of functions available
in SRv6.

The draft received a number of comments during WG last call as well as an RTGDIR review
which were addressed.

I have no concerns about the quality of the document. A number of participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 6 of the draft and made a number of editorial comments which have been
addressed in version 7 to a sufficient extent.  It is clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are 3 IPR disclosures. There was no discussion on these in the WG.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes. There are a couple of warnings about outdated informative references
to drafts where the published version number has incremented by one.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.

Document shepherd writeup for draft-ietf-bess-srv6-services-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
have traditionally been deployed over MPLS networks. However, there is a need to be
able to implement them on new SRv6 based networks. A solution was needed to allow
the signalling of segment identifiers associated with layer 2 and layer 3 service endpoint
functions over SRv6.

This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and
EVPN. The document was developed over a period of time in the BESS WG, in parallel
with the development of SRv6 in the 6MAN and SPRING working groups.

Document Quality:

Segment routing using SRv6 is starting to be deployed. There is a requirement for a
standardised specification for how to deliver widely used VPN services such as provider
provisioned IP VPNs and EVPN over an SRv6 infrastructure, making use of functions available
in SRv6.


The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document. A number of participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 6 of the draft and made a number of editorial comments which have been
addressed in version 7 to a sufficient extent.  It is clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are 3 IPR disclosures. There was no discussion on these in the WG.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes. There are a couple of warnings about outdated informative references
to drafts where the published version number has incremented by one.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.

Document shepherd writeup for draft-ietf-bess-srv6-services-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This draft defines procedures and messages for SRv6-based BGP
  services including L3VPN, EVPN, and Internet services.  It builds on
  RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
  "BGP MPLS-Based Ethernet VPN".

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. These services
have traditionally been deployed over MPLS networks. However, there is a need to be
able to implement them on new SRv6 based networks. A solution was needed to allow
the signalling of segment identifiers associated with layer 2 and layer 3 service endpoint
functions over SRv6.

This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and
EVPN. The document was developed over a period of time in the BESS WG, in parallel
with the development of SRv6 in the 6MAN and SPRING working groups.

Document Quality:

Segment routing using SRv6 is starting to be deployed. for supporting BGP based services between datacenters is becoming
widely deployed. The document is leverages relatively mature BGP extensions described
in a draft which is currently in the RFC editors queue.

The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document. A number of participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

I reviewed Version 6 of the draft and made a number of editorial comments which have been
addressed in version 7 to a sufficient extent.  It is clear and readable.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It also received an RTG DIR review and cross-reviewed with
the IDR working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No formal reviews required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are 3 IPR disclosures. There was no discussion on these in the WG.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


ID nits passes. There are a couple of warnings about outdated informative references
to drafts where the published version number has incremented by one.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

No formal review requirements.

(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There is one IANA action. This is for the new SR Tunnel Sub-TLV from the BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. This is properly called out in the IANA
considerations section and its usage documented in the body of the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

The document does not define any YANG modules.

Request for posting confirmation emailed to previous authors: Bruno Decraene , Clarence Filsfils , Gaurav Dawra , Jorge Rabadan , Ketan Talaulikar , Robert Raszuk , Shunwan Zhuang

Request for posting confirmation emailed to previous authors: Bruno Decraene , Jorge Rabadan , bess-chairs@ietf.org, Shunwan Zhuang , Robert Raszuk , Gaurav Dawra , Clarence Filsfils

Request for posting confirmation emailed to previous authors: Swadesh Agrawal , Robert Raszuk , Dirk Steinberg , Bruno Decraene , " daniel.bernier@bell.ca" , Gaurav Dawra , Shunwan Zhuang , Jorge Rabadan , John Leddy , Clarence Filsfils , Daniel Voyer , Patrice Brissette , bess-chairs@ietf.org, Satoru Matsushima