A minor correction, LISP does have a unified encapsulation where the packet demux function, that has been defined for a few years, is done with UDP ports. As for VXLAN, the packet demux, has been recently introduced, is done with the P-bit.
Dino > On Jul 29, 2014, at 8:15 PM, Haoweiguo <[email protected]> wrote: > > Hi Dino, > VXLAN can use a unified encapsulation to realize both intra-subnet layer 2 > traffic forwarding and inter-subnet layer 3 traffic forwarding at the same > time, inner destination MAC is used to differenciate layer 2 traffic from > layer 3 traffic. > LISP uses two different encapsulations for intra-subnet layer 2 traffic > forwarding and inter-subnet layer 3 traffic forwarding, UDP port is used to > differenciate layer 2 traffic from layer 3 traffic. > From theoretical perspective, both the two solutions are applicable. From > commercial use perspective, the former(unified encap for both layer 2 and > layer 3) seems to be more popular currently. > Thanks > weiguo > ________________________________________ > 发件人: Dino Farinacci [[email protected]] > 发送时间: 2014年7月29日 20:18 > 收件人: Haoweiguo > 抄送: David Melman; [email protected]; LISP mailing list list; Tom Herbert > 主题: Re: 答复: [nvo3] Comments on > http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 > > I understand what you are saying but it comes down to what the encapsulator > is encapsulating. If the packet it is encapsulating is an L2 frame then the > encapsulator is supporting a layer-2 overlay service. Otherwise it is a a > layer-3 overlay service. > > If the dest MAC Is to the encapsulator that MAC header is stripped before a > layer-3 forwarding decision is made. Then, at which time the packet is > forwarded natively or encapsulated. > > If the dest MAC is not the encapsulator's address, then the MAC header stays > with the packet/frame and then encapsulated. > > The former is a layer-3 overlay and the latter is a layer-2 overlay where > both can be supported at the same time in one encapsulator device. > > The former is LISP encapsulation and the latter is VXLAN encapsulation. > > With VXLAN-GPE both cases can be supported (and most importantly with a > single unified control-plane). > > So I believe VXLAN-GPE could be useful yet redundant but LISP requires no > changes (if LISP supports L2 which is documented in draft-smith-lisp-layer-2 > using a different port number). > > Dino > >> On Jul 29, 2014, at 3:58 AM, Haoweiguo <[email protected]> wrote: >> >> Hi Dino, >> Thanks for your detail comments. As for current VXLAN encapsulation, pls >> see my comments inline with [weiguo] below. >> >> There is motivation to extend an encapsulation header (which is called >> VXLAN-GPE) so it can support, most importantly NSH. That change also gives >> VXLAN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate >> functionality of LISP. But the headers are so similar, it really doens't >> matter. >> >> [weiguo]: Yes, an new encapsulation header should be extended to support >> NSH. But as for IPv4 and IPv6, i think current VXLAN already supported. For >> the layer 3 inter-subnet traffic from NVE1 to NVE2, inner destination MAC is >> the gateway interface MAC at NVE2. For the layer 2 intra-subnet traffic >> from NVE1 to NVE2, inner destination MAC is the destination TS's MAC. When >> NVE2 receives VXLAN encapsulated traffic from NVE1, inner destination MAC >> can be used to differentiate layer 2 traffic from layer 3 traffic. VXLAN >> distributed layer 3 gateway can be realized through the mechanism, NVE can >> forward both intra-subnet layer 2 traffic and inter-subnet layer 3 traffic >> at the same time. >> >> Thanks >> weiguo >> ________________________________________ >> 发件人: Dino Farinacci [[email protected]] >> 发送时间: 2014年7月28日 22:17 >> 收件人: Haoweiguo >> 抄送: David Melman; [email protected]; LISP mailing list list; Tom Herbert >> 主题: Re: [nvo3] Comments on >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >>> Hi Dino, >>> Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port and >>> a new data format, P bit >> >> No worries. >> >>> in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer 3 >>> communication and intra-subnet layer 2 communication between NVEs, current >>> NVGRE, VXLAN and LISP have already supported, >> >> VXLAN supports L2 overlays since its goal is to extend subnets. LISP >> supports L3 overlays so it assumes subnets are local (to the xTR) just like >> in a routed network. NVGRE can be a combo. >> >>> NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 network if >>> only basic layer 3 and >> >> There is motivation to extend an encapsulation header (which is called >> VXLAN-GPE) so it can support, most importantly NSH. That change also gives >> VXLAN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate >> functionality of LISP. But the headers are so similar, it really doens't >> matter. >> >> However, the P-bit is not needed for anything new in LISP and the OAM-bit is >> not needed in LISP since LISP has different UDP port number (4342) for >> control-packets. VXLAN does not have a well defined control protocol so the >> data-plane has to escape out control-plane pakcets where the first one is >> this new OAM message. >> >>> layer 2 forwarding process exists. As for some extra functions of OAM, >>> service chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE >>> network should be used in these cases. >>> Thanks >>> weiguo >> >> Right, agree. >> >> Dino >> >>> >>> >>> ________________________________________ >>> 发件人: Dino Farinacci [[email protected]] >>> 发送时间: 2014年7月28日 21:15 >>> 收件人: Haoweiguo >>> 抄送: Tom Herbert; David Melman; [email protected]; LISP mailing list list >>> 主题: Re: 答复: [nvo3] Comments on >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>> >>>> On Jul 28, 2014, at 7:24 AM, Haoweiguo <[email protected]> wrote: >>>> >>>> About backward compatibility, i also agree with Dino. VXLAN-GPE should >>>> focus on the VXLAN-GPE header and requires the assignment of a new UDP >>>> port, the data format don't need consider backward compatibility with >>>> VXLAN header. I >>> >>> I want to make it clear that supporting backward compatibility is very >>> important since VXLAN-port-4789 is supported in various chips already. >>> >>> Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
