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
