Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

[Jiangyuanlong <[e-mail]>]

Hi Lizhong,

Thanks for all the comments, on this last issue, we had discussed with the chairs and AD, it was felt the draft had agreement from the working group on the interpretation in the draft.
Please see the latest draft-ietf-l2vpn-vpls-pe-etree-09 for details.

Regards,
Yuanlong


From: [e-mail] [mailto:[e-mail]]
Sent: Friday, August 28, 2015 7:35 AM
To: Jiangyuanlong
Cc: rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles Heron (giheron); agmalis; stbryant; rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

It's meanless to have such discussion.

I have clearly pointed out the issue:
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 PE1 already receives label mapping from PE2, and PE1 is configured to be leaf-only, and PE1 will send label release to PE2. Then if PE1 is changed to leaf-root node, PE2 will not send mapping again. PW setup will fail.
And I also have clearly given you the solution by the call: simply remove the label release.

If your draft does not support PWid FEC, then OK, we could discuss whether your understanding of Generalized PWid FEC signaling is right. I will not comment again if the discussion could not focus.

Regards
Lizhong

From: Jiangyuanlong<mailto:[e-mail]>
Date: 2015-08-24 10:01
To: Lizhong Jin<mailto:[e-mail]>
CC: rtg-ads<mailto:[e-mail]>; david.i.allan<mailto:[e-mail]>; Fedyk, Donald (Don)<mailto:[e-mail]>; Giles Heron (giheron)<mailto:[e-mail]>; agmalis<mailto:[e-mail]>; stbryant<mailto:[e-mail]>; rtg-dir<mailto:[e-mail]>; pals<mailto:[e-mail]>; draft-ietf-l2vpn-vpls-pe-etree<mailto:[e-mail]>
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
The default FEC used in LDP VPLS is Generalized PWid FEC, please see Sec. 6.1 of RFC 4762.

Thanks,
Yuanlong


From: Lizhong Jin [mailto:[e-mail]]
Sent: Saturday, August 22, 2015 11:46 PM
To: Jiangyuanlong
Cc: rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles Heron (giheron); agmalis; stbryant; rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: Re: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

See inline below.


On Thu, Aug 20, 2015 at 8:30 PM, Jiangyuanlong <[e-mail]<mailto:[e-mail]>> wrote:
Hi Lizhong,

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.
[JY] Why PE2 cannot be triggered to send label mapping to PE1? IMO, we don't need any additional mechanism here. If the configuration is changed for a failed PW establishing session, then a new round of PW negotiations can take place between PE1 and PE2. Furthermore, the PW negotiation process is standardized in RFC 4447 rather than RFC 5036, and you can find answers there.
[Lizhong] You should give out the technical reason. There is no configuration changing on PE2, and PE1 release the mapping from PE2, then the PE2 will not send mapping again since DU mode is used for PW signaling. BTW, the PW signaling RFC4447 is based on RFC5036, and also updated by RFC6723. One method is, like RFC6723, PE1 need LDP request message to reestablish the PW.
[JY2] this is similar to comment 20 since it deals with topology and TLV parameter updates.
[JY3] According to Section 5.3.3 of RFC 4447, if PE2 decides to accept the Label Mapping message from PE1, but find out that it has no PW to PE1, it must initiate such signaling by sending a Label Mapping message to PE1.
The original texts in Section 5.3.3 of RFC 4447 says:
“   If PE2 decides to accept the Label Mapping message, then it has to
   make sure that a PW LSP is set up in the opposite (PE1-->PE2)   //here PW LSP is actually P2P PW
   direction.  If it has already signaled for the corresponding PW LSP
   in that direction, nothing more needs to be done.  Otherwise, it must
   initiate such signaling by sending a Label Mapping message to PE1.
   This is very similar to the Label Mapping message PE2 received, but
   the SAI and TAI are reversed.”
Therefore, PE1 don’t need to send an LDP request message in this case.

