-----Original Message----- From: Dino Farinacci [mailto:farina...@gmail.com] Sent: Thursday, September 26, 2013 3:35 PM To: Lucy yong Cc: Roger Jørgensen; Fabio Maino; n...@ietf.org; Noel Chiappa; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt
> Dino, > > Current VXLAN format is much simpler format compared to LISP format. To use > it with LISP protocol, do you need to modify VXLAN format to support LISP > features? Lucy, the format is exactly the same. If you choose to not implement the LISP data plane features and disable the flags, then it is exactly the same implementation as LISP. However ... VXLAN is actually harder because if you get a cache miss, you have to look in another table to find a group address to encapsulate to. So if you take a closer look under the cover, it is arguably harder. It requires a hardware implementation to build a different lookup memory or partition one memory to do two different types of lookups. [Lucy] I get it. Thank you for the explanation. It tells me that it is better not going that way. Lucy Dino > > Regards, > Lucy > > -----Original Message----- > From: Lucy yong > Sent: Thursday, September 26, 2013 2:44 PM > To: 'Dino Farinacci'; Roger Jørgensen > Cc: Fabio Maino; n...@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: RE: [nvo3] [lisp] New Version Notification for > draft-quinn-vxlan-gpe-00.txt > > Please see inline. > > -----Original Message----- > From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf > Of Dino Farinacci > Sent: Thursday, September 26, 2013 1:57 PM > To: Roger Jørgensen > Cc: Fabio Maino; n...@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: Re: [nvo3] [lisp] New Version Notification for > draft-quinn-vxlan-gpe-00.txt > >> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci <farina...@gmail.com> wrote: >>>> Hi Noel, >>>> there's certainly no intention of keeping this out of the LISP WG, since >>>> this is not part of the charter we just thought an individual submission >>>> was more appropriate. >>>> >>>> We just started from the very practical consideration of the proliferation >>>> of encapsulations in the data center, and the lack of multiprotocol >>>> support in both VXLAN and LISP. >>> >>> Sorry I have to disagree. The protocols that LISP supports are *IP* >>> protocols and the protocols that VXLAN supports are *the rest* since it is >>> layer-2 solution. So this appears to be just rearranging the deck chairs. >> >> This trouble me... why do we want to mix LISP and VXLAN? What is the >> gain in it? I only smell complexity. L2 in L3 over L3? > > We shouldn't but let the authors reply. If you want to carry more than IP > protocols in LISP, then you use the L2 UDP port and carry MAC addresses in > LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane, > the LISP mapping database using LISP-DDT. > > [Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP > protocol. However, Overlay virtual networks that use VXLAN encapsulation may > be implemented in other way too, e.g. SDN controller, not LISP protocol. > Therefore, there is a desire to extend VXLAN encapsulation to support > multiple protocols beside L2 only and make it a generic overlay encapsulation > schematics to support an overlay application. > > BTW: IMO: using UDP port to indicate payload type is not elegant design, but > acceptable for history reason only. > > Lucy > >> How will a mix of LISP and VXLAN benefit the administrators of >> datacenters, end-users in the end? > > The VXLAN authors have to answer that. They came afterwards (by 5 years). > > Dino > >> >> >> >> -- >> >> Roger Jorgensen | ROJO9-RIPE >> rog...@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | ro...@jorgensen.no >> >> (I really start to really dislike gmails new better editor) > > _______________________________________________ > nvo3 mailing list > n...@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
