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

[Lizhong Jin <[e-mail]>]

See inline below.


On Thu, Aug 20, 2015 at 8:30 PM, Jiangyuanlong <[e-mail]>
wrote:

> Hi Lizhong,
>
>
>
> 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.
>
> [JY3] According to Section 5.3.3 of RFC 4447, if PE2 decides to accept the
> Label Mapping message from PE1, but find out that it has no PW to PE1, it
> must initiate such signaling by sending a Label Mapping message to PE1.
>
> The original texts in Section 5.3.3 of RFC 4447 says:
>
> “   If PE2 decides to accept the Label Mapping message, then it has to
>
>    make sure that a PW LSP is set up in the opposite (PE1-->PE2)   //here
> PW LSP is actually P2P PW
>
>    direction.  If it has already signaled for the corresponding PW LSP
>
>    in that direction, nothing more needs to be done.  Otherwise, it must
>
>    initiate such signaling by sending a Label Mapping message to PE1.
>
>    This is very similar to the Label Mapping message PE2 received, but
>
>    the SAI and TAI are reversed.”
>
> Therefore, PE1 don’t need to send an LDP request message in this case.
>
>
>
> To resolve your concerns for this case, and to be clear in other cases, it
> is suggested to insert the following paragraph:
>
> “A PE SHOULD send a Label Mapping message with an E-Tree Sub-TLV as per
> Section 5.3.3 of RFC 4447. A PE MUST send a Label Mapping message with an
> updated E-Tree Sub-TLV to all other PEs over corresponding LDP sessions
> when its role changes from leaf only to not leaf only (i.e., when a root
> node is added to a PE attached with only leaf nodes).”
>
> before the sentence “If a PE has sent an E-Tree Sub-TLV but does not
> receive any E-Tree Sub-TLV in its peer’s PW label mapping message…” in
> Section 6.1.
>
[Lizhong] No, the new text does not solve the issue. Procedure of section
5.3.3 is for Generalized PWid FEC Element, you should care more about PWid
FEC Element which is most widely used. It is clearly said in section 5.2:

Using the PWid FEC, each of the two pseudowire endpoints
   independently initiates the setup of a unidirectional LSP.  An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID and PW type.


Lizhong


>
> Thanks,
>
> Yuanlong
>
>
>
> *From:* [e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, August 12, 2015 11:45 PM
> *To:* Jiangyuanlong; rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles
> Heron (giheron); agmalis; stbryant
> *Cc:* rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
> *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt
>
>
>
> 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 <[e-mail]>
>
> *Date:* 2015-08-12 19:44
>
> *To:* [e-mail]; rtg-ads <[e-mail]>; David Allan I
> <[e-mail]>; Fedyk, Donald (Don)
> <[e-mail]>; Giles Heron <[e-mail]>; Andrew
> G. Malis <[e-mail]>; Stewart Bryant (stbryant)
> <[e-mail]>
>
> *CC:* rtg-dir <[e-mail]>; pals <[e-mail]>;
> draft-ietf-l2vpn-vpls-pe-etree
> <[e-mail]>
>
> *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:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *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 <[e-mail]>
>
> *Date:* 2015-06-11 05:48
>
> *To:* Lizhong Jin <[e-mail]>; rtg-ads <[e-mail]>
>
> *CC:* rtg-dir <[e-mail]>; pals <[e-mail]>;
> [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] <[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.
>
> [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
>
>