MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-14

[Ballot comment]
The shepherd writeup is a bit terse.  It doesn't, for example, explain why "Standards Track" is the right status for this document.  More importantly, the question about IPR disclosures and a pointer to the discussion about them was not really answered.  I trust that this was properly resolved.

Section 1 defines "Inclusive PMSI" but the document doesn't use that term other than in its own definition.

[Ballot comment]
Thanks for the quick turnaround. The update looks good, I’ll clear my discuss. I have a couple new comments/questions regarding the “Context-Specific Label Space ID Type” registry.

- Is there any existing group of registries you could suggest IANA organize the new registry under? At first glance, it appears as though it might fit in the “Border Gateway Protocol (BGP) Extended Communities” group, there are a bunch of other (sub)type registries there. If you agree that’s the place for it, add that suggestion in the IANA section.

- Probably add another line to the table, indicating values 1-255 are unassigned. Unless you want to reserve value 255, sometimes people like to do that, for various reasons. It doesn’t really seem necessary in this case, but on the other hand, it may come under the heading of “can’t hurt, might help“. In that case, it would be two new lines: “1-254, unassigned; 255, reserved”.

[Ballot comment]
Thanks to Zhaohui Zhang and Stéphane Litkowski for addressing my previous DISCUSS points (even if they were 'discuss discuss', i.e., just to have a discussion). I have now cleared my previous DISCUSS ballot.

# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for EVPN) ?

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM includes multicast.

## Section 2.1

`At the present time` what about "In 2023, " ?

## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous sentence).

Why this section use `to be defined by IANA`, while section 5 lists the IANA-assigned values ?

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is there any work in BESS WG for this ?

# NITS

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown *u*nicast, or Multicast (packet)/

s/sub set/subset/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

Standard track

