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

[Jiangyuanlong <[e-mail]>]

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]
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.
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.
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.
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.
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.
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.
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?
[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."
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).
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..."
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.
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.
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).
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.
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."
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)?
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.
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?
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.
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.
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.
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.
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.
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?
Regards
Lizhong