Subject: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

From: Haoweiguo <[email-masked]>
Date: Thu, 13 Nov 2014 07:09:26 +0000

Hi Co-authors,

In today's BESS meeting, i have some comments, pls allow me to reiterate here.

1. EVPN supports mass MAC withdraw when local PE link failure occurs. If EVPN is used for NVO3 network interconnecting, if a local NVE occurs node failure, local DCI PE how to notify remote PEs to flush MAC table in mass mode, because in this case, there maybe many TS's MAC attached to the local NVE, mass MAC withdraw should be supported to provide MAC withdraw efficiecy.

2. For EVPN multi-homing, DF is elected per I-ESI, can you ensure BUM traffic load balancing among multiple PEs?

3. If DC GW and WAN PE are separated device, Option-B solution should be supprted to ensure scalability, Option-A (In your draft, it is called vlan hand-off)has two much scalability limitations.

For unicast traffic, the DC GW should support VN ID and MPLS VPN Label switching. VN ID and MPLS VPN Label at WAN PE assign machanism also should be specified. For BUM traffic, the DC GW should stitch the multicast tree within data center and the multicast tree in WAN network.

The description is too simple in your draft, in our previous drafts, the option-B solution is described in detail,  your reading are welcomed.

http://datatracker.ietf.org/doc/draft-hao-l2vpn-inter-nvo3-evpn/

http://ietfreport.isoc.org/idref/draft-hao-l3vpn-inter-nvo3-vpn/

In my today's Option-C presentation, transport layer stitching mechanism is described. Option-B solution should support service layer stitching, the mechansim also should be fully described.

Thanks

weiguo

---

From: Haoweiguo <[email-masked]>
Date: Wed, 19 Nov 2014 01:11:54 +0000

Hi Joege,

Thanks for your detail explanations.

Yes, there are two Option-B solutions as follows.

1. No MAC VRF is created on DC GW, no sub interfaces associated with each VRF are created between DC GW and WAN PE. Only VN ID and MPLS VPN Label switching is performed on DC GW for unicast traffic forwarding. This solution is equivalent option-B of RFC 4364.

2. MAC VRF is created on DC GW,  MPLS VPN Label is allocated per VRF,no sub interfaces associated with each VRF are created between DC GW and WAN PE.

The above second solution is your solution. It has no problem. Several months ago, Robert and I had already proposed this solution, pls read our draft https://tools.ietf.org/html/draft-hao-l3vpn-inter-nvo3-vpn-01(section 7), and we think the above two solutions can be hybrid deployed, which means from WAN to DC direction using the second solution, from DC to WAN direction using the first solution.

Thanks

weiguo

________________________________

From: Rabadan, Jorge (Jorge) [[email-masked]]
Sent: Saturday, November 15, 2014 12:27
To: Haoweiguo; [email-masked]
Subject: Re: 答复: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Weiguo,

My apologies but I don’t get what you think I missed :-)
draft-rabadan-bess-dci-evpn-overlay describes a gateway solution that does not match an RFC4364-“equivalent" model (*)
draft-ietf-bess-evpn-overlay-00 describes an Inter-AS solution that matches an RFC4364-“equivalent” model-B.

(*) Model A means MAC-VRF to MAC-VRF connected through sub-interfaces, i.e. attachment circuits. This is only the case in section 2.2 of the decoupled model. The rest of the sub-models do not match this description. In particular, one of the models: section 3.4 EVPN-MPLS interconnect for EVPN-Overlay networks, uses EVPN at both sides:

  *   This is in no way model A, since a) MP-BGP is used at both sides, to the DC RR and to the WAN RR and b) no sub-interfaces are used to get connected to the WAN PEs.
  *   A MAC-VRF is instantiated in the GW due to the requirements explained in the document.
  *   We are not comparing the scalability of this solution vs the Inter-AS solution explained in draft-ietf-bess-evpn-overlay-00. We are just providing a needed solution given the stated requirements.
  *   It is understood that this requires MAC lookup hence storing MACs in the FIB, but has many other advantages over an inter-AS model B solution. For instance:
     *   It provides protection/isolation to the DC (control over the advertised MACs, proxy-ARP/ND, unknown-mac-route)
     *   Allows local ACs
     *   Label aggregation: in model B the GW advertises to the WAN a label per NVE per MAC-VRF and the other way around (a label per PE per MAC-VRF to the DC). In our model a single label is advertised per MAC-VRF to the WAN and the other way around. So from the label perspective, it helps scaling the DC and the WAN network more than model B.
     *   Also provides WAN and DC independency in terms of inclusive multicast trees, MAC mobility and other procedures.

Some slides about it:
http://www.ietf.org/proceedings/89/slides/slides-89-l2vpn-2.pdf

