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 rev. 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 Rosen, Karthik Subramanian, Zhaohui Zhang
Draft 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 Nystrom (diff)
Opsdir Last Call review of -03 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-bess-ir-03-opsdir-lc-wu-2016-08-08
Reviewed rev. 03 (document currently at 05)
Review result Has Nits
Review completed: 2016-08-08

Review
review-ietf-bess-ir-03-opsdir-lc-wu-2016-08-08









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