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. 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. 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. 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. Thanks weiguo
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