To resolve your concerns for this case, and to be clear in other cases, it is suggested to insert the following paragraph:
“A PE SHOULD send a Label Mapping message with an E-Tree Sub-TLV as per Section 5.3.3 of RFC 4447. A PE MUST send a Label Mapping message with an updated E-Tree Sub-TLV to all other PEs over corresponding LDP sessions when its role changes from leaf only to not leaf only (i.e., when a root node is added to a PE attached with only leaf nodes).”
before the sentence “If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree Sub-TLV in its peer’s PW label mapping message…” in Section 6.1.
[Lizhong] No, the new text does not solve the issue. Procedure of section 5.3.3 is for Generalized PWid FEC Element, you should care more about PWid FEC Element which is most widely used. It is clearly said in section 5.2:

Using the PWid FEC, each of the two pseudowire endpoints

   independently initiates the setup of a unidirectional LSP.  An

   outgoing LSP and an incoming LSP are bound together into a single

   pseudowire if they have the same PW ID and PW type.

Lizhong


Thanks,
Yuanlong

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, August 12, 2015 11:45 PM
To: Jiangyuanlong; rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles Heron (giheron); agmalis; stbryant
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

Hi Yuanlong,
I could not agree with some of your explanations, and would like to raise comment 13 & 19 as the major issue. Please AD and chairs pay attention to this. I believe we must resolve the two comments before any further steps. Thanks.

________________________________
Regards
Lizhong

From: Jiangyuanlong<mailto:[e-mail]>
Date: 2015-08-12 19:44
To: [e-mail]<mailto:[e-mail]>; rtg-ads<mailto:[e-mail]>; David Allan I<mailto:[e-mail]>; Fedyk, Donald (Don)<mailto:[e-mail]>; Giles Heron<mailto:[e-mail]>; Andrew G. Malis<mailto:[e-mail]>; Stewart Bryant (stbryant)<mailto:[e-mail]>
CC: rtg-dir<mailto:[e-mail]>; pals<mailto:[e-mail]>; draft-ietf-l2vpn-vpls-pe-etree<mailto:[e-mail]>
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
Hi Lizhong,

Please see my further comments inline with [JY2].
Thanks a lot for your discussion.

I also cc to Dave and Don for their suggestions, and cc to the chairs for their guidance.

Best regards,
Yuanlong


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Saturday, August 08, 2015 6:31 PM
To: Jiangyuanlong; rtg-ads
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

Hi, I missed the email, and sorry for the late reply. Please see inline below.

________________________________
Regards
Lizhong

From: Jiangyuanlong<mailto:[e-mail]>
Date: 2015-06-11 05:48
To: Lizhong Jin<mailto:[e-mail]>; rtg-ads<mailto:[e-mail]>
CC: rtg-dir<mailto:[e-mail]>; pals<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
Lizhong,

Thank you a lot for the review, please see my comments with [JY] as a prefix.

Regards,
Yuanlong

From: Pals [mailto:[e-mail]] On Behalf Of Lizhong Jin
Sent: Tuesday, June 02, 2015 5:55 PM
To: rtg-ads
Cc: rtg-dir; pals; [e-mail]<mailto:[e-mail]>
Subject: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt


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<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: 2nd 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”
[JY] Not needed, since multiple E-Tree services may be deployed in a single VPLS network, and the solution aims to support this scenario.
[Lizhong] Then why you use "uses" to describe "services"? I am referring the grammar error here.
[JY2] Please note that “which uses …” is an attributive clause describing the solution, not the services.
   “A generic Virtual Private LAN Service (VPLS) solution is specified
   for Ethernet-Tree (E-Tree) services which uses VLANs to indicate
   root or leaf traffic.”
