Early Review of draft-ietf-l2vpn-vpls-pe-etree-07
review-ietf-l2vpn-vpls-pe-etree-07-rtgdir-early-jin-2015-06-02-00

Hello, 




I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes on
special request. The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate, please see 

​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir







Although these comments are primarily for the use of the Routing
ADs, it would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.




Document: draft-ietf-l2vpn-vpls-pe-etree-07.txt 


Reviewer: Lizhong Jin


Review Date: 2

nd

 June


IETF LC End Date: 


Intended Status: Standards Track




Summary:

 


I have some minor concerns about this document that I think should be resolved
before publication. 




Comments:




Overall, although there is no major technical issues for this
draft, it is strongly suggested to improve the English description to make it
neat, and easier to be understood.




Major Issues:




No major issues found




Minor Issues:




1.

      


Abstract: “services” should be
“service”




2.

      


Abstract: “the MAC address
based Ethernet forwarding engine and the PW work in the same way as before”,
you should tell the detail of “before” here, or add a reference here.




3.

      


Abstract: “is” should be “are”




4.

      


Section3 overall, suggest to
reorganize section 3. Split the section into two parts: 1. Introduction; 2.
Motivation




5.

      


Section3: “in fact, there is no
exact corresponding terminology in IETF yet.” “terminology” could not be a
reason. You should list the technology reason if you want to compare.




6.

      


Section3: “Though there were
proposals on using PW control word or PWs to indicate the root/leaf attribute
of an E-Tree frame, both methods are limited in that they are only applicable
to "VPLS only" networks.” You should have reference for other proposals.
But I don’t think you need to list these proposals, instead only say the
motivation of the VLAN based solution.




7.

      


Section4.1: “Fig. 1 and Fig. 2
(both figures are extracted from [RFC6246])”. You should switch the number of
Fig1 and Fig2, since Fig1 is a detail description of Fig2.




8.

      


Section4.1: “Therefore, the
association between an AC port and a PW on a VSI is difficult, sometimes even
impossible.” Could not understand what’s the purpose of this sentence here?




9.

      


Section4.1: “Assuming this
mechanism is implemented in the bridge module, it is quite straightforward to
infer a VPLS PE model with two VSIs to support the E-Tree (as shown in Fig.
3).” Could move the analysis to motivation section, or removed. And the logic
here is not right. The leaf/root VLAN indication is only for filtering, not
bridging. So it is not accurate to have Root/Leave S-VLAN here to get the
enhanced model.




10.

  


Section4.2: “and optionally MAY
be added with another root S-VLAN.” When and why add another root S-VLAN here?
And why use terminology “root S-VLAN”, not root VLAN as indicated in Figure4?




11.

  


Section4.2: “For an S-VLAN
tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs
SHOULD be translated to the root S-VLAN in the VPLS network domain”. The
description of S-VLAN tagged port is not accurate here. I think here, you want
to refer to a port receiving a packet with both S-VLAN & C-VLAN. So it is
better to say, “when receiving a packet with both S&C VLAN…”. Same
suggestion to previous paragraphs. If S-VLAN only packet received, still
translate S-VLAN to root S-VLAN?




12.

  


Section4.2: “the E-Tree
attribute may also be indicated with two I-SID tags in the bridge module”.
Suggest to remove since it is not part of this document.




13.

  


Section5.2: “For both methods,
VLAN mapping parameters from a remote PE can be provisioned or determined by a
signaling protocol as described in Section 6 when a PW is being established”.
For the global method, why we need signaling?




14.

  


Section5.3.1: “i.e., the local
leaf VLAN in a frame is translated to the remote leaf VLAN; the local root VLAN
in a frame is translated to the remote root VLAN”. Here you should refer back
to section 4.




15.

  


Section5.3.2: “Upon receiving
frames on the PW, add a VLAN tag with a value of the local root VLAN to the
frames.” Not understand here. Does that mean all receiving frames will be
considered to be from root? Then how to isolate traffic between two leaves?




16.

  


Section5.3.3: “If a PE is in
the Optimized Mode for a PW, upon transmit”. Suggest to: If a PE is in the
Optimized Mode for a PW, upon transmit to leaf only nodes.




17.

  


Section6.1: “If the bit V is
set, and the PE is capable of VLAN mapping, then the PE with the minimum IP
address MUST set VLAN-Mapping-Mode to TRUE;” Which IP address? The address in
the LDP IP header? 




18.

  


Section6.1: “2) If the P bit is
set, then:” If above is pseudo code, then the code format should be more
formal, to make it clear and neat.




19.

  


Section6.1: “If the PE is a
leaf-only node itself, then a label release message with a status code
"Leaf to Leaf PW released" is sent to the peer PE and exit the
process;” When both PE release the mapping. Then when one PE1 change the
setting to have both root&leaf, and send label mapping to PE2, will PE2 be
triggered to send label mapping to PE1? According to RFC5036, I think the answer
is no. You need additional mechanism here.




20.

  


Section6.1: the E-Tree Sub-TLV
parameters updating should be also mentioned in this section.




21.

  


Section6.2: “Data plane in the
VPLS is the same as described in Section 4.2 of [RFC4761], and data plane
processing for a PW is the same as described at the end of Section 6.1.” Why
same as RFC4761 here? Don’t you have VLAN-Mapping-Mode and other mode data
plane operation?




22.

  


Section8: This section is too
simple to remove it. Or please add more detail.




23.

  


Section9: New security concern
will include: since the outmost VLAN is leaf or root, it is easy to parse the
leaf and root VLAN information.




24.

  


Section10: The allocated value
should be “TBD”.




 




Regards




Lizhong