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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
