Skip to main content

Last Call Review of draft-ietf-bess-virtual-subnet-05
review-ietf-bess-virtual-subnet-05-opsdir-lc-korhonen-2015-11-23-00

Request Review of draft-ietf-bess-virtual-subnet
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-11-24
Requested 2015-11-13
Authors Xiaohu Xu , Christian Jacquenet , Robert Raszuk , Truman Boyes , Brendan Fee
I-D last updated 2015-11-23
Completed reviews Secdir Last Call review of -05 by Donald E. Eastlake 3rd (diff)
Opsdir Last Call review of -05 by Jouni Korhonen (diff)
Rtgdir Early review of -02 by Ron Bonica (diff)
Assignment Reviewer Jouni Korhonen
State Completed
Request Last Call review on draft-ietf-bess-virtual-subnet by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2015-11-23
review-ietf-bess-virtual-subnet-05-opsdir-lc-korhonen-2015-11-23-00
Dear authors,



I have reviewed draft-ietf-bess-virtual-subnet-05 as part of the OPS-DIR 


directorate reviews and you should treat all comments as any IETF Last 


Call comments.






I found the document well written and easy to read/comprehend. The 


document is about ready for publications with small nits.






I did not find any text about operational aspects of the virtual subnet. 


I was not really even expecting to see those but if there _are_ already 


known good management / operational practises specifically in the 


virtual subnet context those would be nice to have listed. Few specific 


areas what I was thinking are where the line is when having more than 


one default gateway gets justified or are there operational concerns 


related the number of host routes etc. Not requiring this text though if 


the authors think it is not needed.




Small nits:
 * VRF, VDP, TTL are never expanded.
 * Section 3.7. line 422:
   "..contain ARP/ND entries of local hosts As a result, .."
                                       ^^^^^^^^
   I have issues parsing this sentence.
 * Since this is Informational RFC all references could also be
   Informational.

Clarifications and semi-substantial:
 * Section 4.2. Line 485 on non-support of IP Broadcast and Link-Local
   Multicast. Since IPv6 ND also relies on link-local multicast for
   quite a few things this section is a bit confusing. Are you saying
   IPv6 ND is also handled using L2VPN? I do not get that implression
   from the rest of the document. You might want to open this specific
   part a bit more how IPv6 ND is handled, since you have proxying also
   in place.
 * Section 7. security considerations.. I find the statement a bit bold
   that there are no additional security risks. At least the I would
   expect to see a reference to RFC6583 when it comes to IPv6 ND and
   e.g., opeartion of PE routers / ND proxies.

- Jouni