Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
draft-ietf-bess-mvpn-bidir-ingress-replication-04

This is not an easy document to read.  If it gave reasons, examples, and explained what it was accomplishing
with the information exchanged, that would probably help.

A very small point, and not a big deal:  The abstract says, "This specification updates RFC 6514," presumably to meet the I-D nits question.  But it doesn't say what, specifically, is updated, and I don't get that clearly from reading the rest of the document either (I presume that someone who knows 6514 well would understand; I think the explanation is in the paragraph in the introduction that mentions Ingress Replication tunnels, and there's a paragraph in the middle of Section 3.1...).  Can the sentence be expanded just a little (keeping it as one sentence) to summarise what the update is?  I'm thinking along the line of, "This specification updates RFC 6514 by [changing the procedures with respect to [whatever]]."

Here is Warren Kumari's OPS DIR review.
Summary: Ready, typo / grammar nits.

General:
I found this document to be very dense. At some point my brain started
dribbling out my ears and I largely gave up on trying to understand
the mechanism. This seems to be very much a niche application, and my
IP multicast and deep MPLS knowledge isn't up to the level of finding
issues with the logic.

Nits:

Abstract:
This document specifiess how
[O] specifiess
[P] specifies
[R] spelling

1: Introduction:
   With these two methods, all PEs of a particular VPN are separated
[O] all PEs
[P] all PEs (Provider Edge router)
[R] first use of acronym. The document does say it assumed familiarity
with terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582],
but this is before that, and also expanding PE here will help people
understand if they want to continue reading...

I have to agree with Alia's comments and Warren's review. Very dense. No clear justification. No examples.

warren kumari did the  opsdir review

I have one less and two more serious comments...

- Less seriously, "MP2MP tunnel" seems like a strange use of
language, I wondered if it might be better to call these an
MP2MP warren (as in rabbit warren, and of course bearing in
mind the ops-dir review:-)

- More seriously, this is another draft that simply has too
many acronyms and uses those too densely. For example, I just
find it really hard to believe that "If a PE, say PEx, is
connected to a site of a given VPN, and PEx's next hop
interface to some C-RPA is a VRF interface, then PEx MUST
advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of
whether it has any local Bidir-PIM join states corresponding
to the C-RPA learned from its CEs" is a useful sentence to
implementers. IMO enough folks have commented on this aspect
that the wg would be wise to seriously consider the
readibility of their output.  I've worked on enough EU-funded
projects that had write-only documents to be worried if the
IETF starts to produce those.  (This is not a discuss since
I've been assured that this is not a problem for implementers,
and while I do accept that, I also continue to worry about
it.)

- I am simply not in a position to evaluate section 4. And nor
was the assigned secdir reviewer. The same point about density
and that making any secdir review hard to impossible was noted
by the secdir reviewer for draft-ietf-bess-mvpn-bidir. I don't
think it'd be valid for me to put on a discuss on the basis
that nothing this complex has "no new security issues" but it
was tempting.

Overall, I think it would be best if this were returned to the
wg asking for significant improvement in clarity for readers.