(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:

The document provides a solution to reduce the number of upstream allocated labels to be managed by egress PEs by allowing to use provisioned labels.

Working Group Summary:

No controversy on this draft


Document Quality:

There's already implementation of the specification.

Personnel:

Stephane Litkowski is the shepherd
Andrew Alston is the responsible AD

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

The shepherd provided editorial comments that have been addressed. Nits and references have been checked and updated.

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

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

n/a

(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 concern

(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 2 IPRs currently disclosed.

(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 a good consensus on the document

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

No

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

No nits

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

n/a

(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?

no

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

No, but the document updates few RFCs

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

The IANA consideration is written properly

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

N/a

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

n/a

(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?

n/a

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-bess-mvpn-evpn-aggregation-label-12
CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy to take care of) and a few comments and nits.

(Sorry for the iteration on this ballot, I missed one of my pages of notes in my haste to get this sent off.)

## DISCUSS

### Section 3.2, ignoring routes considered harmful

There are two places toward the end of this subsection where you specify that a route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be exceptions, if the conditions for ignoring the routes are carefully chosen so that correctness (or something like it) is preserved, but as a general matter, ignoring routes is a one-way ticket to persistent traffic loss or worse. It's for this reason that RFC 7606 specifies treat-as-withdraw for many error conditions. I'll illustrate the general problem with an example that uses simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install it in the FIB.
- Now suppose the router that advertised it to us sends a replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path attribute P that we decide is malformed. We ignore the route as our error handling strategy.
- We are left in a state where we still have 10/8 via 1.1.1.1 selected and installed, because we ignored the replacement, "treating it as if was not received". This is an incorrect state. I can easily show you scenarios where it leads to traffic loss, persistent loops, etc.
- The correct behavior in this scenario would be to remove the 10/8 route received in the first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an issue for the two cases I've quoted, but you haven't made this clear in the document. I think at minimum, some analysis is needed to show that the strategy is OK. On the other hand if what you meant by "ignore" is something closer to the "treat-as-withdraw" strategy, I think the language has to be made more specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

Edited to add: I sent this as a followup to my original ballot, with cc idr-chairs: "I suspect my DISCUSS would have been caught if there had been review from IDR. Searching for the draft name in the IDR mailing list archive doesn’t surface any traffic about it, so I’m guessing this didn’t occur."

[Ballot comment]
## COMMENTS

### Section 3, EC

Please expand "EC" on first use, or put it in your glossary, or my personal favorite, just use the words "Extended Community" and remove "EC" altogether, it's unnecessary and (in my opinion) unhelpful to abbreviate it.

### Section 3.1, need registry?

You have an ID-Type and define the semantics of type 0. You probably should create a registry for the unallocated types.

### Section 3.1, AND or OR?

You have:

  In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
  route "carries DCB-flag" or "has DCB-flag attached" we mean the
  following:

  *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
      field has the Extension bit set

  *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
      and its DCB flag is set

I think you need to indicate if the bullets are ANDed or ORed. I infer from later context that they're ORed, in which case perhaps "we mean one or the other of the following".

### Section 3.1, values aren't TBA, they've been assigned

You write, "Sub-Type value to be assigned by IANA". But your IANA section shows that the sub-type has been assigned the value 0x08. Please update the "to be assigned" language, and put the value into the diagram.

You also write, "This document introduces a DCB flag (to be assigned by IANA)". Again, your IANA section shows IANA has assigned value 47, so please update the text in this section to match.

## NITS

### Section 2.2

- "number of total number of labels" --> too many "number of"s

### Section 2.2.2.3

- "w/o" --> "without"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-bess-mvpn-evpn-aggregation-label-12
CC @jgscudder

Thanks for this spec. I have one serious concern (but I think it will be easy to take care of) and a few comments and nits.

## DISCUSS

### Section 3.2, ignoring routes considered harmful

There are two places toward the end of this subsection where you specify that a route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be exceptions, if the conditions for ignoring the routes are carefully chosen so that correctness (or something like it) is preserved, but as a general matter, ignoring routes is a one-way ticket to persistent traffic loss or worse. It's for this reason that RFC 7606 specifies treat-as-withdraw for many error conditions. I'll illustrate the general problem with an example that uses simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install it in the FIB.
- Now suppose the router that advertised it to us sends a replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path attribute P that we decide is malformed. We ignore the route as our error handling strategy.
- We are left in a state where we still have 10/8 via 1.1.1.1 selected and installed, because we ignored the replacement, "treating it as if was not received". This is an incorrect state. I can easily show you scenarios where it leads to traffic loss, persistent loops, etc.
- The correct behavior in this scenario would be to remove the 10/8 route received in the first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an issue for the two cases I've quoted, but you haven't made this clear in the document. I think at minimum, some analysis is needed to show that the strategy is OK. On the other hand if what you meant by "ignore" is something closer to the "treat-as-withdraw" strategy, I think the language has to be made more specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-bess-mvpn-evpn-aggregation-label-12
CC @jgscudder

## DISCUSS

Thanks for this spec. I have one serious concern (but I think it will be easy to take care of) and a few comments and nits.

### Section 3.2, ignoring routes considered harmful

There are two places toward the end of this subsection where you specify that a route must be ignored. The first is:

"A PE MUST ignore a received route with both the DCB-flag and the Context Label Space ID EC attached, treating as if it was not received."

The second is:

"If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."

Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be exceptions, if the conditions for ignoring the routes are carefully chosen so that correctness (or something like it) is preserved, but as a general matter, ignoring routes is a one-way ticket to persistent traffic loss or worse. It's for this reason that RFC 7606 specifies treat-as-withdraw for many error conditions. I'll illustrate the general problem with an example that uses simple IPv4 unicast routes:

- Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install it in the FIB.
- Now suppose the router that advertised it to us sends a replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path attribute P that we decide is malformed. We ignore the route as our error handling strategy.
- We are left in a state where we still have 10/8 via 1.1.1.1 selected and installed, because we ignored the replacement, "treating it as if was not received". This is an incorrect state. I can easily show you scenarios where it leads to traffic loss, persistent loops, etc.
- The correct behavior in this scenario would be to remove the 10/8 route received in the first step; RFC 7606 calls this "treat-as-withdraw".

It might be that something special about MVPN/EVPN routes means this isn't an issue for the two cases I've quoted, but you haven't made this clear in the document. I think at minimum, some analysis is needed to show that the strategy is OK. On the other hand if what you meant by "ignore" is something closer to the "treat-as-withdraw" strategy, I think the language has to be made more specific and leave less to the creativity and imagination of the implementor.

Let's have a discussion about which it is, and see where to go from there.

[Ballot comment]
## COMMENTS

### Section 3, EC

Please expand "EC" on first use, or put it in your glossary, or my personal favorite, just use the words "Extended Community" and remove "EC" altogether, it's unnecessary and (in my opinion) unhelpful to abbreviate it.

### Section 3.1, need registry?

You have an ID-Type and define the semantics of type 0. You probably should create a registry for the unallocated types.

### Section 3.1, AND or OR?

You have:

  In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
  route "carries DCB-flag" or "has DCB-flag attached" we mean the
  following:

  *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
      field has the Extension bit set

  *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
      and its DCB flag is set

I think you need to indicate if the bullets are ANDed or ORed. I infer from later context that they're ORed, in which case perhaps "we mean one or the other of the following".

## NITS

### Section 2.2

- "number of total number of labels" --> too many "number of"s

### Section 2.2.2.3

- "w/o" --> "without"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-bess-mvpn-evpn-aggregation-label-12

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/3fAtK3w0wRrSeNCGgzBnr86jTRU).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 1, paragraph 14
```
onal label spaces is to be used to lookup the label, hence those label space
                                  ^^^^^^
```
The word "lookup" is a noun. The verb is spelled with a white space.

#### Section 1, paragraph 16
```
referred to as upstream-assigned. Otherwise it is downstream-assigned. An ups
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 2.1, paragraph 5
```
VPN 1, and so forth. Now only 1000 label instead of 1,000,000 labels are nee
                                  ^^^^^
```
Possible agreement error. The noun "label" seems to be countable.

#### Section 2.2.1, paragraph 2
```
hen tunnel segmentation is applied to a S-PMSI, certain nodes are "segmentati
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 2.2.2.1, paragraph 1
```
tunnel T2 and Flow-2 by tunnel T3. Then when the segmentation point receives
                                    ^^^^
```
Consider adding a comma here.

#### Section 2.2.2.1, paragraph 3
```
labels for segmented S-PMSI independently from its assigned label block tha
                            ^^^^^^^^^^^^^^^^^^
```
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

#### Section 2.2.2.2, paragraph 1
```
-PMSIs for the same VPN/BD to share the a VPN/BD-identifying label that leads
                                    ^^^^^
```
Two determiners in a row. Choose either "the" or "a".

#### Section 3.2, paragraph 5
```
nel encapsulation of data packets arriving on the tunnel. * They MUST all hav
                                  ^^^^^^^^^^^
```
The usual preposition after "arriving" is "at", not "on". Did you mean
"arriving at"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.

** Section 4.
  This document allows three methods (Section 2.2.3) of label
  allocation for MVPN [RFC6514] or EVPN [RFC7432] PEs and specifies
  corresponding signaling and procedures. 

...

  None of the [RFC6514], [RFC7432], [RFC8402] and [RFC5331]
  specifications lists any security concerns related to label
  allocation methods, and this document does not introduce new security
  concerns either.

Does this imply that the label allocations/advertising methods described in Section 2.2.3 rely on the security properties of the mechanisms described in other documents?  If so, can this be explicitly stated?

[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-bess-mvpn-evpn-aggregation-label-11

Thank you for the work put into this document.

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

Special thanks to Stéphane Litkowski for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status.

I hope that this review 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:

## Shepherd write-up

The shepherd write-up includes `Martin Vigoureux is the responsible AD`.

The shepherd write-up includes `There is one IPR`, while data tracker has 2 IPR declarations. At least, the auto-generated IETF Last Call correctly listed the two IPR declarations.

The above parts are obviously outdated and MUST be updated.

This is not really a DISCUSS criteria, so I will change my ballot after the IESG formal telechat or after an update of the shepherd write-up (the earlier).

## Wrong reference to RFC5531

As indicated by idnits, there is a reference to RFC 5531 (it should probably be RFC 5331)

[Ballot comment]

# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for EVPN) ?

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM includes multicast.

## Section 2.1

`At the present time` what about "In 2023, " ?

## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous sentence).

Why this section use `to be defined by IANA`, while section 5 lists the IANA-assigned values ?

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is there any work in BESS WG for this ?

# NITS

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown *u*nicast, or Multicast (packet)/

s/sub set/subset/

Closed request for Telechat review by INTDIR with state 'Withdrawn': It is now too late to request a review on this short document after Bob's rejection (and thanks to Bob to clearly indicate his intention).

[Ballot comment]
# Internet AD comments for draft-ietf-bess-mvpn-evpn-aggregation-label-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S2.1

* The first paragraph does not read like a normal part of the text flow.
  Maybe just some parentheses around it might help.

### S2.2.2.1

* "from those a few" -> "from those few"?

### S3.2

* s/mpls/MPLS/

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

The IANA Functions Operator has completed its review of draft-ietf-bess-mvpn-evpn-aggregation-label-10. 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 two actions which we must complete.

First, in the Additional PMSI Tunnel Attribute Flags registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the existing, temporary registration for:

Bit Flag: 47
Name: DCB

will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the Transitive Opaque Extended Community Sub-Types registry also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the existing, early registration for:

Sub-Type Value: 0x08
Name: Context Label Space ID Extended Community

will be made permanent and its reference changed to [ RFC-to-be ].

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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-07-12):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org, slitkows.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (MVPN/EVPN Tunnel Aggregation with Common Labels) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'MVPN/EVPN Tunnel Aggregation with Common
Labels'
  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 2023-07-12. 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


  The MVPN specifications allow a single Point-to-Multipoint (P2MP)
  tunnel to carry traffic of multiple VPNs.  The EVPN specifications
  allow a single P2MP tunnel to carry traffic of multiple Broadcast
  Domains (BDs).  These features require the ingress router of the P2MP
  tunnel to allocate an upstream-assigned MPLS label for each VPN or
  for each BD.  A packet sent on a P2MP tunnel then carries the label
  that is mapped to its VPN or BD (in some cases, a distinct upstream-
  assigned label is needed for each flow.)  Since each ingress router
  allocates labels independently, with no coordination among the
  ingress routers, the egress routers may need to keep track of a large
  number of labels.  The number of labels may need to be as large (or
  larger) than the product of the number of ingress routers times the
  number of VPNs or BDs.  However, the number of labels can be greatly
  reduced if the association between a label and a VPN or BD is made by
  provisioning, so that all ingress routers assign the same label to a
  particular VPN or BD.  New procedures are needed in order to take
  advantage of such provisioned labels.  These new procedures also
  apply to Multipoint-to-Multipoint (MP2MP) tunnels.  This document
  updates RFCs 6514, 7432 and 7582 by specifying the necessary
  procedures.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/


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

  https://datatracker.ietf.org/ipr/4571/
  https://datatracker.ietf.org/ipr/3341/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

Standard track

(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:

The document provides a solution to reduce the number of upstream allocated labels to be managed by egress PEs by allowing to use provisioned labels.

Working Group Summary:

No controversy on this draft


Document Quality:

There's already implementation of the specification.

Personnel:

Stephane Litkowski is the shepherd
Martin Vigoureux is the responsible AD

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

The shepherd provided editorial comments that have been addressed. Nits and references have been checked and updated.

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

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

n/a

(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 concern

(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 s one IPR

(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 a good consensus on the document

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

No

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

No nits

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

n/a

(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?

no

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

No, but the document updates few RFCs

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

The IANA consideration is written properly

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

N/a

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

n/a

(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?

n/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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?

Standard track

(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:

The document provides a solution to reduce the number of upstream allocated labels to be managed by egress PEs by allowing to use provisioned labels.

Working Group Summary:

No controversy on this draft


Document Quality:

There's already implementation of the specification.

Personnel:

Stephane Litkowski is the shepherd
Martin Vigoureux is the responsible AD

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

The shepherd provided editorial comments that have been addressed. Nits and references have been checked and updated.

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

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

n/a

(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 concern

(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 s one IPR

(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 a good consensus on the document

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

No

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

No nits

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

n/a

(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?

no

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

No, but the document updates few RFCs

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

The IANA consideration is written properly

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

N/a

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

n/a

(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?

n/a