Hi Stewart,

Thank a lot  for your exhaustive review, please see my comments in line.
I also uploaded a new version to reflect all those changes:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-05

Best regards,
Yuanlong


From: Pals [mailto:[email protected]] On Behalf Of Stewart Bryant
Sent: Monday, February 23, 2015 11:47 PM
To: [email protected]; [email protected]
Cc: [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree


I have picked up the task of shepherding this draft, and

have a number of comments which I think that you should

address before we send this text to the IESG.



As the text contains both LDP and BGP control information

I am copying the BESS WG and their chairs.



- Stewart



========



SB> The document fails I-D nits with



     Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--).





Please fix this.



======



SB> Number of authors. The guideline is five but it is not

a hard limit provided that all authors made significant contribution.

If asked by the IESG can all authors point to specific

text that they wrote?







    Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)

                   draft-ietf-l2vpn-vpls-pe-etree-04.tx







=====



 Abstract



   A generic Virtual Private LAN Service (VPLS) solution is proposed for

   Ethernet-Tree (E-Tree) services which uses VLANs to indicate root or

   leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an

   example for the solution. In the solution, E-Tree VPLS PEs are

   interconnected by PWs which carry the VLAN indicating the E-Tree

   attribute, the MAC address based Ethernet forwarding engine and the

   PW work in the same way as before. A signaling mechanism for E-Tree

   capability and VLAN mapping negotiation is further described.



======



 2. Terminology



   E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in

   MEF 6.1



   EVC: Ethernet Virtual Connection, as defined in MEF 4.0



   FIB: Forwarding Information Base, or forwarding table



   T-VSI: Tree VSI, a VSI with E-Tree support



   Root AC, an AC attached with a root



   Leaf AC, an AC attached with a leaf



   C-VLAN, Customer VLAN



   S-VLAN, Service VLAN



   B-VLAN, Backbone VLAN



   Root VLAN, a VLAN ID used to indicate all the frames that are

   originated at a root AC



   Leaf VLAN, a VLAN ID used to indicate all the frames that are

   originated at a leaf AC



   I-SID, Backbone Service Instance Identifier, as defined in IEEE

   802.1ah





=======





3. Introduction



   Further, an E-Tree service may

   include multiple roots and multiple leaves. Although VPMS or P2MP



SB> VPMS, P2MP and in a few line VPLS, VSI and PE need expansion (and ideally a 
reference)
[Yuanlong] done.

========



   IEEE 802.1 has incorporated the generic E-Tree solution in the latest

   version of 802.1Q [802.1Q-2011], which is just an improvement on the

   traditional asymmetric VLAN mechanism (the use of different VLANs to

   indicate E-Tree root/leaf attributes and prohibiting leaf-to-leaf

   traffic with the help of VLANs was first standardized in IEEE 802.1Q-

   2003). In the solution, VLANs are used to indicate root/leaf



SB> In THE solution - which solution is THE solution?


[Yuanlong] The new IEEE 802.1Q solution.

=======



   This document introduces how the Ethernet VLAN solution can be used



SB> s/introduces/specifies/ and later s/proposed/specified/



   to support generic E-Tree services in VPLS. The solution proposed


[Yuanlong] done.

=======



 here is fully compatible with the IEEE bridge architecture and the



SB> s/the/with/


 [Yuanlong] done.


