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

[Lizhong Jin <[e-mail]>]

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”

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