Hello Weiguo, > VXLAN-GPE have next protocol field, so it can combine multiple data planes > into one VXLAN-gpe.
so you are fine with the VxLAN-gpe layout then? Okay, I misunderstood this. > Currently inner destination MAC can be used to > distinguish layer 2 and layer 3 traffic at egress NVE. as I said I see a subtle difference here and would say VxLAN is doing a layer-2 operation. Nevertheless, if your encapsulation/decapsulation network elements understand this layer-2 aspect, are capable to add Ethernet header, VxLAN shim and outer IP header onto the inner IP packet etc., then yes, you could transport layer-3 with VxLAN. Regards, Marc > Thanks > weiguo > ________________________________________ > 发件人: Marc Binderberger [[email protected]] > 发送时间: 2014年7月30日 14:40 > 收件人: Haoweiguo > 抄送: Dino Farinacci; David Melman; [email protected]; 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 [[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 >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
