Last Call Review of draft-ietf-bess-ir-03
review-ietf-bess-ir-03-opsdir-lc-wu-2016-08-08-00
| Request | Review of | draft-ietf-bess-ir |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2016-08-10 | |
| Requested | 2016-08-01 | |
| Authors | Eric C. Rosen , Karthik Subramanian , Zhaohui (Jeffrey) Zhang | |
| I-D last updated | 2016-08-08 | |
| Completed reviews |
Genart Last Call review of -03
by Paul Kyzivat
(diff)
Genart Last Call review of -03 by Paul Kyzivat (diff) Secdir Last Call review of -03 by Magnus Nyström (diff) Opsdir Last Call review of -03 by Qin Wu (diff) |
|
| Assignment | Reviewer | Qin Wu |
| State | Completed | |
| Request | Last Call review on draft-ietf-bess-ir by Ops Directorate Assigned | |
| Reviewed revision | 03 (document currently at 05) | |
| Result | Has nits | |
| Completed | 2016-08-08 |
review-ietf-bess-ir-03-opsdir-lc-wu-2016-08-08-00
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 document updates RFC RFCs 6513 and 6514 and add additional details to clarify the use of Ingress Replication tunnels in Multicast VPN that is not clear in the RFC6513 and RFC6514. It doesn ’ t introduce any protocol extension or new procedure. I think this document is ready for publication. Here are a few editorial comments: 1. Section 2, Paragraph 8 said: “ Since data traveling along an IR P-tunnel is always unicast from parent node to child node, it can be convenient to think of an IR P-tunnel as a P2MP tree whose arcs are unicast tunnels. ” What “ arcs ” means in this sentence? 2. Section 2, last paragraph Provide reference to Inclusive P-tunnels and Selective P – tunnels. 3. Section 6, last paragraph: It looks this paragraph is the consequence of the previous paragraph, but I don ’ t see how duplication prevention mechanism is related to determine the packet's ingress PE based on IR P-tunnel label. 4. Section 7.1, paragraph 4: This section also discuss the procedure of RFC6513 section 9.1.1 “ Discard Packet from Wrong PE ” , I am wondering how this part is related to Section 6 “ A Note on IR P-tunnels and 'Discarding Packets from the Wrong PE' ” 5. Section 7.2, paragraph 1 said: “ Each intermediate node is a leaf node of an "upstream segment" and a parent node of one or more "downstream segments". “ s/leaf node/child node 6. Section 9, last paragraph: s/I.e.,/i.e., 7. Section 1 Would it be good to remove the last sentence in paragraph 8,9,10 since paragraph 11,12 and 13 have clarified what additional details this document add to RFC6513 and RFC6514, keeping the last sentence in the paragraph 8,9,10 looks verbose and tedious, in my personal opinion. -Qin