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 protected]] Sent: Saturday, November 15, 2014 12:27 To: Haoweiguo; [email protected] 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 protected]<mailto:[email protected]>> Date: Friday, November 14, 2014 at 3:14 PM To: Jorge Rabadan <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>] 代表 Rabadan, Jorge (Jorge) [[email protected]<mailto:[email protected]>] 发送时间: 2014年11月15日 1:23 收件人: Haoweiguo; [email protected]<mailto:[email protected]> 主题: Re: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00 Weiguo, In-line [JORGE2]. Thanks. From: Haoweiguo <[email protected]<mailto:[email protected]>> Date: Friday, November 14, 2014 at 1:08 AM To: Jorge Rabadan <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>] 发送时间: 2014年11月13日 16:42 收件人: Haoweiguo; [email protected]<mailto:[email protected]> 主题: Re: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00 Hi Weiguo, Please see in-line. From: Haoweiguo <[email protected]<mailto:[email protected]>> Date: Wednesday, November 12, 2014 at 11:09 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00 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. [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. 2. For EVPN multi-homing, DF is elected per I-ESI, can you ensure BUM traffic load balancing among multiple PEs? [JORGE] See the procedures in section 3.4.3. [weiguo2]: Yes, It can realize per EVI loadbalancing. 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. [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 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/ [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. 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. [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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
