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
>
>