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

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Yaunlong,

Thanks for your comments. Please refer to my reply in line ...

On 10/26/12 7:18 PM, "Jiangyuanlong" <[e-mail]> wrote:

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

This is a data-plane function and has nothing to do with the control-plane
BGP. Currently majority of LACP implementation do perform load balancing
among member links using L3 and/or L4 headers besides MAC addresses. On
the remote PE, when multiple adjacencies exist for the same MAC route, the
PE can hash based on L2/L3/L4 header to pick one of those adjacencies.
This also has nothing to do with the BGP control plane.

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

I think the text is very clear regarding multi-homed group and redundancy
group and both of them are defined in the text. Section 4.4 defines
multi-homed group by saying: "A multi-homed group (also known as a
multi-chassis LACP group) is a group of PEs supporting a multi-homed CE"
and section 4.5 defines redundancy group by saying: "each redundancy group
represents all multi-
   homed groups that share the same group of Pes".

If you think the definitions can be made better, please provide the text.

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

Yes.

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

Hopefully after the discussion that we had on evpn-etree, it is now clear
on how to fulfill this 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).

This requirement doc is supposed to cover both E-VPN and PBB-EVPN.
PBB-EVPN performs the MAC learning in data-plane.

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

Agreed to all.

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

G.8032 is considered as 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/

Agreed to all.

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

Changed to the attachment circuit or the 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.

Because that can constitutes the majority of the flood traffic.

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

Other roots is o.k.

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

Done.

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