Reviewer: Ben Niven-Jenkins Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-bess-vpls-multihoming-05.txt Reviewer: Ben Niven-Jenkins Review Date: 9th March 2020 IETF LC End Date: 12th March 2020 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is readable and presents an easy to follow solution to a complex problem. Major Issues: No major issues found. Minor issues: Section 3.2 - Deployment Considerations. “Note that a CE-ID=0 is invalid and a PE should discard such an advertisement.” Is that really a SHOULD (or a MUST)? Section 3.3.2.1 - RD. “Actual process of assigning Route Distinguisher values must guarantee its uniqueness per PE node.” Is that really a MUST? Section 6.1 - BGP based VPLS. “For compatibility with PEs that use multiple VE-IDs with non-zero label block values for multi-homing operation, it is a requirement that a PE receiving such advertisements must use the labels in the NLRIs associated with lowest VE-ID for PW creation.” Is that really a MUST? Nits: Section 1 - Introduction introduces the abbreviation BGP MH without expanding it on first use. As this is the only place in the document where the abbreviation BGP MH is used, I would suggest just expanding it in the introduction, i.e. s/BGP MH/BGP multi-homing/ Section 1.1 - General Terminology. You repeat the same two sentences at the end of paragraph 3 that also constitute paragraph 4: ‘A VPLS site is a grouping of ports on a PE that belong to the same VPLS domain. The terms "VPLS instance" and "VPLS domain" are used interchangeably in this document.’. Remove one of the sets of repeated sentences. Section 1.1 - General Terminology, paragraph 5. You say that “VPLS site” and “CE site” are used interchangeably but the definition of VPLS site doesn’t mention CEs and “CE site” implies (to me) the site of a particular CE device which isn’t exactly the same as a “VPLS site” as defined by the document. As there are only 2 instances of “CE site” in the document (outside of where you say it is used interchangeably with “VPLS site”), you may want to consider just replacing those 3 instances with “VPLS site” and removing the sentence stating “VPLS site” and “CE site” are interchangeable in section 1.1. Section 1.1 - General Terminology, paragraph 6. s/and label base is called as VE NLRI/and label base is called a VE NLRI/ (i.e. swap “as” for “a” Section 1.1 - General Terminology, paragraphs 7 & 8. s/Section Section 3.1/Section 3.1/ Section 3.3.3 - Election Procedures. s/specific to designated forwarded election procedures/specific to designated forwarder election procedures/ Section 3.5 - Pseudowire and Site-ID Binding Properties. The first sentence is very difficult to parse. I think what you are trying to say is something like “For the use case where a single PE provides connectivity to a set of CEs where some CEs are multi-homed and others are not, only a single pseudowire MAY be established.” Section 3.5 - Pseudowire and Site-ID Binding Properties. s/PE3 would establish/PE3 could establish/ (because using a single PW is optional as per the earlier MAY) Section 3.5 - Pseudowire and Site-ID Binding Properties. s/Since label allocation and pseudowire established is tied to site-ID/Since label allocation and pseudowire establishment is tied to site-ID/ Regards Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
