RE: WG Last Call for draft-ietf-l2vpn-evpn-req

[Jiangyuanlong <[e-mail]>]

Hi authors of draft-ietf-l2vpn-evpn-req-01 and all,

I had a review of this document, and believe that some issues still need to be resolved.

Some technical comments:
1. In Section 4.1, it says:
   "....This being the case, the first requirement for
   active/active multi-homing is the ability to accommodate flexible
   flow-based load-balancing from the CE node based on L2, L3 and/or L4
   header fields.

   A solution MUST be capable of supporting flexible flow-based load
   balancing from the CE as described above."
   
I am not sure the current E-VPN framework can support CE load-balancing based on L3 and/or L4 header fields. For example, if the frames with the same MAC address are load-balanced on multiple PEs in a multi-homed group, the remote PEs need to support sub-MAC flow-based forwarding, furthermore, BGP signaling also needs substantial extensions to support it. All these will pose a great challenge to EVPN.

2. At the end of Section 4.4, it says:
"
   A multi-homed group (also known as a multi-chassis LACP group) is a
   group of PEs supporting a multi-homed CE.
"
and in Section 4.5, it says:
"  In order to simplify service provisioning and activation, the multi-
   homing mechanism SHOULD allow arbitrary grouping of PE nodes into
   redundancy groups where each redundancy group represents all multi-
   homed groups that share the same group of PEs. This is best explained
   with an example: consider three PE nodes - PE1, PE2 and PE3. 
"
It seems a formal definition of redundancy group is needed (IMO, "each redundancy group represents all multi-homed groups that share the same group of PEs" is a little confusing), and multi-homed group is also not clearly defined IMO (it seems a specific PE should be designated as DF in multi-homed group while redundancy group is just a set of PEs according to the EVPN framework).  
   
3. At the end of Section 6, it says:
"  - Implementations SHOULD revert to using default values for
   parameters as and where applicable.
"
It seems like a rule of thumb to use some default values for any implementation or protocol design, do we really need to list this as an EVPN requirement?

4. In Section 10, it says:
"
   A solution MUST be capable of supporting flexible VPN topologies that
   are not constrained by the underlying mechanisms of the solution. 
"
Not sure how can we determine the fulfillment of this mandatory requirement?

5. In Section 11, it says:
"
   For scenarios where MAC learning is performed in data-plane, there
   are no additional security aspects beyond those considered in
   [RFC4761] and [RFC4762]. And for scenarios where MAC learning is
   performed in control plane (via BGP), there are no additional
   security aspects beyond those considered in [RFC4364].
"
However, there is no description of "MAC learning" in the requirement doc, so why it is discussed in the security section? It is proposed either we remove these discussions, or refer to draft-ietf-l2vpn-evpn in the first place (where it dwells in).

Some minor comments:
1. Section 2, s/for e.g./e.g.,/
2. At the end of Section 2, all the section numbers referred to are in disorder.
3. Section 3, the Terminology section is in a mess, and re-formatting is needed.
4. Section 4.1, s/IGP ECMP paths/ECMP paths/, as E-VPN may well cross multi-AS.
5. Section 4.2, 
	s/For instance/For instance,/
6. Section 4.2, 
	s/between those LSPs/among those LSPs/
7. In Section 4.2, it says:
   "Similarly if LDP is being used as the transport LSP protocol,
   then the solution MUST be able to leverage LDP ECMP capabilities."
1) s/transport LSP protocol/signaling protocol for transport LSPs/
2) s/leverage LDP ECMP capabilities/leverage those LDP signaled equal cost LSPs/, since "LDP ECMP capabilities" are somewhat ambiguous.

8. In Section 4.2, it says:
 "The solution MUST also be able to leverage work in the MPLS WG that is in
   progress to improve the load balancing capabilities of the network
   based on entropy labels." 						
   It seems a reference to draft-ietf-mpls-entropy-label is needed.
   
9. In Section 4.3,
  s/from cost standpoint/from a cost standpoint/
  s/the pair of PEs/multiple PEs/ or s/multi-homed/dual-homed/
  
10. In Section 4.4,
s/multi-chassis LACP group/multi-chassis LAG/, since LACP is only the control protocol for the LAG.

11. Section 4.6,
s/participate in the control/participate in the resiliency/, since G.8032 is usually not regarded as a control protocol.

12. Section 5,
1) What is the advantage of MP2MP LSP? Maybe an example or a reference could be provided to justify it.
2) s/uncast/unicast/

13. Section 6,
1) s/MUST be maintained/MUST be maintained./
2) s/on the access circuit/for the access circuit/

14. Section 8,
s/the attachment circuit or PE/an attachment circuit or a PE/

15. Section 9, it says:
"   ...it is required to minimize the flooding of broadcast
   frames outside the confines of a given site. Of particular interest
   is periodic ARP traffic.
"
Why periodic ARP traffic is of particular interest? it seems to me just an example.

16. Section 10, 
s/with other roots/with roots/

17. Section 13, 
1) For [802.1Q], it seems IEEE Std 802.1Q-2011 is the latest revision.
2) Two redundant references for [VPLS-MCAST] are included in this section, it is proposed that the 1st should be removed.

Regards,
Yuanlong

------------------------------
Date: Fri, 19 Oct 2012 23:34:53 +0100
From: Giles Heron <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: WG Last Call for draft-ietf-l2vpn-evpn-req
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

This email initiates an L2VPN WG Last Call for:

http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01

please comment to the list as to the suitability of this draft for publication as a Standards Track RFC from the L2VPN WG.

this last call will close on Friday 2nd November.

Nabil & Giles