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 <[email protected]> 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 > [email protected] > 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
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
