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

["[e-mail]" <[e-mail]>]

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; [e-mail]
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
Lizhong, 
 
Thank you a lot for the review, please see my comments with [JY] as a prefix.
 
Regards,
Yuanlong
 
From: Pals [mailto:[e-mail]] On Behalf Of Lizhong Jin
Sent: Tuesday, June 02, 2015 5:55 PM
To: rtg-ads
Cc: rtg-dir; pals; [e-mail]
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