[bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss

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-bess-mvpn-evpn-sr-p2mp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-bess-mvpn-evpn-sr-p2mp-15
CC @evyncke

Thank you for the work put into this document.

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

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

Please note that Tim Winters is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir review as well when it will
be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/reviewrequest/22937/

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Sections 3 & 5.2

Keeping the field name of "MPLS Label" (singular) is really misleading as it
can contains SRV6 SID. Did the WG/authors consider updating RFC 6514 to change
the field name ?


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


## COMMENTS (non-blocking)

### Abstract

s/This document describes/This document specifies/

### Section 1

s/allow a Service Provider/allow a network operator/

s/This document describes/This document specifies/

While the statements `The reader is expected...` are valid in a RFC, they do
not help the IESG review by a non expert.

### Section 3.1.2

To be honest, I failed to follow the procedure... A decriptive figure would
help a lot. The same comment for the whole section 4.

### Section 7

Please properly define `IMET`.

No need to define twice the "BUM".

What is a `NVE`?

### Section 8

Having a list of implementations is nice, but if the document refers to RFC
7942, then it should follow section 2 of this RFC rather than having a very
succint description.

### Section 9

Please add also a URI for "SRv6 Endpoint Behaviors" registry.