Weiguo, In-line [JORGE2]. Thanks.
From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>> Date: Friday, November 14, 2014 at 1:08 AM To: Jorge Rabadan <jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00 Hi Jorge, Please see inline with [weiguo2]. Thanks weiguo ________________________________ 发件人: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] 发送时间: 2014年11月13日 16:42 收件人: Haoweiguo; bess@ietf.org<mailto:bess@ietf.org> 主题: Re: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00 Hi Weiguo, Please see in-line. From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>> Date: Wednesday, November 12, 2014 at 11:09 PM To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
