Hi Marc, VXLAN-GPE have next protocol field, so it can combine multiple data planes into one VXLAN-gpe. Currently inner destination MAC can be used to distinguish layer 2 and layer 3 traffic at egress NVE. Thanks weiguo ________________________________________ 发件人: Marc Binderberger [m...@sniff.de] 发送时间: 2014年7月30日 14:40 收件人: Haoweiguo 抄送: Dino Farinacci; David Melman; n...@ietf.org; LISP mailing list list; Tom Herbert 主题: Re: [nvo3] 答复: 答复: Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Hello Weiguo, I would say there is a difference if your "layer-3" service is actually a layer-2 Ethernet frame with the destination MAC of the encapsulated packet being identical with the MAC of the decapsulating system, compared to a layer-3 service where your whole processing stays solely in the layer-3, no MAC involved. If I want to define a layer-3 encapsulation (like LISP, like the proposed VxLAN-gpe with IPv4/v6 as protocol) then having any layer-2 in the process seems a bit "odd". Worse, the involved systems may not have this layer-2 logic. LISP for example is often used in the WAN, even when some encapsulator/decapsulator are DC switches. Some of these WAN systems may be pure IPv4/v6 routers. In other words: having both a layer-2 (VxLAN) and a layer-3 (LISP) encapsulation makes good sense. The question is: shall we keep it separated as it is today as "LISP" and "VxLAN" or combine the (expensive) multiple data planes into one VxLAN-gpe. Regards, Marc On Wed, 30 Jul 2014 03:15:19 +0000, Haoweiguo 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 [farina...@gmail.com] > 发送时间: 2014年7月29日 20:18 > 收件人: Haoweiguo > 抄送: David Melman; n...@ietf.org; 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 <haowei...@huawei.com> 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 [farina...@gmail.com] >> 发送时间: 2014年7月28日 22:17 >> 收件人: Haoweiguo >> 抄送: David Melman; n...@ietf.org; 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 [farina...@gmail.com] >>> 发送时间: 2014年7月28日 21:15 >>> 收件人: Haoweiguo >>> 抄送: Tom Herbert; David Melman; n...@ietf.org; 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 <haowei...@huawei.com> 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 > n...@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
