The WG is NV over L3. When we refer to MPLS, we're talking about using MPLS context ID labels, not MPLS LSP. If you look at all these encaps, they have two things in common (1) IP transport tunnel and (2) destination context ID. I don't see how it can be unreasonably difficult for an NVE to support more than one encap which have similar constructs. However E-VPN additionally has split-horizon label for multi-homing which draft-drake-nvo3 describes a possible alternative.
On Wed, Sep 26, 2012 at 4:52 PM, Sunny Rajagopalan <[email protected]> wrote: > 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