To be clear, it is proposed to move it ahead in this way:
   “A generic Virtual Private LAN Service (VPLS) solution which uses VLANs to indicate
   root or leaf traffic is specified for Ethernet-Tree (E-Tree) services which uses VLANs to indicate
   root or leaf traffic.

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.
[JY] Actually, Section 4 and 5 describe the details of how the Ethernet forwarding engine and the PW work. I don't think we need to describe the details in an abstraction or forward reference any sections in the document here.
[Lizhong] I do not agree. The abstract section should give out the outline of whole concept. Use word "before" does not provide any information for the readers.
[JY2] it simply states that the MAC address based Ethernet forwarding engine and the PW will not be changed, and it is proposed to be replaced with “the MAC address based Ethernet forwarding engine and the PW work in the same way as before in [RFC4762] and [RFC4448] respectively”.


3.       Abstract: “is” should be “are”
[JY] There are 3 cases of "is" in the abstraction, but the suggested change is not applicable to any of them. From the sequence it seems you are referring to the last one, but the subject "A signaling mechanism" is not plural.
[Lizhong] OK, since signaling mechanism also include VLAN mapping, then I suggest to change "VLAN mapping negotiation" to "E-Tree attribute".
[JY2]  “E-Tree service attribute” is already used in MEF, thus its use may introduce confusion to the topic, but to be clear, it is proposed to move the verb ahead:
   “A signaling mechanism is further described for E-Tree
   capability and VLAN mapping negotiation is further described.”


4.       Section3 overall, suggest to reorganize section 3. Split the section into two parts: 1. Introduction; 2. Motivation
[JY] This is related to question 6 and 9, not sure what is the problem you are trying to solve as a whole.
[Lizhong] not well organized in this section. Let WG to decide.

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.
[JY] This sentence simply points out the fact that E-Tree is a new type of service (no corresponding service defined in IETF yet), the technical comparison is done in the E-Tree framework and is referenced in the next paragraph of this document.
[Lizhong] Please see the whole sentence I am referring:

