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

# 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/

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

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.

note a lot of RFC references are not links and should be fixed.

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?

Thank you for this document, and for working to address Menachem Dodge's OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-bess-mvpn-evpn-aggregation-label-10-opsdir-lc-dodge-2023-07-02/ )

Thanks for working on this specification. I have no objection from TSV point of view.

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/

# 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