[bess] Opsdir last call review of draft-ietf-bess-evpn-optimized-ir-09

[Tim Chown via Datatracker <[e-mail]>]

Reviewer: Tim Chown
Review result: Has Issues

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft describes a solution to optimise the efficient use of Ingress
Replication in (IR) in Network Virtualisation Overlay (NVO) networks.

The document is close to being Ready for publication.  Its technical content
and proposal seems sound, and useful, and the quality of writing good, but
there is room for improvement and some extra clarity, particularly around
terminology and use of RFC2119 language.

General comments

There are many, many, many acronyms in this document.  This area is not one I
have a detailed knowledge of, so I found myself rechecking the terminology
several times as I read through the document.  It would help if the terminology
section was presented in alphabetic order, or at least an order where something
(like BD) is explained in advance if its first use elsewhere (for BD, in IR
forwarding mode).

I understand the rationale for use of IR, where PIM is not implemented.  A
number of research and education networks are removing classic PIM from their
backbones - there is surprisingly little multicast traffic in NREN networks,
and the only significant application on the UK NREN network is EUMETSAT.  While
I am familiar with PIM (and am co-author of RFC8815) I am less familiar with IR
so a little more introduction or pointers on it would be useful.  I note also
neither PIM nor IR feature in the references section.

It’s not clear to me why BM traffic is split out from U traffic.  Perhaps the
rationale could be more explicit.

The document, as a potential PS, makes use of RFC2119 language.  However, its
use seems inconsistent to me.  In many places, the document says so-and-so will
do something, and it’s not clear if that’s as a result of something previously
defined via a MUST or SHOULD, or whether it should be a MUST or a SHOULD.  A
more specific example is page 8, where it says “Originating Router’s IP address
MUST be set to an IP address of the PE that should be common…” - is that
“should” really a “MUST”, a “SHOULD”, or do you mean “should”?  It reads
strangely.  Another example follows on page 9, where the text says “its fields
are set as follows” and then of the four points below vary in style, one says
“is set to”, one says “MUST include” - do you mean “is set to” or “MUST” be set
to”, or?   And then just further down the page “its use SHOULD be an
administrative choice”, which also reads oddly to me (and in section 7 the same
choice is a plain “is an”).  Page 10, “SHALL follow” - do you mean MUST be
configured to follow, or will follow anyway because of the routing in place? 
Or 9.1(d), “will process” or “MUST process”.  As I read through the document,
there are many examples like this; a review of consistency might be a useful
exercise.

Nits:

The quality of writing is good; I saw very few grammatical nits.

In the terminology, delete “switch”, or say ToR switch.

p.19 “will forward the BM”, missing “it”.

The document often says “BM (Broadcast and Multicast)”, but sometimes “BM”. 
Just “BM” is fine as it is defined after its first use.

--
Tim