Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
Lizhong Jin <lizho.jin@gmail.com> Fri, 14 August 2015 14:24 UTC
Return-Path: <lizho.jin@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB081A8909; Fri, 14 Aug 2015 07:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtP7BcH3ZMQO; Fri, 14 Aug 2015 07:23:56 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F5A1A8902; Fri, 14 Aug 2015 07:23:55 -0700 (PDT)
Received: by lahi9 with SMTP id i9so44653479lah.2; Fri, 14 Aug 2015 07:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BT/kx0LJ5xzuxEOBqS7OceoZlukGSpiHjJ0nTSfwXN4=; b=U5iQHg6WHgQ5sby8oQmrWKSHxUWkL0dPIXv8qGCbX5lqZDoOc7vK/KeyfANf2yCemN uh9R9OigtmcoxsFA9P538PiIbCSqlAlqxZYXxN4Ofo9dXZbKvfaaywiSIsedi/tfD+rw NW9pH8IbmyiPFC4x+3LaYCq7zbzZ8Uc0Ql/YGWVitOwOrnM81Xu9WuMxLl0J0Zq2DwzW 5miPLpd8+f9on4PrsId38f8m2guTkc6MlrRnbbbZ8EiC2hkYGwCz0drzLVIyzEyEi9iw zBIF00whhUWkVUcvlk5sHtvzolfLmkKSZG60+viUgVAYsLRuAh89l4HO07THJPC55qUL 6UZQ==
MIME-Version: 1.0
X-Received: by 10.152.6.65 with SMTP id y1mr30486918lay.58.1439562234034; Fri, 14 Aug 2015 07:23:54 -0700 (PDT)
Received: by 10.25.211.67 with HTTP; Fri, 14 Aug 2015 07:23:53 -0700 (PDT)
In-Reply-To: <201508122345018343936@gmail.com>
References: <CAH==cJw0gYz17bWYwe6+VKVCcWjYZR=j0V5f5Ywec_jXnte62Q@mail.gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A900449@szxema506-mbs.china.huawei.com> <20150808183111884135100@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A9B3543@szxema506-mbs.china.huawei.com> <201508122345018343936@gmail.com>
Date: Fri, 14 Aug 2015 22:23:53 +0800
Message-ID: <CAH==cJyGdyVODMn9UwRKGaucs3335khk0W7RKurGn65zkyOM5w@mail.gmail.com>
From: Lizhong Jin <lizho.jin@gmail.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, rtg-ads <rtg-ads@tools.ietf.org>, "Giles Heron (giheron)" <giheron@cisco.com>, agmalis <agmalis@gmail.com>, stbryant <stbryant@cisco.com>
Content-Type: multipart/alternative; boundary="089e01493db2977f2b051d4633b4"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/ZbxzAzXa2v55eGUV4endoMqV8WE>
Cc: rtg-dir <rtg-dir@ietf.org>, draft-ietf-l2vpn-vpls-pe-etree <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, pals <pals@ietf.org>
Subject: Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 14:24:05 -0000
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, lizho.jin@gmail.com <lizho.jin@gmail.com> 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 <jiangyuanlong@huawei.com> > *Date:* 2015-08-12 19:44 > *To:* lizho.jin@gmail.com; rtg-ads <rtg-ads@tools.ietf.org>; David Allan I > <david.i.allan@ericsson.com>; Fedyk, Donald (Don) > <donald.fedyk@alcatel-lucent.com>; Giles Heron <giheron@cisco.com>; Andrew > G. Malis <agmalis@gmail.com>; Stewart Bryant (stbryant) > <stbryant@cisco.com> > *CC:* rtg-dir <rtg-dir@ietf.org>; pals <pals@ietf.org>; > draft-ietf-l2vpn-vpls-pe-etree > <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org> > *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt > > 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:* lizho.jin@gmail.com [mailto:lizho.jin@gmail.com] > *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 > > > > Hi, I missed the email, and sorry for the late reply. Please see inline > below. > > > ------------------------------ > > Regards > > Lizhong > > > > *From:* Jiangyuanlong <jiangyuanlong@huawei.com> > > *Date:* 2015-06-11 05:48 > > *To:* Lizhong Jin <lizho.jin@gmail.com>; rtg-ads <rtg-ads@tools.ietf.org> > > *CC:* rtg-dir <rtg-dir@ietf.org>; pals <pals@ietf.org>; > draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org > > *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:pals-bounces@ietf.org <pals-bounces@ietf.org>] *On > Behalf Of *Lizhong Jin > *Sent:* Tuesday, June 02, 2015 5:55 PM > *To:* rtg-ads > *Cc:* rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org > *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. > > [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.” > > > > > > 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 <https://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-07#ref-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. > > [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. > > [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. > > [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). > > > > 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. > > [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: > > "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? > > [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). “ > > > > 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. > > [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? > > [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. > > [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. > > [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"? > > [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. > > [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). > > > > > > 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. > > [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. > > > > 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 ..... > > [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. > > > > 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 > >
- [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-pe… Lizhong Jin
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… lizho.jin@gmail.com
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… lizho.jin@gmail.com
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Lizhong Jin
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Stewart Bryant
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Lizhong Jin
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Lizhong Jin
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… lizho.jin@gmail.com
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Lizhong Jin
- Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2… Jiangyuanlong