Although Virtual Private Multicast Service (VPMS)

   [VPMS<https://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-07#ref-VPMS>] or Point-to-Multipoint (P2MP) multicast is a somewhat

   simplified version of this service, in fact, there is no exact

   corresponding terminology in IETF yet.

I could not understand why you say the "terminology" here refer to E-Tree.
[JY2]  To be clear, rewrite the 2nd part as “…, in fact, they are both multicast services and are different from an E-Tree service which may include both unicast and multicast traffic”.

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.
[JY] Both references were listed in the older versions of this draft indeed. Since there had been quite a lot of emails exchanged over these proposals before the WG adoption of this draft, this sentence simply reflects a summary of the conclusions. We can remove it in the next revision if the WG thinks it appropriate.
[Lizhong] OK.

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.
[JY] Not exactly, Fig.1 is not just a block of Fig. 2, it also describes CE access which is not shown in fig.2. Moreover, the order of CEs, the bridge and the VSI as they appear in Fig.1 and Fig.2 is also more consistent with their network topology. However, if we swap Fig.1 with Fig.2, then Fig.1 will forward reference to Fig.2, and this would be another disadvantage.
[Lizhong] Please refer to RFC6246. And let WG to decide. Thanks.

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?
[JY] It is proposed to update it with:
"Therefore, the association between an AC port and a PW on a VSI without using any VLAN is difficult, sometimes even impossible."
[Lizhong] still not agree. VLAN is not mandotary for the association. There are many implementations for VPLS to have the association without VLAN, e.g., virtual/physical port. I could not see the "difficult" here.
[JY2] To resolve the concern, it is proposed to remove “, sometimes even impossible” from the sentence.
(It should be noted that this paragraph does not mandate anything; and in Ethernet, a virtual port itself is usually implemented as VLAN;  using physical ports for internal connections in a device is not a common practice).

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.
[JY] Sorry, I am not sure I understand your reasoning here. It is already a standardized mechanism to encapsulate and switch an E-Tree service into two VLANs by a bridge according to IEEE 802.1Q-2011. Here is the only enhancement: a root VLAN is connected to a root VSI and all the root VSIs in peer PEs constitute one VPLS instance (with one mesh of PWs), and a leaf VLAN is connected to a leaf VSI and all the leaf VSIs constitute another VPLS instance (with another mesh of PWs), both VPLS instances are transparent to the E-Tree traffic, and all the filtering operations are done on the bridge according to the IEEE 802.1Q mechanism (that is, VSIs do not need to filter any leaf traffic).
[Lizhong] I mean your inferring is not right. In RFC6246, it says:

The bridge

   module has a single "Emulated LAN" interface over which it

   communicates with all VPLS forwarders, and each VPLS instance is

   represented by a unique S-VLAN tag.
That is the S-VLAN is used to indentify VLAN instance. But now S-VLAN is used to only identify E-Tree attribute, then it is not right to apply 802.1ad bridge mode to illustrate E-Tree mode.
[JY2] I think there is some misunderstanding here, S-VLANs for E-Tree is not different from S-VLANs for other services (for example, E-LAN). In IEEE 802.1, the only requirement is that two unique S-VLAN values are used (one used for root traffic forwarding, and the other used for leaf traffic forwarding); and the two unique S-VLAN values aforementioned can each represent a VPLS instance (just as described in RFC 6246). It is also noted in the document “both these VSIs have to share their learned MAC addresses” in page 7. VSIs forward E-Tree traffic just like a normal VPLS service and all E-Tree filtering happens in the bridge module.

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?
[JY] Figure 4 is a generalized diagram, where VLAN may be a C-VLAN, S-VLAN or B-VLAN, the texts in Section 4.2 describe each cases of specific VLANs respectively.
It is proposed to update the 1st sentence "In order to support the E-Tree in a more scalable way..." in Section 4.2 with:
"In order to support the E-Tree in a more generic and more scalable way..."
[Lizhong] A word "generic" does not solve the problem. Since you list the possibility to add one root C-VLAN and another root S-VLAN, I need to understand the scenario why we need that. The strange thing is, at the end of this section:

In all cases, the outermost VLAN in the resulted Ethernet header is

   used to indicate the E-Tree attribute of an Ethernet frame; this

   document uses VLAN to refer to this outermost VLAN for simplicity in

   the latter sections.
Then why we should add the first root C-VLAN?
And you should use same terminology across the document. And what's the different among "Root VLAN", "Root C-VLAN", "Root S-VLAN", "Root B-VLAN", and same question to leaf?
[JY2] Similar to the IEEE terminology (a generic VLAN may be a C-VLAN, S-VLAN or B-VLAN),  a Root VLAN may be a "Root C-VLAN", "Root S-VLAN", or "Root B-VLAN", the same applies to leaf VLAN. We will further clarify it in the terminology section by adding “it may be a C-VLAN, an S-VLAN or a B-VLAN” to the definition of “Root VLAN” and “Leaf VLAN”, that is:
“   Root VLAN: a VLAN ID used to indicate all the frames that are
   originated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN”
Please note that an 802.1ad bridge module may co-exist with 802.1Q bridge modules in the same PE (as shown in Fig.2 in RFC 6246), and both root C-VLAN and root S-VLAN may be used at the same time, so that seamless convergence can be realized (e.g., when 802.1Q bridges co-exist with 802.1D bridges in the same customer network and be attached to this PE).
To be clear, it is proposed to replace the 2nd paragraph in Section 4.2 with:
“For an untagged port (frames over this port are untagged) or VLAN-unaware port (VLAN tags in the frames are ignored), when the bridge module is a C-VLAN bridge, the Ethernet frames received from the root ACs SHOULD be tagged with a root C-VLAN and optionally MAY be added with another root S-VLAN; when the bridge module is an 802.1ad bridge, the Ethernet frames received from the root ACs SHOULD be tagged with a root S-VLAN (it can be added with a root C-VLAN firstly but this is out of the scope of this document). “

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.
[JY] This is not what we want. There are implementations in the industry that supports encapsulation of all traffics from a port into an S-VLAN (BBF TR-101 also specifies such a behavior). So no change is needed here.

If S-VLAN only packet received, still translate S-VLAN to root S-VLAN?
[JY]  Yes, some SPs may prefer to use such an S-VLAN translation in their networks for ease of management. This was also discussed in the L2VPN WG before and a consensus was reached.
[Lizhong] Then I could not agree you use "SHOULD" to mandatory the translation. It is not necessary to do translation for S-VLAN only packet in many cases. Could WG chair confirm the consensus Yuanlong refers to.
[JY2]  Maybe the previous L2VPN chairs has something to say since all those details were discussed in L2VPN WG as early as in 2012. I have no strong opinion to change “SHOULD” to “MAY”, but it would be better to give a preference when several options are given.

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.
[JY] As I remember, this note was added to resolve a comment raised in the L2VPN WG mailing list, and it was accepted into the document with no objection. This note is totally informational, and I am not sure it is appropriate to delete it.
[Lizhong] You describe the brief method, but does not provide the detail. My concern is, if there is future document to describe E-Tree for PBB-VLAN, and basic method is different with this document, then there will be conflict.
[JY2] Both Don & Dave mentioned this approach as a valid option (in http://www.ietf.org/mail-archive/web/l2vpn/current/msg03433.html and http://www.ietf.org/mail-archive/web/l2vpn/current/msg03365.html respectively), and this paragraph was added in the E-Tree I-D before the WG adoption. IMO, this is informational and is useful, but let the WG decide it.

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?
[JY] Just as the sentence says, the global VLAN method does not rely on signaling for its work.
But the SPs may prefer to use one method (e.g., global VLAN based) in scenario A and the other method (e.g., local VLAN based) in scenario B, and they would like to keep both methods work in a similar way, so the signaling protocol was designed to be applicable in both methods to give them a similar operation experience (if signaling is supported).
[Lizhong] I don't agree, what if deploying only global mode? You are talking about the operational experience, but I am talking about the technology. It is very confusing for the readers.
[JY2] Firstly, signaling for global method is not mandatory. Secondly, when control plane is needed, it is simple to implement if the same signaling can be used in both cases. BTW, even in the global mode, we may save some work in configuration if we have signaling capability (thus we only need to configure two VLAN values per router).

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.
[JY] At the end of Section 4, it already says:
"  In all cases, the outermost VLAN in the resulted Ethernet header is
   used to indicate the E-Tree attribute of an Ethernet frame; this
   document uses VLAN to refer to this outermost VLAN for simplicity in
   the latter sections."
Since there are dozens of "VLAN"s in section 5 & 6 ("the latter sections" aforementioned), referring to Section 4 for each use of VLAN is thus both unnecessary and cumbersome.
[Lizhong] But here is "local leaf VLAN" and "remote leaf VLAN", if I expand, they will change to "local leaf outermost VLAN" and "remote leaf outermost VLAN". Then question is what is the "remote leaf outermost VLAN"?
[JY2] No, we did not hint such a expansion. The E-Tree VLAN is generic (it may be C-VLAN, S-VLAN or B-VLAN), and actually indicated by the outermost VLAN. See comment 10 for the terminology clarification.

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?
[JY] Yes, all the received frames from the PW will be from roots. As the 1st paragraph in this section already says:"the VPLS PE with a traditional VSI can only be attached with root nodes."
[Lizhong] OK.

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.
[JY] As it already says in the 1st paragraph of Section 5.3.3, a PE works in Optimized Mode for a PW only when its peer PE is attached with only leaf nodes. Why add this condition again (in implementation, you need an extra data plane operation to determine whether this condition is met, furthermore, it is difficult to determine whether a destination node is a root or leaf in the data plane)?
[Lizhong] no, by signaling, the dataplane should know the remote PE is leaf only or not. What I mean is, the drop operation is only valid for leaf-only nodes.
[JY2] this is always true, so the condition is not needed in the data plane. To be clear, it is proposed to update the 1st sentence in Section 5.3.3 ”When two PEs (both have E-Tree capability) are inter-connected with a PW ……its peer PE (e.g., PE1) should then work in the optimized mode for this PW.”

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?
[JY] Yes.
[Lizhong] you should explicitly say that. But I personaly suggest to compare the LDP ID in LDP signaling.
[JY2] To be consistent with BGP section, suggest to keep it as is (in both cases, IP addresses used for comparison are extracted from their respective IP sessions).


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.
[JY] Thanks, we will remove the character ":" in the next revision. Does this resolve your concerns?
[Lizhong] you could refer to RFC4379 section 4.4.
[JY2] thanks, we will.

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.
[JY] Why PE2 cannot be triggered to send label mapping to PE1? IMO, we don't need any additional mechanism here. If the configuration is changed for a failed PW establishing session, then a new round of PW negotiations can take place between PE1 and PE2. Furthermore, the PW negotiation process is standardized in RFC 4447 rather than RFC 5036, and you can find answers there.
[Lizhong] You should give out the technical reason. There is no configuration changing on PE2, and PE1 release the mapping from PE2, then the PE2 will not send mapping again since DU mode is used for PW signaling. BTW, the PW signaling RFC4447 is based on RFC5036, and also updated by RFC6723. One method is, like RFC6723, PE1 need LDP request message to reestablish the PW.
[JY2] this is similar to comment 20 since it deals with topology and TLV parameter updates.

20.   Section6.1: the E-Tree Sub-TLV parameters updating should be also mentioned in this section.
[JY] Could you elaborate more on the specific requirements and scenarios in your mind? Are you suggesting to support versions for this TLV? I am not sure we need such a complex mechanism.
[Lizhong] The most simple updating mechanims is to LDP withdraw and mapping again. If you want to be simple, it is better to explictly say that.
[JY2] Please note that RFC 7152 which specifies the requirements for E-Tree does not have such a requirement. Definitely, LDP withdrawal and mapping (both have already been defined in RFC 4447) can be used in updating PW labels and TLVs in LDP VPLS, but scenarios and requirements are also needed. Maybe a new I-D is better to serve this purpose. The guidance from the WG chairs is needed.

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?
[JY] Please see the end of section 6.1, it says:
"   Data plane processing for this PW is as following:
   If Optimized-Mode is TRUE, then data plane processing as described
   in Section 5.3.3 applies.
   If VLAN-Mapping-Mode is TRUE, then data plane processing as
   described in Section 5.3.1 applies.
   If Compatible-Mode is TRUE, then data plane processing is as
   described in Section 5.3.2."
   These sub-sections definitely deal with E-Tree specific data plane operations such as VLAN mapping.
[Lizhong] You should say that, like: except described in section 6.1, other dataplane behavior is same as .....
[JY2] They are on different topic: the end of Section 6.1 covers PW processing, while Section 4.2 of [RFC4761] covers VPLS data plane.
To be clear, it is proposed to say:”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 in this document.”

22.   Section8: This section is too simple to remove it. Or please add more detail.
[JY] The details are already covered in Section 4 and Appendix A, so this section is just a summary of the application scenarios it can work.
[Lizhong] since covered, why we need summary here? Let WG decide.
[JY2] Please note that RFC 7152 Section 5.2 has such a requirement.

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.
[JY] It is unclear to me what is the security hole you are trying to indicate and what security measure is in your mind. Could you elaborate a little more on it? In my opinion, VLANs in this document are not more vulnerable compared with the VLANs in a tagged PW (see RFC 4448) and the security measures as proposed in RFC 4762 and RFC 4448 are sufficient.
[Lizhong] compared with VPLS, parse the VLAN could get the E-Tree topology for the E-tree VPLS. Topology information leaking is the concern.
[JY2] yes, an intruder inside a carrier network may get the information on the 2 E-Tree VLAN values used by the carrier, but is it worse than a single VLAN value in the case of a traditional VPLS? Are there any security measures different? I am still in doubt.

24.   Section10: The allocated value should be “TBD”.
[JY] Sorry, I failed to understand the point. But all the values have already been allocated officially by IANA, why do you suggest to use "TBD" instead?
[Lizhong] I think IANA is pre-allocated, not final. Let WG decide.

Regards
Lizhong