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

From: "[email-masked]" <[email-masked]>
Date: Sat, 8 Aug 2015 18:31:14 +0800

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

Regards
Lizhong
 
From: Jiangyuanlong
Date: 2015-06-11 05:48
To: Lizhong Jin; rtg-ads
CC: rtg-dir; pals; [email-masked]
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:[email-masked]] On Behalf Of Lizhong Jin
Sent: Tuesday, June 02, 2015 5:55 PM
To: rtg-ads
Cc: rtg-dir; pals; [email-masked]
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 
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.

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.

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".

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] 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.
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.

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.

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?

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.

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. 

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.

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"?

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.

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.

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.

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.

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.

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 .....

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.

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.

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

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 12 Aug 2015 11:44:34 +0000

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: [email-masked] [mailto:[email-masked]]
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

________________________________
Regards
Lizhong

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

Regards,
Yuanlong

From: Pals [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Tuesday, June 02, 2015 5:55 PM
To: rtg-ads
Cc: rtg-dir; pals; [email-masked]<mailto:[email-masked]>
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>

Summary:

Comments:

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.”

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

   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”.

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).

The bridge

   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.

   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). “

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.

[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).

[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.

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).

[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.

[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.

Regards
Lizhong

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Aug 2015 23:45:05 +0800

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
Date: 2015-08-12 19:44
To: [email-masked]; rtg-ads; David Allan I; Fedyk, Donald (Don); Giles Heron; Andrew G. Malis; Stewart Bryant (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 Lizhong,

 
Best regards,
Yuanlong

Regards
Lizhong
 
From: Jiangyuanlong
Date: 2015-06-11 05:48
To: Lizhong Jin; rtg-ads

Regards,
Yuanlong

Hello, 

 
Although Virtual Private Multicast Service (VPMS)   [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.

 
 
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.
 
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.

 

 

 

 

 
Regards
Lizhong

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 14 Aug 2015 22:23:53 +0800

For comment 17.
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).

[Lizhong]  I also could not accept such explanation. LDP ID is a stable ID
while LDP hello adjacency may not. By using LDP ID to select the
master/slave node is a common way in LDP protocol. If you use the IP
address in IP header of LDP message, it will bring network unstability.

------------------------------
Regards
Lizhong

On Wed, Aug 12, 2015 at 11:45 PM, [email-masked] <[email-masked]>
wrote:

> 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 <[email-masked]>
> *Date:* 2015-08-12 19:44
> *To:* [email-masked]; rtg-ads <[email-masked]>; David Allan I
> <[email-masked]>; Fedyk, Donald (Don)
> <[email-masked]>; Giles Heron <[email-masked]>; Andrew
> G. Malis <[email-masked]>; Stewart Bryant (stbryant)
> <[email-masked]>
> *CC:* rtg-dir <[email-masked]>; pals <[email-masked]>;
> draft-ietf-l2vpn-vpls-pe-etree
> <[email-masked]>
> *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
>
> Hi Lizhong,
>
>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *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
>
>
>
> ------------------------------
>
> Regards
>
> Lizhong
>
>
>
> *From:* Jiangyuanlong <[email-masked]>
>
> *Date:* 2015-06-11 05:48
>
> *To:* Lizhong Jin <[email-masked]>; rtg-ads <[email-masked]>
>
> *CC:* rtg-dir <[email-masked]>; pals <[email-masked]>;
> [email-masked]
>
> *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
>
> Lizhong,
>
>
>
> *From:* Pals [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Lizhong Jin
> *Sent:* Tuesday, June 02, 2015 5:55 PM
> *To:* rtg-ads
> *Cc:* rtg-dir; pals; [email-masked]
> *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
>
> 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.
>
> *Summary:*
> *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:*
>
> [JY] Not needed, since multiple E-Tree services may be deployed in a
> single VPLS network, and the solution aims to support this scenario.
>
> 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”.
>
>
>
>
>
> [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:
>
> 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.
>
> [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.
>
>    [VPMS <https://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-07#ref-VPMS>] or Point-to-Multipoint (P2MP) multicast is a somewhat
>
> [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.
>
> 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?
>
> "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.
>
> (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).
>
> 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:
>
> [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:
>
> 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:
>
> 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).
>
> “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.
>
>
>
> [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?
>
> 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.
>
> 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.
>
> [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.
>
> 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.
>
> [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?
>
> [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.”
>
>
>
> [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.
>
> 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.
>
>
>
> [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?
>

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 20 Aug 2015 12:20:59 +0000

Hi Lizhong,

In fact, there are 3 RFCs of LDP (RFC 5036, RFC 6870, and RFC 7275) are using IP addresses for tiebreaker, while LDP ID (or LSR ID) is not explicitly used for selection of nodes in any RFCs.
Thus, I don’t think there is any need to change it.

Thanks,
Yuanlong

From: Lizhong Jin [mailto:[email-masked]]
Sent: Friday, August 14, 2015 10:24 PM
To: Jiangyuanlong; rtg-ads; 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

For comment 17.
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).
[Lizhong]  I also could not accept such explanation. LDP ID is a stable ID while LDP hello adjacency may not. By using LDP ID to select the master/slave node is a common way in LDP protocol. If you use the IP address in IP header of LDP message, it will bring network unstability.

On Wed, Aug 12, 2015 at 11:45 PM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:
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.

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

Best regards,
Yuanlong

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]

Regards,
Yuanlong

Hello,

Summary:

Comments:

Major Issues:

No major issues found

Minor Issues:

The bridge

   the latter sections.

Regards
Lizhong

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Aug 2015 13:25:47 +0100

On 12/08/2015 16:45, [email-masked] wrote:
>
>         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?
>
>         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).
>

SB> I honestly do not understand the problem with the original text.

SB> Sure if you only use global you do not NEED signalling, but if you 
want to implement it that way it will work, and the text makes it clear 
that signalling is optional.

>         ==========
>
>         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.
>

SB> The correct document to use as the basis for this discussion is 
4447bis, since that is the description of PW signalling that has all the 
errors corrected.

SB> So is this protocol broken if the procedures in RFC4447bis are applied?

>         topology and TLV parameter updates.

Also can I suggest that the document is updated with the changes we know 
we are going to make so we know exactly what text we are dealing with 
and can deal with the unresolved issues withing that context.  When we 
have the text technically correct we will then need to do an English 
Language pass to pick up the concerns raised by our AD. However I am 
reluctant to do this, or ask someone else to do do it before the 
outstanding technical issues are all fixed.

If you think it is useful to set up a conference call to resolve this 
please let me know.

- Stewart

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 20 Aug 2015 12:30:14 +0000

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.

Thanks,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
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,

Best regards,
Yuanlong

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Regards,
Yuanlong

Hello,

Summary:

Comments:

Major Issues:

No major issues found

Minor Issues:

The bridge

   the latter sections.

Regards
Lizhong

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 20 Aug 2015 14:15:40 +0000

Hi Stewart,

A new revision has been uploaded which is based on the previous discussions:
https://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-pe-etree-08.txt

And I would like to have a conference call to further discuss with Lizhong on his concerns and those proposed resolutions.

Thanks,
Yuanlong

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, August 20, 2015 8:26 PM
To: [email-masked]; Jiangyuanlong; rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles Heron (giheron); agmalis
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: Re: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

On 12/08/2015 16:45, [email-masked]<mailto:[email-masked]> wrote:

SB> Sure if you only use global you do not NEED signalling, but if you want to implement it that way it will work, and the text makes it clear that signalling is optional.

==========

SB> The correct document to use as the basis for this discussion is 4447bis, since that is the description of PW signalling that has all the errors corrected.

Also can I suggest that the document is updated with the changes we know we are going to make so we know exactly what text we are dealing with and can deal with the unresolved issues withing that context.  When we have the text technically correct we will then need to do an English Language pass to pick up the concerns raised by our AD. However I am reluctant to do this, or ask someone else to do do it before the outstanding technical issues are all fixed.

If you think it is useful to set up a conference call to resolve this please let me know.

- Stewart

---

From: Lizhong Jin <[email-masked]>
Date: Sat, 22 Aug 2015 22:26:57 +0800

Stewart, you are the best guy to join the review.

Regards
Lizhong

On Thu, Aug 20, 2015 at 8:25 PM, Stewart Bryant <[email-masked]> wrote:

> we are going to make so we know exactly what text we are dealing with and
> can deal with the unresolved issues withing that context.  When we have the
> text technically correct we will then need to do an English Language pass
> to pick up the concerns raised by our AD. However I am reluctant to do
> this, or ask someone else to do do it before the outstanding technical
> issues are all fixed.
>

---

From: Lizhong Jin <[email-masked]>
Date: Sat, 22 Aug 2015 23:45:56 +0800

See inline below.

On Thu, Aug 20, 2015 at 8:30 PM, Jiangyuanlong <[email-masked]>
wrote:

> [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.
>
> 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

> *Sent:* Wednesday, August 12, 2015 11:45 PM
> *To:* Jiangyuanlong; rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles
> Heron (giheron); agmalis; stbryant
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 24 Aug 2015 02:01:34 +0000

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:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lizhong,

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:

Lizhong

Thanks,
Yuanlong

Hi Yuanlong,

Best regards,
Yuanlong

Regards,
Yuanlong

Hello,

Summary:

Comments:

Major Issues:

No major issues found

Minor Issues:

The bridge

   the latter sections.

Regards
Lizhong

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 28 Aug 2015 07:34:42 +0800

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
Date: 2015-08-24 10:01
To: Lizhong Jin
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
The default FEC used in LDP VPLS is Generalized PWid FEC, please see Sec. 6.1 of RFC 4762.
 
Thanks,
Yuanlong

See inline below.

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

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

Hi Yuanlong,

Regards
Lizhong
 
From: Jiangyuanlong
Date: 2015-08-12 19:44

 
Best regards,
Yuanlong

Regards
Lizhong
 
From: Jiangyuanlong
Date: 2015-06-11 05:48
To: Lizhong Jin; rtg-ads

Regards,
Yuanlong

Hello, 

 

 

 

 

 

 

 

 
Regards
Lizhong

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 28 Aug 2015 09:08:33 +0000

I hope we can discuss technical issues based on facts and reasoning rather than make judgments.

The LDP VPLS protocol (RFC 4762) is focused on the Generalized PWid FEC, while the PWid FEC Element is only briefly discussed in its appendix, actually the first sentence in “Appendix A” says:
“   This section is being retained because live deployments use this
   version of the signaling for VPLS.”
That means the section of “VPLS signaling using PWid FEC Element” is not normative (in fact, “VCID” in the texts is “VC ID”,  which is inherited from the old draft-ietf-pwe3-control-protocol-00, and not consistent with RFC 4447). I am not sure the WG want to supplement VPLS on the basis of it.

Even if we need to support PWid FEC Element in VPLS, the solution as you proposed cannot prevent a leaf PE from sending traffic to another leaf PE,  because both leaf PEs still regards the PW to be a valid PW.
It would work better if the PE sends a label mapping firstly and then send a label request to its peer PEs (so that they will reply with a label mapping respectively).

Regards,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
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

Regards
Lizhong

From: Jiangyuanlong<mailto:[email-masked]>
Date: 2015-08-24 10:01
To: Lizhong Jin<mailto:[email-masked]>
CC: rtg-ads<mailto:[email-masked]>; david.i.allan<mailto:[email-masked]>; Fedyk, Donald (Don)<mailto:[email-masked]>; Giles Heron (giheron)<mailto:[email-masked]>; agmalis<mailto:[email-masked]>; stbryant<mailto:[email-masked]>; rtg-dir<mailto:[email-masked]>; pals<mailto:[email-masked]>; draft-ietf-l2vpn-vpls-pe-etree<mailto:[email-masked]>
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

See inline below.

Lizhong

Thanks,
Yuanlong

Hi Yuanlong,

Best regards,
Yuanlong

Regards,
Yuanlong

Hello,

Summary:

Comments:

Major Issues:

No major issues found

Minor Issues:

The bridge

   the latter sections.

Regards
Lizhong

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 28 Aug 2015 09:31:37 +0000

Indeed, whether my understanding of Generalized PWid FEC signaling is correct, whether the signaling procedure is correct,  are under the examination of the whole WG (including you).

Thanks,
Yuanlong

Regards
Lizhong

Thanks,
Yuanlong

See inline below.

Lizhong

Thanks,
Yuanlong

Hi Yuanlong,

Best regards,
Yuanlong

Regards,
Yuanlong

Hello,

Summary:

Comments:

Major Issues:

No major issues found

Minor Issues:

The bridge

   the latter sections.

Regards
Lizhong