[Gen-art] Gen-ART Last Call review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[Brian E Carpenter <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt
Reviewer: Brian Carpenter
Review Date: 2015-09-30
IETF LC End Date: 2015-10-08
IESG Telechat date:

Summary: Ready with issues
--------

Comments:
---------

According to the writeup:
"Good consensus among a solid although small set of contributors
(two vendors on the draft and a third vendor supporting the proposal)."
I wonder if that really means "Nobody else cares." Going back in the
bess and l3vpn mail archives, I only found one significant technical
discussion (on the original individual draft version).

The AD Review asks for a number of changes. To be frank, it's a bit annoying
to be asked to do a review of a draft that will change during the Last Call.

All that said, I didn't identify any protocol issues and it seems like
a reasonable solution.

Major Issues:
-------------

>  This document
>  describes how the MP2MP tunnel can be simulated with a mesh of P2MP
>  tunnels, each of which is instantiated by Ingress Replication
>  [I-D.ietf-bess-ir]

You can't understand the current document without consulting ietf-bess-ir.
For example, there are numerous instances of the phrase "IR P-tunnel" which
is defined by ietf-bess-ir. IMHO, it's therefore a normative reference.

> The label may be shared
> with other P-tunnels, subject to the anti-ambiguity rules for
> extranet [I-D.ietf-bess-mvpn-extranet].

This or similar words appear several times. An implementer cannot implement
the current document without consulting ietf-bess-mvpn-extranet. IMHO, it's
therefore a normative reference.

Minor Issues:
-------------

> These specifications update RFC 6514.

Is that actually true? Or is it just an *extension* of RFC 6514, which
doesn't merit a formal "Updates: 6514"? [In other words, will anything bad
happen if an implementation of RFC 6514 doesn't add this?]

> 1.  Introduction
>
>   Section 11.2 of RFC 6513, "Partitioned Sets of PEs", describes two
>   methods of carrying bidirectional C-flow traffic over a provider core
>   without using the core as RPL or requiring Designated Forwarder
>   election.

Which RPL is that? Propbably not RFC6550. Whatever it means, it needs
to be expanded when first used.