Last Call Review of draft-ietf-bier-architecture-07
review-ietf-bier-architecture-07-genart-lc-romascanu-2017-06-25-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bier-architecture-??
Reviewer: Dan Romascanu
Review Date: 2017-06-25
IETF LC End Date: 2017-06-29
IESG Telechat date: 2017-07-06

Summary:

This document specifies a new architecture known as "Bit Index Explicit
Replication" (BIER) for the forwarding of multicast data packets through a
"multicast domain".  It does not require a protocol for explicitly building
multicast distribution trees, nor does it require intermediate nodes to
maintain any per-flow state. This architecture is .  While the Abstract and
Introduction of the document mentions Architecture as the principal scope, this
document goes well beyond the scope of a typical architectural document.
including detailed definitions of the procedures, terminology and normative
algorithms required for BIER.

The document is clear and detailed. Because of its structure, I am missing some
information that usually can be found in architecture documents. I included
these in the 'minor issues' list. Although none of these may be a show-stopper,
I believe that addressing these before document approval can improve the
quality of the document and of the overall BIER work.

Major issues:

Minor issues:

1. As the document is targeting 'Experimental' it would be useful to mention
what is the scope of the experiment. The charter actually says:

' The scope of the experiment will be
documented in the output of the Working Group.'

Would not the Architecture document be the right place for this? If not, is
there another document that deals or is planned to define the scope of the
experiment?

2. While the Abstract and Introduction of the document mentions Architecture as
the principal scope, this document is different from a typical architectural
document. While it defines well the procedures, terminology and normative
algorithms required for BIER Intra-domain forwarding, it goes well beyond the
level of detail that other similar documents go. Specifications of the
procedures and normative algorithm should be mentioned in Abstract and
Introduction, they occupy the same or more space than architecture.

3. On the other hand I am missing the relationship with other work items in the
BIER charter - there is no manageability section for example, there is no
reference to the performance impact in networks. Maybe these are dealt with in
a different document or documents or BIER, if so it would be good at least to
mention and reference these here.

4. I also would have expected the architecture document to refer the use cases
document and note which of the use cases are being addressed and how -
draft-ietf-bier-use-cases is not even included in the references.

5. Sections 3 to 6 mentioned repeatedly provisioning. As there is no Operations
and Manageability section as in many other Routing Area documents, it is not
clear how this is expected to happen. For example draft-ietf-bier-bier-yang is
not mentioned or referred. I suggest adding a note (and maybe references) for
clarity.

6. In section 8 I found:

'Every BFR must be provisioned to know which of its interfaces lead to
   a BIER domain and which do not.  If two interfaces lead to different
   BIER domains, the BFR must be provisioned to know that those two
   interfaces lead to different BIER domains. '

It seems that the two 'must' in these sentences would rather be capitalized.

Nits/editorial comments: