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-l2vpn-vpls-pe-etree-07.txt Reviewer: Lizhong Jin Review Date: 2 nd June IETF LC End Date: Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Overall, although there is no major technical issues for this draft, it is strongly suggested to improve the English description to make it neat, and easier to be understood. Major Issues: No major issues found Minor Issues: 1.        Abstract: “services” should be “service” 2.        Abstract: “the MAC address based Ethernet forwarding engine and the PW work in the same way as before”, you should tell the detail of “before” here, or add a reference here. 3.        Abstract: “is” should be “are” 4.        Section3 overall, suggest to reorganize section 3. Split the section into two parts: 1. Introduction; 2. Motivation 5.        Section3: “in fact, there is no exact corresponding terminology in IETF yet.” “terminology” could not be a reason. You should list the technology reason if you want to compare. 6.        Section3: “Though there were proposals on using PW control word or PWs to indicate the root/leaf attribute of an E-Tree frame, both methods are limited in that they are only applicable to "VPLS only" networks.” You should have reference for other proposals. But I don’t think you need to list these proposals, instead only say the motivation of the VLAN based solution. 7.        Section4.1: “Fig. 1 and Fig. 2 (both figures are extracted from [RFC6246])”. You should switch the number of Fig1 and Fig2, since Fig1 is a detail description of Fig2. 8.        Section4.1: “Therefore, the association between an AC port and a PW on a VSI is difficult, sometimes even impossible.” Could not understand what’s the purpose of this sentence here? 9.        Section4.1: “Assuming this mechanism is implemented in the bridge module, it is quite straightforward to infer a VPLS PE model with two VSIs to support the E-Tree (as shown in Fig. 3).” Could move the analysis to motivation section, or removed. And the logic here is not right. The leaf/root VLAN indication is only for filtering, not bridging. So it is not accurate to have Root/Leave S-VLAN here to get the enhanced model. 10.    Section4.2: “and optionally MAY be added with another root S-VLAN.” When and why add another root S-VLAN here? And why use terminology “root S-VLAN”, not root VLAN as indicated in Figure4? 11.    Section4.2: “For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs SHOULD be translated to the root S-VLAN in the VPLS network domain”. The description of S-VLAN tagged port is not accurate here. I think here, you want to refer to a port receiving a packet with both S-VLAN & C-VLAN. So it is better to say, “when receiving a packet with both S&C VLAN…”. Same suggestion to previous paragraphs. If S-VLAN only packet received, still translate S-VLAN to root S-VLAN? 12.    Section4.2: “the E-Tree attribute may also be indicated with two I-SID tags in the bridge module”. Suggest to remove since it is not part of this document. 13.    Section5.2: “For both methods, VLAN mapping parameters from a remote PE can be provisioned or determined by a signaling protocol as described in Section 6 when a PW is being established”. For the global method, why we need signaling? 14.    Section5.3.1: “i.e., the local leaf VLAN in a frame is translated to the remote leaf VLAN; the local root VLAN in a frame is translated to the remote root VLAN”. Here you should refer back to section 4. 15.    Section5.3.2: “Upon receiving frames on the PW, add a VLAN tag with a value of the local root VLAN to the frames.” Not understand here. Does that mean all receiving frames will be considered to be from root? Then how to isolate traffic between two leaves? 16.    Section5.3.3: “If a PE is in the Optimized Mode for a PW, upon transmit”. Suggest to: If a PE is in the Optimized Mode for a PW, upon transmit to leaf only nodes. 17.    Section6.1: “If the bit V is set, and the PE is capable of VLAN mapping, then the PE with the minimum IP address MUST set VLAN-Mapping-Mode to TRUE;” Which IP address? The address in the LDP IP header? 18.    Section6.1: “2) If the P bit is set, then:” If above is pseudo code, then the code format should be more formal, to make it clear and neat. 19.    Section6.1: “If the PE is a leaf-only node itself, then a label release message with a status code "Leaf to Leaf PW released" is sent to the peer PE and exit the process;” When both PE release the mapping. Then when one PE1 change the setting to have both root&leaf, and send label mapping to PE2, will PE2 be triggered to send label mapping to PE1? According to RFC5036, I think the answer is no. You need additional mechanism here. 20.    Section6.1: the E-Tree Sub-TLV parameters updating should be also mentioned in this section. 21.    Section6.2: “Data plane in the VPLS is the same as described in Section 4.2 of [RFC4761], and data plane processing for a PW is the same as described at the end of Section 6.1.” Why same as RFC4761 here? Don’t you have VLAN-Mapping-Mode and other mode data plane operation? 22.    Section8: This section is too simple to remove it. Or please add more detail. 23.    Section9: New security concern will include: since the outmost VLAN is leaf or root, it is easy to parse the leaf and root VLAN information. 24.    Section10: The allocated value should be “TBD”.   Regards Lizhong