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

I picked up shepherd of this doc. Will reply by end of week to Dan's,
Eric's comments ...

thanks

-- tony

On Tue, Jun 27, 2017 at 7:42 AM, Eric C Rosen <erosen@juniper.net> wrote:

> On 6/25/2017 6:54 AM, Dan Romascanu 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> <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?
>
>
> I don't really know what is meant by "the experiment" or "scope of the
> experiment", but I'm pretty sure it is not relevant to the architecture (or
> to the forwarding rules).
>
> I don't know if there is another document discussing "scope of the
> experiment", or if such a document is actually needed.  That would be a
> question for the WG chairs.
>
> 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.
>
>
> I can add a few sentences to the abstract and introduction to make it
> clear that the procedures for fowarding BIER packets within a BIER domain
> specified in this document.
>
> 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.
>
>
> There is no requirement to include a manageability section.
>
> I believe there is ongoing work having to do with Operations and
> Management of BIER, but as that does not help to understand the
> architecture (or forwarding procedures), I don't think it would be
> appropriate to reference that work.
>
> With regard to the performance impact, if the question is speed of
> forwarding, there is mention of the fact that the number of lookups needed
> to forward a BIER packet is on the order of the number of neighbors.   I
> don't know what else can really be said at this level of detail, as the
> actual forwarding performance will depend a great deal on the
> implementation.  I'm not worried too much about that, because if BIER
> implementations do not perform well, the technology will not catch on.
>
> 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.
>
>
> I don't see any reason why the architecture document should reference the
> "use cases" document.  An explanation of how to apply the architecture to
> each use case is not within the scope of the architecture document.
>
> 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.
>
>
> How OAM is "expected to happen" would be outside the scope of this
> document.
>
> For example draft-ietf-bier-bier-yang is
> not mentioned or referred. I suggest adding a note (and maybe references) for
> clarity.
>
>
> I don't see any reason to reference that document.
>
> 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.
>
>
>
>
> I will make that change.
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky