Subject: Re: [Bier] [Gen-art] Genart last call review of draft-ietf-bier-architecture-07

From: Alissa Cooper <[email-masked]>
Date: Wed, 5 Jul 2017 13:24:19 -0400

Dan, thanks for your review. Authors, thanks for engaging with Dan’s review. I have entered a No Objection ballot position.

Alissa

> On Jun 25, 2017, at 6:54 AM, Dan Romascanu <[email-masked]> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
> 
> 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:
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art