Subject: editing suggestion on draft-ietf-l2vpn-evpn-02

From: Lucy yong <[email-masked]>
Date: Tue, 20 Nov 2012 20:57:19 +0000

Hi Ali,

In the L2VPN WG meeting, I pointed out that current draft states multicast related process in several chapters and suggested to consolidate them. Here is my suggestion how to consolidate them.

Make charter 12, 13 and 17 into one chapter titled as broad, multi, and unknown cast processing and place this chapter at current charter 17 position. Make the 12,13, and 17 content as three sub-sections in the new chapter. IMO: 13.2 is not necessary. It just needs to state that the procedures for using P-tunnel is the same as the procedure in 12.2. The large paragraph in section 14.1 for unknown flood processing is redundant too, just need to a  reference. Charter 17 also have some redundant text that mentioned in 12 or 13 such as ingress replication and p2mp LSPs, etc.

Under the suggested organization, the draft structure will be more clear, chapter 8 is about BGP extension, chapter 9 is about multi-homing functions. Chapter 10~14 is about unicast traffic process and charter. The chapter 15 (new charter) is about multicasting process.

Here are some additional comments and suggestions on the draft.

*         Chapter 7, Ethernet Tag.
Comment: it is very important for us to distinct the multiple broadcast domains and separated MAC spaces in the network virtualization. The document should state that "an Ethernet Tag identifies a particular broadcast domain in an EVI, e.g. a VLAN, in an EVI. An EVI corresponds to one customer MAC space and consists of one or more broadcast domains and."

*         Text in Ch 7:
   Further, some deployment scenarios guarantee uniqueness of broadcast
   domain identifiers across all EVIs;  all points of attachment of a
   given EVI use the same broadcast domain identifier(s) and no other
   EVI uses these broadcast domain identifier(s).

       Comments: I think that it means that uniqueness of broadcast domain identifier across  all PEs for a given EVI. Since one PE may be
       configured with multiple EVI for different customer. Current statement makes a bit of confusion.

*         Text in 7.3,
        Furthermore, there are multiple bridge domains per PE for the EVI: one broadcast domain per CE broadcast domain
       identifier.

      The sentence is not clear. Do you mean multiple broadcast domains per PE for the EVI?  If yes, it is better to state as multiple multicast domains per PE for the EVI. In fact, the text in 8.3 and 17 describes the related procedures in supporting multiple multicast domains.

*         Text in 17.3,
       The procedures are the same as those in [VPLS-MCAST] with S- PMSI A-D routes in [VPLS-MCAST] replaced by E-VPN Selective A-D
   routes.

       Should it be:  The procedures are the same as those in [VPLS-MCAST] with S- PMSI A-D routes in [VPLS-MCAST] and replaced by E-VPN Selective A-D  routes.

*         Text in 17.3,
   A E-VPN Selective A-D route includes an optional
   Ethernet Tag field. Also an E-VPN selective A-D route may encode a
   MAC address in the Group field. The encoding details of the E-VPN
   selective A-D route will be described in the next revision.

   I don't think this can be down such each. How to match the selective tree and Ethernet tag based multicast domain? Can they have different topologies?

*         Text in ch 12 : received from a CE encapsulated in a given Ethernet Tag in an EVI, ...
should be: received from a CE and encapsulated with a given Ethernet Tag at PE for an EVI,...

*         The document use P2MP LSP and P-tunnel in these chapters and describe for  the same purpose. Suggest to make them consistent.

*         Change "imposition PE"  to "ingress PE" and "disposition PE" to "egress PE". We don't need to define new components to describe the procedure.

*         Replace "a E-VPN" to "an E-VPN"

Hope these help make the document more clear, concise, and less duplications.

Regards,
Lucy