IETF PWE3 technology, thus it will not change the FIB (such as



SB> please expand FIB
[Yuanlong] done.



=======







4. PE Model with E-Tree Support



   Problem scenario of E-Tree as shown in Fig. 1 of [Etree-req] is a

SB> The problem
[Yuanlong] done.



=======



4.1. Existing PE Models





SB> In the text that follows it is clear how Fig 1 fits into the picture

but not Fig 2 (which as far as I can see you do not even reference).

I think you are saying that Fig 2 is the existing VPLS model, then

Fig 3 is the obvious mapping to E-tree, but there are problems, but this

needs to be much clearer.
[Yuanlong] both Figs are called out in the new texts now.



========



4.2. A New PE Model with E-Tree Support



   In order to support the E-Tree in a more scalable way, a new VPLS PE

   model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is

   proposed.



SB> s/proposed/specified/
[Yuanlong] done.



=======







   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. Alternatively, the PBB VPLS PE model (where



SB> PBB needs expansion
[Yuanlong] done.



=======



   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 will use VLAN to refer to this outermost VLAN for simplicity



SB> S/will use/uses/
[Yuanlong] done.





5. PW for E-Tree Support



5.1. PW Encapsulation



   To support an E-Tree service, T-VSIs in a VPLS must be interconnected

   with a bidirectional Ethernet PW. The Ethernet PW may work in the

   tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN

   tag must be carried in each frame in the PW to indicate the frame



SB>s/and a VLAN tag must be carried in each frame/

in which case a VLAN tag MUST be carried in each frame/
 [Yuanlong] done.





   originated from either root or leaf (the VLAN tag indicating the

   frame originated from either root or leaf can be translated by a

   bridge module in the PE or added by an outside Ethernet edge device,

   even by a customer device). In the tagged PW mode, two service

   delimiting VLANs must be allocated in the VPLS domain for an E-Tree.



s/must/MUST/
[Yuanlong] done.



=======





   Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree

   service for a PW in Compatible mode as shown in Section 5.3.2.



SB> I think this needs to be :

Raw PW (PW type 0x0005 in [RFC4448]) MAY also be used
[Yuanlong] done.



========











6. Signaling for E-Tree Support



6.1. LDP Extensions for E-Tree Support



   In addition to the signaling procedures as specified in [RFC4447],

   this document proposes a new interface parameter sub-TLV to provision

   an E-Tree service and negotiate the VLAN mapping function, as follows:



     0                   1                   2                   3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |  E-Tree       |   Length=8    |           Reserved        |P|V|

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |          Root VLAN ID         |          Leaf VLAN ID         |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 8  E-Tree Sub-TLV



   Where:



   o E-Tree is the sub-TLV identifier to be assigned by IANA.



SB> You have an assigned value. I think it would be clearer to all

to say that and include the value in this text
[Yuanlong] done.



========







   A PE that receives a PW label mapping message with an E-Tree Sub-TLV

   from its peer PE, after saving the VLAN information for the PW, must



SB> must or MUST? The latter I think.
[Yuanlong] done.



=========





SB> Does what follows need to be proceeded by Else or Otherwise?
[Yuanlong] Yes, the following should be processed in all cases.



 PW processing as described in [RFC4448] proceeds as usual for all

   cases.



6.2. BGP Extensions for E-Tree Support







   A PE which does not recognize this attribute shall ignore it silently.



SB> I think that should be SHALL or MUST.
[Yuanlong] Done.



======



7. OAM Considerations



   Ethernet OAM for E-Tree including both service OAM and segment OAM

   frames shall undergo the same VLAN mapping as the data traffic; and

   root VLAN SHOULD be applied to segment OAM frames so that they are

   not filtered.



SB> I think s/shall/SHALL/
[Yuanlong] Done.



=======



 8. Applicability



   The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS

SB> s/The/This/ or s/The solution specified in this document/
[Yuanlong] Done.





======

 10.  IANA Considerations



   IANA is requested to allocate a value for E-Tree in the registry of

   Pseudowire Interface Parameters Sub-TLV type.



   Parameter ID   Length       Description

   =======================================

   TBD            8            E-Tree





SB> Update to show you have the assignment
[Yuanlong] done.





=======





   IANA is requested to allocate two new LDP status codes from the

   registry of name "STATUS CODE NAME SPACE". The following values are

   suggested:





   Range/Value     E     Description

   ------------- -----   ----------------------

   TBD             1     E-Tree VLAN mapping not supported

   TBD             0     Leaf to Leaf PW released



SB> Update to show you have the assignment
[Yuanlong] done.



======

 IANA is requested to allocate a value for E-Tree in the registry of

   BGP Extended Community.



   Type Value          Name

   =======================================

   TBD                 E-Tree Info

SB> Update to show you have the assignment
[Yuanlong] done.



=======



Appendix A. Other PE Models for E-Tree



A.1. A PE Model With a VSI and No bridge





   This PE model may be used by an MTU-s in an H-VPLS network, or an N-

   PE in an H-VPLS network with non-bridging edge devices, wherein a

   spoke PW can be treated as an AC in this model.



SB> Please check that all of the above abbreviations have been

previously expanded.
[Yuanlong] done.



=======


_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to