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@xxxxxxxxxxx> wrote:
On 6/25/2017 6:54 AM, Dan Romascanu wrote:
? 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?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-?
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@xxxxxxxx
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