Xiaohu, Assume a Virtual LAN is formed by the interconnection of an L2 VN in an overlay domain with other LAN technology (dot1q, TRILL, PBB, etc) and/or other L2 VN in other overlay domain. In such a case would you mandate that the interconnection points must be active/standby? What then if the VN "bridges" with the VN in the other Overlay domain via multiple sites/DC? Would you pick one site to be the active interconnection point in order to avoid data plane loops? What then of optimizing ingress/egress? What of pooling?
Best regards. -- aldrin On Saturday, September 22, 2012, Xuxiaohu wrote: > Yes, if the active-active multi-homing on a per L2VPN instance basis was > desired in some cases, vendors could offer their proprietary schemes like > Cisco’s VSS to support that capability. In this way, there is no need to > introduce the complexity into the standard, especially on the data plane > perspective, and therefore other NVEs (i.e., PE routers) which are not > within any active-active redundancy group don’t need to afford that > complexity anymore. **** > > ** ** > > As for active-passive multi-homing, I fully agree with you that the > active/passive multi-homing on a per physical interface or trunk interface > basis is not welcomed. Hence we could achieve load-balancing among the > physical interfaces or trunk interfaces which are connected to different > NVEs of the same RG (redundancy group) on the basis of VLANs. For example, > a dual-homed device (DHD) is multi-homed to NVE1 and NVE2 and it is > configured with two VLANs (say VLAN x and y) on its physical NICs in a > bond, NVE1’s corresponding interface is active for VLAN x while NVE2’s > corresponding interface is active for VLAN y…**** > > ** ** > > Best regards,**** > > Xiaohu**** > > -**** > > *发件人:* Jon Hudson [mailto:[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>] > *发送时间:* 2012年9月22日 17:16 > *收件人:* Xuxiaohu > *抄送:* Aldrin Isaac; Lucy yong; Kireeti Kompella; > [email protected]<javascript:_e({}, 'cvml', '[email protected]');> > *主题:* Re: [nvo3] Is the cost of supporting active-active multi-homing on > a per L2VPN instance basis sustainable?**** > > ** ** > > ** ** > > If we don't do it as part of the standard, vendors will just implement > proprietary versions.**** > > ** ** > > active/passive anything is not welcomed in the datacenter anymore **** > > ** ** > > ** ** > > On Sat, Sep 22, 2012 at 2:02 AM, Xuxiaohu <[email protected]> wrote:**** > > Hi all, > > I strongly believe this is an very important question which needs more > attentions and discussions. Hence I redefine the subject of the original > email so as to avoid this email from being missed. > > Best regards, > Xiaohu > > > -----邮件原件----- > > 发件人: [email protected] [mailto:[email protected]] 代表 > > Xuxiaohu > > 发送时间: 2012年9月21日 10:00 > > 收件人: Aldrin Isaac; Lucy yong > > 抄送: Kireeti Kompella; [email protected] > > 主题: [nvo3] 答复: draft-drake-nvo3-evpn-control-plane > > > > > > > > > -----邮件原件----- > > > 发件人: [email protected] [mailto:[email protected]] 代表 > > Aldrin > > > Isaac > > > 发送时间: 2012年9月19日 5:24 > > > 收件人: Lucy yong > > > 抄送: Kireeti Kompella; [email protected] > > > 主题: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > The imported E-VPN route will determine what the next hop entry in the > > > EVI will look like -- whether it will have encapsulation A or > > > encapsulation B. That is determined by the sender of the E-VPN route. > > > This is like having a PPP interface and an Ethernet interface > > > connected to the same VRF. > > > > > > Ideally the other encapsulations would have included support for > > > multi-homing by including an additional field for a split-horizon ID > > > for use by control-planes and NVE that support multi-homing. Maybe > > > it's not too late to add an SH field to these encapsulations since it > > > seems that there is some unused bits in nvGRE (maybe not enough) and > > > in VXLAN -- just a thought. > > > > If the SH field is just intended for supporting active-active > multi-homing on a per > > VPN instance basis, I suggest it'd better for us to seriously evaluate > whether > > the cost for realizing that goal is worthwhile since that will make the > solution > > itself, especially the data plane process, much more complex. In the > > multi-tenant cloud data center environment, isn't it good enough in > practice to > > support active-standby multi-homing on a per VPN instance basis while > > supporting active-active multi-homing on a per physical interface basis? > For > > instance, a physical server containing two VMs (say VM1 and VM2) which > > belong to different VPN instances respectively is dual-homed to two NVEs > (say > > NVE1 and NVE2), NVE1 is the active NVE for VM1 and the standby NVE for > VM2 > > while NVE2 is the active NVE for VM2 and the standby NVE for VM1. > > > > Best regards, > > Xiaohu > > > > > On Tue, Sep 18, 2012 at 4:18 PM, Lucy yong <[email protected]> > wrote: > > > > Hi Kreeti, > > > > > > > > Regarding interworking >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