Thanks.
Jorge

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 14, 2014 at 3:14 PM
To: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Joege,

Sorry, may be you missed it. Your discription is Option-A solution between NVO3 GW and EVPN PE, not Option-B solution. In option-B case, no MAC VRFs are required on GW, only VN ID and MPLS VPN Label switching is needed, it has bettter scalability than option-A.

Thanks

weiguo

________________________________
发件人: BESS [[email-masked]<mailto:[email-masked]>] 代表 Rabadan, Jorge (Jorge) [[email-masked]<mailto:[email-masked]>]
发送时间: 2014年11月15日 1:23
收件人: Haoweiguo; [email-masked]<mailto:[email-masked]>
主题: Re: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Weiguo,

In-line [JORGE2].
Thanks.

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 14, 2014 at 1:08 AM
To: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Jorge,

Please see inline with [weiguo2].

Thanks

weiguo

________________________________
发件人: Rabadan, Jorge (Jorge) [[email-masked]<mailto:[email-masked]>]
发送时间: 2014年11月13日 16:42
收件人: Haoweiguo; [email-masked]<mailto:[email-masked]>
主题: Re: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Weiguo,

Please see in-line.

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 12, 2014 at 11:09 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Co-authors,

[JORGE] If you are talking about the EVPN-MPLS interconnect model, if there is a failure in one of the ESIs at an NVE, the NVE will withdraw the A-D per ESI route and the DC GWs will do mass withdraw. That is perfectly supported. The NVE ESI A-D route updates/withdraw don’t have to be exported to the WAN PEs.

[weiguo2]: Sorry, it's my mistake, too many similar drafts. In the draft no this issue. in your draft data center network is NVO3+EVPN, control plane mac learning is used. There is another draft, NVO3 uses data plane MAC learning, no EVPN protocol is running within data center network, in this case NVE occurs link or node failure, no MASS mac withdraw mechanism.

[JORGE] See the procedures in section 3.4.3.
[weiguo2]: Yes, It can realize per EVI loadbalancing.

[JORGE] The decoupled model assumes separate admin entities in WAN and DC, hence you need a clear demarcation hand off for security and QoS, etc. Of course the decouple vs integrated model described in the draft have pros and cons, but both are required. Option B is described in http://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03

[JORGE] If you refer to section 3.4, all the procedures which are *different from EVPN* are described in the draft in my opinion. I don’t think EVPN procedures have to be explained here, but let us know if there is something specific that can be subject to different interpretations.

[weiguo2]: Option-B solution only applies for decouple model. I think the solution in your referrence is not clear, if you have spare time, pls read the above two drafts. VN ID and MPLS VPN Label assigning principle, how to stitch service layer including unicast and multicast are all described in detail. Thanks.

[JORGE2] To be clear, this draft does not talk about option B. That is explained in the evpn-overlay draft. This draft defines a gateway function, where a MAC-VRF is instantiated in the GW, i.e. a MAC lookup is required. As such, stitching and translations VNI to VNI or VNI to MPLS label are all fully supported. The VNIs or MPLS labels are locally allocated and there are no dependencies because we always do a MAC lookup. Can you please let us know what exactly is not clear?
Another comment: the decouple vs integrated thing is terminology of this draft and it is not used anywhere else, and IMO it does not make sense when talking about option B.

[JORGE] As discussed, personally I think I understand your solution but at the moment I haven’t seen any use-case for such complex architecture. I have only seen use cases for model B or for the GW model described in the dci-evpn-overlay draft.
[weiguo2]: Currently NVO3 networks have not been widely deployed, so you haven't seen any usecases for option-C. But maybe in the future, it will be used, because it is a equivalent solution of vanilla option-C in RFC4364.

Thanks

weiguo

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 19 Nov 2014 15:33:18 +0000

Weiguo,

We can’t refer to model B in draft-rabadan-bess-dci-evpn-overlay because it is not a model B. I would say it is a gateway model for EVPN.
Besides, this draft extends some procedures in EVPN so it is classified as “standards track”.
Your draft talks about an IP-VPN inter-as option B. I have no comments about it. It does not “compete" to the dci-evpn-overlay draft.
Thanks.
Jorge

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 18, 2014 at 5:11 PM
To: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RE: [bess] RE: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Joege,

Thanks

weiguo

From: Rabadan, Jorge (Jorge) [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, November 15, 2014 12:27
To: Haoweiguo; [email-masked]<mailto:[email-masked]>
Subject: Re: 答复: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00

Hi Weiguo,

Some slides about it:

Thanks.
Jorge

Hi Joege,

Thanks

weiguo

Weiguo,

In-line [JORGE2].
Thanks.

Hi Jorge,

Thanks

weiguo

Hi Weiguo,

Please see in-line.

Hi Co-authors,

Thanks

weiguo