[Bier] Robert Wilton's No Objection on draft-ietf-bier-evpn-12: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-bier-evpn-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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