EVPN BUM Using BIER
draft-ietf-bier-evpn-14

# Internet AD comments for draft-ietf-bier-evpn-10
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/

## Comments

### S5

* Do you want to request an IPv6 multicast address as well?

Minor comments:

- Requirements language section should adhere to RFC8174 noting the change in boilerplate language.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

- idnits complains about several unused and missing references - authors please correct these.

- Section 1: "Several kinds of tunnel technologies can be used, as specified in [RFC7432].". It would be helpful to specify what these tunnel technologies are (with references); also, RFC7432 only specifies the procedures for MPLS LSPs as the tunneling technology so the authors may want to clarify this in the text. 

- Section 2.1: "When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP header (and UDP header in the case of VXLAN/GENVE).." - typo 'GENVE' correct to 'GENEVE'

# John Scudder, RTG AD, comments for draft-ietf-bier-evpn-11
CC @jgscudder

Thanks for this document. As usual with multicast documents, I largely am taking it on faith that the authors and WG know what they're doing, but I still have a few non-blocking comments, below.

## COMMENTS

### Section 1.1

- You define "AC", but only use it once, IMO the definition isn't needed in this case (for that matter the abbreviation isn't needed in Section 2.2.2.1, you can just use your words).

- "Sets of C-flows can be identified by the use of the "C-*" wildcard" -- I wonder if "denoted" would be a better term than "identified" in this context.

- "A multicast tunnel through the network of one or more SPs" -- presumably by "SPs" you mean "service providers". Probably better to write it out.

### Section 2.2.1

I can't understand what this sentence means: "Only when selectively forwarding is for all flows without tunnel segmentation, SMET routes are used without the need for S-PMSI A-D routes." Specifically, I can't parse the first clause. I would propose a rewrite if I had a solid guess as to what it meant, but alas.

### Section 2.2.2.1

I'm guessing that when you write, "It may be desired that SMET routes are not used to reduce the burden of explicit tracking", what you mean is "It may be desired that SMET routes are not used, in order to reduce the burden of explicit tracking"?

(See also https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves)

### Section 3

Please expand "DF".

### Section 4.1.1, best match

I trust/hope that other documents in the BIER/EVPN/MVPN set clearly define what "best match" means in this context. It's not intuitively obvious what things like "best match the source and destination IP address" mean, absent a definition.

### Section 4.1.2

"Each instance of the re-advertised route for a downstream region has a PTA that specifies tunnel information that is the same as or different from that of the route for a different region."

Possibly this is just my lack of expertise in the subject area and appreciation for your subtlety, but I don't see how the second half of the sentence conveys any information. Couldn't you rewrite it as "Each instance of the re-advertised route for a downstream region has a PTA."?

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

Thank you for writing this document; I found it an interesting read.

I have a few comments / readability suggestions:

Section 3. Multihoming Split Horizon
"For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
the ES from which a BUM packet originates. A PE receiving that
packet from the core side will not forward it to the same ES."

It is unclear what exactly "that packet" refers to - from my (limited) understanding the packets themselves don't carry ESI labels.

"For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
bias procedures, with which a PE receiving a BUM packet from the
core side knows from encapsulation the ingress PE so it does not
forward the packet to any multihoming ESes that the ingress PE is
on, because the ingress PE already forwarded the packet to those
ESes, regardless of whether the ingress PE is a DF for those ESes."

This sentence is somewhat of a run-on. Perhaps moving the "from encapsulation" much earlier would help? Or perhaps splitting this into multiple sentences would help?

Thanks for working on this specification. 

I have some question that might need some clarifications-

  # Section 2.1, is says 

        In that case the full VXLAN/NVGRE/GENEVE encapsulation with an IP header MUST be included in the BIER payload.

   The "IP header" here, does this mean outer IP header as mentioned in the beginning of this section? also what about UDP header in case of VXLAN/GENVE, should there be no requirements on that?

Thank you for addressing all my previous DISCUSS/COMMENT points.

Archive is at: 
https://mailarchive.ietf.org/arch/msg/bier/0kvx2trIvsuyGxYeqyst2fv2lH4/

# GEN AD review of draft-ietf-bier-evpn-12

CC @larseggert

## Comments

### Section 2, paragraph 4
```
     *  "Tunnel Type".  The same codepoint 0x0B that IANA has assigned for
        BIER for MVPN [RFC8556] is used for EVPN as well.
```
Should this document update RFC8556? It reuses the 0x0B codepoint, but
the definition of "MPLS label" (and "Flags"?) seems to be
broader/different than that in RFC8556?

### Section 2, paragraph 3
```
     *  "Tunnel Identifier".  This field contains three subfields for
        BIER.  The text below is exactly as in [RFC8556].
```
It would be better to normatively cite the relevant section in RFC8556
rather than to replicate its text here. (If that part of RFC8556 is
ever updated by another RFC, the copy here will be inconsistent.)

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

### Typos

#### Section 4.1.1, paragraph 2
```
-        packet after the ethernet header, the IMET route originated for
-                         ^
+        packet after the Ethernet header, the IMET route originated for
+                         ^
```

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

Just some minor nits/suggestions:

Minor level comments:

(1) p 3, sec 2.  Use of the PMSI Tunnel Attribute

      1  The first subfield is a single octet, containing the sub-
         domain-id of the sub-domain to which the BFIR will assign the
         packets that it transmits on the PMSI identified by the NLRI of
         the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that
         contains this PTA.  How that sub-domain is chosen is outside
         the scope of this document.

What does I-PMSI stand for?


(2) p 7, sec 3.  Multihoming Split Horizon

   For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
   the ES from which a BUM packet originates.  A PE receiving that
   packet from the core side will not forward it to the same ES.  The
   procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP
   P2MP tunnels, using downstream- and upstream-assigned ESI labels
   respectively.  For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
   bias procedures, with which a PE receiving a BUM packet from the core
   side knows from encapsulation the ingress PE so it does not forward
   the packet to any multihoming ESes that the ingress PE is on, because
   the ingress PE already forwarded the packet to those ESes, regardless
   of whether the ingress PE is a DF for those ESes.

Perhaps expand DF to designated forwarder?



Nit level comments:

(3) p 4, sec 2.1.  IP-Based Tunnel and BIER PHP

   When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP
   header (and UDP header in the case of VXLAN/GENVE) is not included in
   the BIER payload, except when it is known apriori that BIER PHP [I-
   D.ietf-bier-php] is used in the BIER domain and the encapsulation
   (after the BIER header is popped) between the BIER Penultimate Hop
   and the egress PE does not have a way to indicate the next header is
   VXLAN/NVGRE/GENEVE.  In that case the full VXLAN/NVGRE/GENEVE
   encapsulation with an IP header MUST be included in the BIER payload.
   A well-known IP multicast address (to be assigned by IANA) is used as
   the destination address and the egress PEs MUST be set up to receive
   and process packets addressed to the address.  The address is used
   for all BDs and the inner VXLAN/NVGRE/GENEVE header will be used to
   identify BDs.

I assume PHP is "penultimate hop pop", but that doesn't appear to be specified.

Regards,
Rob