Reviewer: Tim Chown Review result: Has Issues Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a solution to optimise the efficient use of Ingress Replication in (IR) in Network Virtualisation Overlay (NVO) networks. The document is close to being Ready for publication. Its technical content and proposal seems sound, and useful, and the quality of writing good, but there is room for improvement and some extra clarity, particularly around terminology and use of RFC2119 language. General comments There are many, many, many acronyms in this document. This area is not one I have a detailed knowledge of, so I found myself rechecking the terminology several times as I read through the document. It would help if the terminology section was presented in alphabetic order, or at least an order where something (like BD) is explained in advance if its first use elsewhere (for BD, in IR forwarding mode). I understand the rationale for use of IR, where PIM is not implemented. A number of research and education networks are removing classic PIM from their backbones - there is surprisingly little multicast traffic in NREN networks, and the only significant application on the UK NREN network is EUMETSAT. While I am familiar with PIM (and am co-author of RFC8815) I am less familiar with IR so a little more introduction or pointers on it would be useful. I note also neither PIM nor IR feature in the references section. It’s not clear to me why BM traffic is split out from U traffic. Perhaps the rationale could be more explicit. The document, as a potential PS, makes use of RFC2119 language. However, its use seems inconsistent to me. In many places, the document says so-and-so will do something, and it’s not clear if that’s as a result of something previously defined via a MUST or SHOULD, or whether it should be a MUST or a SHOULD. A more specific example is page 8, where it says “Originating Router’s IP address MUST be set to an IP address of the PE that should be common…” - is that “should” really a “MUST”, a “SHOULD”, or do you mean “should”? It reads strangely. Another example follows on page 9, where the text says “its fields are set as follows” and then of the four points below vary in style, one says “is set to”, one says “MUST include” - do you mean “is set to” or “MUST” be set to”, or? And then just further down the page “its use SHOULD be an administrative choice”, which also reads oddly to me (and in section 7 the same choice is a plain “is an”). Page 10, “SHALL follow” - do you mean MUST be configured to follow, or will follow anyway because of the routing in place? Or 9.1(d), “will process” or “MUST process”. As I read through the document, there are many examples like this; a review of consistency might be a useful exercise. Nits: The quality of writing is good; I saw very few grammatical nits. In the terminology, delete “switch”, or say ToR switch. p.19 “will forward the BM”, missing “it”. The document often says “BM (Broadcast and Multicast)”, but sometimes “BM”. Just “BM” is fine as it is defined after its first use. -- Tim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
