Hi Sunny, Yes, you make the point. If two NVEs support different data plane encapsulation only, there is no way they can communicate each other. Period.
Because of that, should we require all the NVEs supporting all the encapsulation types or each DC may ask certain type of encapsulation from vendors. For the DC migration or transition, we can use a gateway to handle it under one control plane. I don't think requiring all NVE to support all the encapsulation types is right approach for this. What if we find a better data plane encapsulation in the future? We don't want to make a dead end here. Lucy From: Sunny Rajagopalan [mailto:[email protected]] Sent: Wednesday, September 26, 2012 3:53 PM To: Lucy yong Cc: Aldrin Isaac; [email protected] Subject: support for multiple encoding types at the NVE (was RE: [nvo3] comments on draft-drake-nvo3-evpn-control-plane) Right. Nobody likes gateways. So let's say that the preferred NVE encoding type on a hypervisor vswitch is vxlan. Let's say you learn (using the tunnel-encap attribute) that your peer only supports MPLS. What good does it do you? Your data center only supports VXLAN - even if your vswitch figured out how to make an mpls packet, your underlay wouldn't know what to do with it. If the NVE and the underlay infrastructure supported all possible types of encodings, the underlay provider would just choose one everywhere. What typically happens is that you have one data center which is hyper-v based and another which is esx based. Each places restrictions on the type of encap that hypervisor switches can produce. To interconnect the two, there's no point in telling the NVEs what their peer supports, because they can only produce the kind of packet that's kosher with their virtualization provider. The solution is a gateway. What are the scenarios where the tunnel attribute would be useful? -- Sunny From: Lucy yong <[email protected]> To: Aldrin Isaac <[email protected]>, Sunny Rajagopalan/Santa Clara/IBM@IBMUS, Cc: "[email protected]" <[email protected]> Date: 09/26/2012 12:44 PM Subject: RE: [nvo3] comments on draft-drake-nvo3-evpn-control-plane ________________________________ Hi Aldrin, > 4) I would also suggest not having the NVE keep track of the encapsulation > used by the remote endpoint. (this means that the tunnel encapsulation > attribute in the draft would be unnecessary). Instead, the onus of > translating between encapsulation methods should be on gateways. If you > define the XMPP format well, you should be able to communicate end point > information in a way that is agnostic of the encap method used by the NVE, > allowing it to do the one encap it does best. A gateway can do this > translation without BGP control plane intervention, because it would be > configured to have interfaces that are (for eg) NVGRE on one arm and VXLAN > on the other, and it would be obvious as to what encap to put on a packet > going from one arm to the other. Applying an MPLS label would involve the > gateway participating in BGP. Gateways = choke points. They should be avoided. Every time I buy the next guys NVO3 system (because it's faster, more scalable, etc) I'll have to figure out where/how to gateway between it and my other ten NVO3 systems. :-/ I prefer Inter-AS option-C where I can have it. [[LY]] option C requires building a tunnel between two PEs and also another tunnel between sending PE and ASBR on top, so the packet can be transported in IGP. This does not apply here. RFC4364 does not address supporting multiple data plane encapsulations. Lucy _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
