Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication
draft-ietf-bess-mvpn-evpn-sr-p2mp-18

Thanks to Mohit Sethi for their secdir review. 

Introduction:  Please expand PIM, BIDIR.  Sometimes paragraphs like the last paragraph in the Intro are in a terminology section (closer to the BCP 14 language section).  Please consider.

Thanks for the work done in this document. My previous blocking DISCUSS was about the "MPLS Label" header field, which is no more only for MPLS (see https://mailarchive.ietf.org/arch/msg/bess/mfXLxWrcxs-5BvUOGKNODeSCR8U/ ).

Based on the responsible AD, Gunter van de Velde, email https://mailarchive.ietf.org/arch/msg/bess/M3sPL5drhWXCXY4LR8nIrcjQBUc/ I am trusting the responsible AD and the BESS WG chairs to apply due diligence to the rfc6514bis I-D as this I-D will rename the "MPLS Label" field.

-éric

This is primarily about providing multicast to a VPN.

It would be helpful if this also pointed to section 4 of RFC 8085 for BCP guidance on the congestion control implications for multicast traffic (and section 3.6 of RFC 8085 regarding controlled environments).

Thanks to the authors and the WG for their work on this document.

I am updating this ballot following the latest document update which addresses my comments. My thanks to the authors for this very helpful update.

I would like to share the following further comments on v16 of the document:

1) Please introduce normative reference to rfc9819 in addition to rfc9252 when referencing ESI filtering for EVPN with SRv6 (i.e., End.DT2M with Arg.FE2) since that RFC updates the base rfc9252.

2) For all use of the "MPLS Label" field in the PTA for SRv6, it would be good to say that the value 0 is put in that field per RFC6514 and the SRv6 SID is placed in the BGP Prefix SID appropriate TLV. And then state that only when transposition scheme is used for efficient BGP encoding, that the whole or portion of the function part of the SRv6 SID is encoded in the MPLS Label field. This is just a suggestion to clarify - I leave it to the authors.

Hi Rishabh, Daniel, Clarence, Hooman, and Jeffrey, 

The changes made in -16 [1] addresses all DISCUSS/COMMENT points raised in my previous ballot [2]. Thank you.

Please find below some very minor nits I tagged when reviewing the latest version, fwiw:

3.2.1.1.2:
   The SRv6 Endpoint Behavior of
   the SRv6 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6
   or End.DTMC46 Section 3.1 code point values.
                 ^^^^^^^^^^

3.3.2:
   The SRv6 Endpoint
   Behavior of the SRv6 SID Information Sub-TLV MUST encode one of
   End.DTMC4, End.DTMC6 or End.DTMC46 Section 3.1 code point value.
                                     ^^^^^^^^^^^^

4.1.2.1:
   The split-horizon procedures specified in P2MP MPLS LSPs
   Section 8.3.1.2 of [RFC7432] are sufficient for SR P2MP P-tunnels.
   ^^^^^^^^^^^^^^^^

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-sr-p2mp-15&url2=draft-ietf-bess-mvpn-evpn-sr-p2mp-16&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/bess/1QhhIKz_tE427kAsXLKMi_q6bkE/

Thank you to Paul Kyzivat for the GENART review.