Alia, Just trying to understand — is there a particular reason why you pick on extensibility? What set of extension requirements do you have in mind?
The historical evolution of data path encaps seems to indicate a decreasing (not increasing) number of extensions and capability to support them (e.g., L2TPv2 -> L2TPv3, Original GRE -> Current GRE). Thanks, — Carlos. On Jul 23, 2016, at 10:14 AM, Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>> wrote: David, Thank you. This is helpful information. Can you comment at all on extensibility & support for VXLAN-GPE & the other options? Regards, Alia On Jul 22, 2016 3:41 PM, "David Melman" <davi...@marvell.com<mailto:davi...@marvell.com>> wrote: > Though if someone knows of a vendor who plans to support vxlan-gpe on their > already installed vxlan supporting hardware please speak up. I certainly did > not check with every vendor. As a silicon vendor, Marvell have the same silicon that supports both VXLAN and VXLAN-GPE. Our customers can indeed support both on the same hardware. David From: nvo3 [mailto:nvo3-boun...@ietf.org<mailto:nvo3-boun...@ietf.org>] On Behalf Of Jon Hudson Sent: Friday, July 22, 2016 11:58 AM To: Dino Farinacci Cc: Matthew Bocci; Tom Herbert; nvo3@ietf.org<mailto:nvo3@ietf.org> Subject: Re: [nvo3] Consensus call on encap proposals On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>> wrote: > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host > receives a VXLAN packet for some protocol other than Ethern the payload will > be misinterpreted. A separate port number was required. I assume that a user > using VXLAN in HW must upgrade HW to use VXLAN-GPE Tom, one clarification. Did you really mean VXLAN-GPE is not compatible with VXLAN-GPE or did you mean VXLAN? This is how a VXLAN-GPE encapsulator (an upgraded system) can talk to a VXLAN decapsulator (an existing system) with the LISP control-plane: (1) The encapsulator does a lookup on a MAC address to the mapping system. (2) What gets retunred is the decapsultor’s IP address and an encapsulation format. In this case the encapsulation format is VXLAN. (3) The VXLAN-GPE supuported encapsulator then encapsulates packets with UDP port 4789. I am told you can do this with BGP as well by negotiating what encapsulations are supported. However, most product managers are not nearly as clever as you are Dino, and as far as I know Users who today have HW that supports vxlan will have to buy new switches or line cards to support vxlan-gpe. Though if someone knows of a vendor who plans to support vxlan-gpe on their already installed vxlan supporting hardware please speak up. I certainly did not check with every vendor. Jon Dino _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3 -- "Do not lie. And do not do what you hate." _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
