Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Lucy yong <lucy.yong@huawei.com> Fri, 20 November 2015 19:58 UTC
Return-Path: <lucy.yong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5601B33BD for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 11:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Level:
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goc-Wzd5_N-J for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 11:57:56 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2EE1B33BB for <bess@ietf.org>; Fri, 20 Nov 2015 11:57:55 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEJ93486; Fri, 20 Nov 2015 19:57:53 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 20 Nov 2015 19:57:52 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Fri, 20 Nov 2015 11:57:46 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: "Rabadan, Jorge (Jorge)" <jorge.rabadan@alcatel-lucent.com>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Thread-Index: AQHRI3IOJGngb/4i3EuknzuoW5FiTp6jxQsAgAEtcoCAAIKQgIAAAU8AgAAC7oCAAAQmAP//tSIggACg1oD//37R8A==
Date: Fri, 20 Nov 2015 19:57:46 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5721B256@dfweml701-chm>
References: <CACS9xV+FhSwLHmhAO42PTE3iOWEk4YgYm7uDC0B-faH0dOewPQ@mail.gmail.com> <19AB2A007F56DB4E8257F949A2FB9858A97DF65E@nkgeml512-mbx.china.huawei.com> <564DAA0B.7050707@orange.com> <E3852711-1729-41F5-BC5F-19639F56C97A@alcatel-lucent.com> <8458_1448010096_564EE170_8458_13965_3_564EE16F.2010902@orange.com> <2691CE0099834E4A9C5044EEC662BB9D5721B124@dfweml701-chm> <SN1PR0501MB17097DB817349384430E64A9C71A0@SN1PR0501MB1709.namprd05.prod.outlook.com> <22461_1448039044_564F5284_22461_15936_1_564F5283.3070301@orange.com> <SN1PR0501MB170967F5BE17394B8BB501B4C71A0@SN1PR0501MB1709.namprd05.prod.outlook.com> <B17A6910EEDD1F45980687268941550F0CD4F501@MISOUT7MSGUSRCD.ITServices.sbc.com> <9C29802C-77FD-4542-A02D-F020999AC60A@alcatel-lucent.com>
In-Reply-To: <9C29802C-77FD-4542-A02D-F020999AC60A@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.152.239]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.564F7B41.0086, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ceb60f37a8fd0834926d760c5c14f917
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/JeKq1twh-X77G_vsQPGS_pBsjpE>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2015 19:58:02 -0000
IMHO: voting on this thread does not make a sense. Both solutions will work and scales. Lucy -----Original Message----- From: Rabadan, Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com] Sent: Friday, November 20, 2015 1:32 PM To: UTTARO, JAMES; John E Drake; EXT - thomas.morin@orange.com; Lucy yong; Henderickx, Wim (Wim); bess@ietf.org Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc IMHO if TOR chip vendors can confirm they are seriously looking at MPLS/MPLS/UDP, Wim’s suggestion makes all the sense since we know it works and scales. My 2 cents. Jorge On 11/20/15, 9:51 AM, "BESS on behalf of UTTARO, JAMES" <bess-bounces@ietf.org on behalf of ju1738@att.com> wrote: >+1 > >-----Original Message----- >From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of John E Drake >Sent: Friday, November 20, 2015 12:19 PM >To: EXT - thomas.morin@orange.com; Lucy yong; Henderickx, Wim (Wim); >bess@ietf.org >Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc > >Lucy, > >My apologies, I misunderstood. > >I think we have to accept the fact that we will have to deal with a multiplicity of different encapsulations in the data plane along a packet's e2e path and that we should take a more measured approach to deciding how to deal with this in a general and extensible way before accepting any solutions. > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: thomas.morin@orange.com [mailto:thomas.morin@orange.com] >> Sent: Friday, November 20, 2015 12:04 PM >> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); bess@ietf.org >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc >> >> 2015-11-20, John E Drake: >> > That presupposes that the group likes either of the two proposed >> > solutions >> in your draft. >> >> John, I think Lucy's "two solutions" was referring to >> draft-hao-bess-inter- nvo3-vpn-optionc solution and the 3-label >> Optionc MPLS/MPLS/UDP solution described by Wim. >> >> -Thomas >> >> >> >> > >> >> -----Original Message----- >> >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong >> >> Sent: Friday, November 20, 2015 11:49 AM >> >> To: EXT - thomas.morin@orange.com; Henderickx, Wim (Wim); >> >> bess@ietf.org >> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc >> >> >> >> Share my 2 cent. >> >> >> >> Cloud providers want to tunnel its customer traffic through DC (AS)BR. >> >> Option C is a way to realize it. Both solutions summarized by >> >> Thomas have no change on WAN VPN side and seamlessly work with WAN >> >> VPN >> option C. >> >> However, to support either solution, DC has to do some enhancement >> >> on DC BR or ToR switch, etc, which dictates to different >> >> implementations within a DC. Option C pro and con remains >> >> regardless what implementation is used in a DC. >> >> >> >> Two solutions should not coexist in one DC (does not make a >> >> sense), but it does not matter if one DC operator prefers to use >> >> one solution and another DC prefers to use another solution. Since >> >> there are many cloud providers today, it is worth for the WG to >> >> document both solutions and point out the implementation >> >> requirements on impacted components. Then, up to vendors and >> >> operators to select a solution for >> their DC. >> >> >> >> It does not make a sense for us to vote which solution is better >> >> here because a better solution for a DC depends on many factors. >> >> >> >> >> >> Lucy >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of >> >> thomas.morin@orange.com >> >> Sent: Friday, November 20, 2015 3:02 AM >> >> To: Henderickx, Wim (Wim); bess@ietf.org >> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc >> >> >> >> 2015-11-19, Henderickx, Wim (Wim): >> >>> WH> I vote for a an evolution of switches/TORs that have proper >> >>> support for this. I hope some HW vendors of TOR chips shime in, >> >>> but I am told the MPLS solution is possible in the next >> >>> generation chips they are working on. >> >> >> >> Well, it looks like the key questions are: >> >> - when would ToR chips support MPLS/MPLS/UDP ? (the generation >> >> that has been released recently but not present in most shipping >> >> ToRs yet, the next one ?) >> >> - do we want an interim VXLAN-based solution ? (that will involve >> >> at best a performance penalty with existing chips, and at worse >> >> impossible to implement -- we haven't seen clear information in >> >> this >> >> thread) >> >> >> >> -Thomas >> >> >> >> >> >>>> Zhuangshunwan : >> >>>>> >> >>>>> Hi Diego, >> >>>>> >> >>>>> Thanks for your comments. Pls see inline with [Vincent]. >> >>>>> >> >>>>> Vincent >> >>>>> >> >>>>> *发件人:*BESS [mailto:bess-bounces@ietf.org] *代表 *Diego Garcia >> >> del Rio >> >>>>> *发送时间:*2015年11月18日14:25 *收件人:*bess@ietf.org *主题 >> >> :*Re: [bess] >> >>>>> draft-hao-bess-inter-nvo3-vpn-optionc >> >>>>> >> >>>>> Some comments from my side, I think the draft makes quite a few >> >>>>> assumptions on specific implementation details that are way too >> >>>>> general to be considered widely available. Most of the TOR >> >>>>> devices today already pay a double-pass penalty when doing >> >>>>> routing of traffic in/out of vxlan-type tunnels. Only the >> >>>>> newest generation can route into tunnels without additional >> >>>>> passes. And are definitively limited in being able to arbitrary >> >>>>> select UDP ports on a per tunnel basis. In fact, most are even >> >>>>> limited at using more than one VNID per "service" of sorts. >> >>>>> [Vincent]: Yes, the new generation BCM chipset has already >> >>>>> supported VXLAN routing >> without >> >>>>> additional passes. For OVS/TOR, VXLAN encapsulation is more >> >>>>> popular than MPLSoGRE/UDP, and has better performance. The >> >>>>> IP-addressed based implementation which would, I assume, imply >> >>>>> assigning one or more CIDRs to a loopback interface on the >> >>>>> ASBR-d is also quite arbitrary and does not seem like a >> >>>>> technically "clean" solution. (besides burning tons of IPs). As >> >>>>> a side-note, most PE-grade routers i've worked with were quite >> >>>>> limited in terms of IP addresses used for tunnel termination >> >>>>> and it wasn't that just a simple pool can be used. [Vincent]: I >> >>>>> think the larger VTEP IP address range on ASBR-d has no limitations. >> >>>>> For the hardware on ASBR-d, it has capability to terminate >> >>>>> multiple VXLAN tunnels with arbitrary destination VTEP IP >> >>>>> addresses. Wim's mentions on cases where the Application >> >>>>> itself, hosted in a datacenter, would be part of the option-C >> >>>>> interconnect, was dismissed without much discussion so far, >> >>>>> while, if we look in detail at the type of users which will >> >>>>> even consider a complex topology like model-C its most likely >> >>>>> users and operators very familiar with MPLS VPNs in the WAN. >> >>>>> Those type of operators will most likely be very interested in >> >>>>> deploying MPLS or WAN-grade applications (i.e., virtual-routers >> >>>>> or other >> >>>>> VNFs) in the DC and thus its highly likely that the >> >>>>> interconnect would not terminate at the NVE itself but rather >> >>>>> the TS (the virtual machine). Also, the use of UDP ports at >> >>>>> random would imply quite complex logic on the ASBR-d IMHO. Im >> >>>>> not saying its impossible, but since the received packet now >> >>>>> not only has to be received on a random (though locally chosen) >> >>>>> UDP port and this information preserved in the pipeline to be >> >>>>> able to do the double-tunnel-stitching, it sounds quite >> >>>>> complex. I am sure someone in the list will mention this has >> >>>>> already been implemented somewhere, and I won't argue with >> >>>>> that. And let's not even bring into account what this would do >> >>>>> to any DC middlebox that now has to look at vxlan over almost >> >>>>> any random port. We have to go back to the "is it a 4 or is it >> >>>>> a 6 in byte x" heuristics to try to guess whether the packet is >> >>>>> vxlan or just something entirely different running over IP. >> >>>>> [Vincent]: Using NP or multi-core CPU hardware technology, it >> >>>>> can be implemented although deeper packet inspection is needed >> >>>>> to perform UDP port and MPLS stitching. In general I feel the >> >>>>> proposed solution seems to be fitting of a specific use-case which is not really detailed >> >>>>> in the draft and does not describe a solution that would >> >>>>> "elegantly" solve the issues at hand. It just feels like we're >> >>>>> using any available bit-space to stuff data into places that do >> >>>>> not necesarily belong. Yes, MPLS encapsulations on virtual >> >>>>> switches are not yet fully available, and there can be some >> >>>>> performance penalty on the TORs, but the solutions are much >> >>>>> cleaner from a control and data plane point of view. Maybe I'm >> >>>>> too utopic. [Vincent]: I think pure VXLAN solution has its >> >>>>> scenario, it's general rather than specific. We can't require >> >>>>> all OVS/NVEs support VXLAN + MPLSoGRE at the same time. Best >> >>>>> regards, Diego >> >>>>> --------------------------------------------------------------- >> >>>>> --- >> >>>>> -- >> >>>>> ------------- >> >>>>> >> >>>>> >> >> Hi, >> >>>>> The problem we are trying to solve is to reduce data center >> >>>>> GW/ASBR-d's forwarding table size, the motivation is same as >> >>>>> traditional MPLS VPN option-C. Currently, the most common >> >>>>> practise on ASBR-d is to terminate VXLAN encapsulation, look up >> >>>>> local routing table, and then perform MPLS encapsulation to the >> >>>>> WAN >> network. >> >>>>> ASBR-d needs to maintain all VM's MAC/IP. In Option-C method, >> >>>>> only transport layer information needed to be maintained at >> >>>>> GW/ASBR-d, the scalability will be greatly enhanced. Traditonal >> >>>>> Option-C is only for MPLS VPN network interworking, because >> >>>>> VXLAN is >> becoming >> >>>>> pervasive in data center, the solution in this draft was >> >>>>> proposed for the heterogeneous network interworking. The >> >>>>> advantage of this solution is that only VXLAN encapsulation is required for OVS/TOR. >> >>>>> Unlike Wim's solution, east-west bound traffic uses VXLAN >> >>>>> encap, while north-south bound traffic uses MPLSoGRE/UDP encap. >> >>>>> There >> are >> >>>>> two solutions in this draft: 1. Using VXLAN tunnel destination >> >>>>> IP for stitching at ASBR-d. No data plane modification >> >>>>> requirements on OVS or TOR switches, only hardware changes on >> >>>>> ASBR-d. ASBR-d normally is router, it has capability to realize >> >>>>> the hardware changes. It will consume many IP addresses and the >> >>>>> IP pool for allocation needs to be configured on ASBR-d >> >>>>> beforehand. 2. Using VXLAN destination UDP port for stitching >> >>>>> at ASBR-d. Compared with solution 1, less IP address will be >> >>>>> consumed for allocation. If UDP port range is too large, we can combine with solution 1 and 2. >> >>>>> In this solution, both data plane modification changes are >> >>>>> needed at OVS/TOR and ASBR-d. ASBR-d also has capability to >> >>>>> realize the hardware changes. For OVS, it also can realize the >> >>>>> data plane changes. For TOR switch, it normally can't realize this function. >> >>>>> This solution mainly focuses on pure software based overlay >> >>>>> network, it has more scalability. In public cloud data center, >> >>>>> software based overlay network is the majority case. Whether >> >>>>> using solution 1 or 2 depends on the operators real envionment. >> >>>>> So I think our solution has no flaws, it works fine. >> >>>>> Thanks, weiguo ________________________________ From: BESS >> >>>>> [bess-bounces@ietf.org <mailto:bess-bounces@ietf.org>] on >> >>>>> behalf of John E Drake [jdrake@juniper.net >> >>>>> <mailto:jdrake@juniper.net>] >> >>>>> Sent: Wednesday, November 18, 2015 2:49 To: Henderickx, Wim >> (Wim); >> >>>>> EXT - thomas.morin@orange.com >> <mailto:thomas.morin@orange.com>; >> >> BESS >> >>>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Hi, I >> >>>>> think Wim has conclusively demonstrated that this draft has >> >>>>> fatal flaws and I don’t support it. I also agree with his >> >>>>> suggestion that we first figure out what problem we are trying >> >>>>> to solve before solving it. Yours Irrespectively, John From: >> >>>>> BESS [mailto:bess-bounces@ietf.org >> >>>>> <mailto:bess-bounces@ietf.org>] On Behalf Of Henderickx, Wim >> >>>>> (Wim) Sent: Tuesday, November 17, 2015 >> >>>>> 12:49 PM To: EXT - thomas.morin@orange.com >> >>>>> <mailto:thomas.morin@orange.com>; BESS Subject: Re: [bess] >> >>>>> draft-hao-bess-inter-nvo3-vpn-optionc — Snip — No, the spec as >> >>>>> it is can be implemented in its VXLAN variant with existing >> >>>>> vswitches (e.g. OVS allows to choose the VXLAN destination >> >>>>> port, ditto for the linux kernel stack). (ToR is certainly >> >>>>> another story, most of them not having a flexible enough VXLAN >> >>>>> dataplane nor support for any >> >>>>> MPLS-over-IP.) WH> and how many ports simultaneously would they >> >>>>> support? For this to work every tenant needs a different VXLAN >> >>>>> UDP destination port/receive port. There might be SW elements >> >>>>> that could do some of this, but IETF defines solutions which >> >>>>> should be implemented across the board HW/SW/etc. >> >>>>> Even if some SW switches can do this, the proposal will impose >> >>>>> so many issues in HW/data-plane engines that I cannot be behind >> >>>>> this solution. To make this work generically we will have to >> >>>>> make changes anyhow. Given this, we better do it in the right >> >>>>> way and guide the industry to a solution which does not imply >> >>>>> those >> complexities. >> >>>>> Otherwise we will stick with these specials forever with all >> >>>>> consequences (bugs, etc). - snip - From: >> >>>>> "thomas.morin@orange.com >> >>>>> >> >> >> <mailto:thomas.morin@orange.com><mailto:thomas.morin@orange.com >> >>>>> <mailto:thomas.morin@orange.com>>" <thomas.morin@orange.com >> >>>>> >> >> >> <mailto:thomas.morin@orange.com><mailto:thomas.morin@orange.com >> >>>>> <mailto:thomas.morin@orange.com>>> Organization: Orange Date: >> >>>>> Tuesday 17 November 2015 at 01:37 To: Wim Henderickx >> >>>>> <wim.henderickx@alcatel-lucent.com >> >>>>> <mailto:wim.henderickx@alcatel- >> >> lucent.com><mailto:wim.henderickx@alc >> >>>>> atel-lucent.com >> >>>>> >> >>>>> >> >> <mailto:wim.henderickx@alcatel-lucent.com>>>, BESS <bess@ietf.org >> >>>>> <mailto:bess@ietf.org><mailto:bess@ietf.org >> >>>>> <mailto:bess@ietf.org>>> Subject: Re: [bess] >> >>>>> draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, WG, 2015-11-16, >> >>>>> Henderickx, Wim (Wim): 2015-11-13, Henderickx, Wim (Wim): >> Thomas, >> >> we >> >>>>> can discuss forever and someone need to describe requirements, >> >>>>> but the current proposal I cannot agree to for the reasons explained. >> >>>>> TM> Well, although discussing forever is certainly not the >> >>>>> TM> goal, the >> >>>>> reasons for rejecting a proposal need to be thoroughly understood. >> >>>>> WH> my point is what is the real driver for supporting a plain >> >>>>> WH> VXLAN >> >>>>> data-plane here, the use cases I have seen in this txt is >> >>>>> always where an application behind a NVE/TOR is demanding >> >>>>> option c, but none of the NVE/TOR elements. >> >>>>> My understanding is that the applications are contexts where >> >>>>> overlays are present is when workloads (VMs or baremetal) need >> >>>>> to be interconnected with VPNs. In these contexts, there can be >> >>>>> reasons to want Option C to reduce the state on ASBRs. In these >> >>>>> context, its not the workload (VM or baremetal) that would >> >>>>> typically handle VRFs, but really the vswitch or ToR. WH2> can >> >>>>> it not >> be all cases: >> >>>>> TOR/vswitch/Application. I would make the solution flexible to >> >>>>> support all of these not? 2015-11-13, Henderickx, Wim (Wim): >> >>>>> TM> The right trade-off to make may in fact depend on whether >> >>>>> you >> prefer: >> >>>>> (a) a new dataplane stitching behavior on DC ASBRs (the >> >>>>> behavior specified in this draft) or >> >>>>> (b) an evolution of the encaps on the vswitches and ToRs to >> >>>>> support MPLS/MPLS/(UDP or GRE) WH> b depends on the use case I >> >>>>> don't get what you mean by "b depends on the use case". WH> see >> my >> >>>>> above comment. If the real use case is an application behind >> >>>>> NVE/TOR requiring model C, than all the discussion on impact on >> >>>>> NVE/TOR is void. As such I want to have a discussion on the >> >>>>> real driver/requirement for option c interworking with an IP >> >>>>> based Fabric. Although I can agree than detailing requirements >> >>>>> can always help, I don't think one can assume a certain >> >>>>> application to dismiss the proposal. WH> for me the proposal is >> >>>>> not acceptable for the reasons explained: too much impact on >> >>>>> the data-planes I wrote the above based on the idea that the >> >>>>> encap used in MPLS/MPLS/(UDP or GRE), which hence has to be >> >>>>> supported on the >> ToRs and vswitches. >> >>>>> Another possibility would be >> >>>>> service-label/middle-label/Ethernet >> >>>>> assuming an L2 adjacency between vswitches/ToRs and ASBRs, but >> >>>>> this certainly does not match your typical DC architecture. Or >> >>>>> perhaps had you something else in mind ? WH> see above. The >> >>>>> draft right now also requires changes in existing TOR/NVE so >> >>>>> for me all this discussion/debate is void. No, the spec as it >> >>>>> is can be implemented in its VXLAN variant with existing >> >>>>> vswitches (e.g. OVS allows to choose the VXLAN destination >> >>>>> port, ditto for the linux kernel stack). (ToR is certainly >> >>>>> another story, most of them not having a flexible enough VXLAN >> >>>>> dataplane nor support for any >> >>>>> MPLS-over-IP.) >> >>>>> WH> and how many ports simultaneously would they support? WH> >> and >> >>>>> depending on implementation you don’t need to change any of the >> >>>>> TOR/vswitches. Does this mean that for some implementations you >> >>>>> may not need to change any of the TOR/vswitches, but that for >> >>>>> some others you may ? WH> any proposal on the table requires >> >>>>> changes, so for me this is not a valid discussion See above, >> >>>>> the proposal in the draft does not necessarily need changes in >> >>>>> vswitches. Let me take a practical example : while I can quite >> >>>>> easily see how to implement the procedures in >> >>>>> draft-hao-bess-inter-nvo3-vpn-optionc >> >>>>> based on current vswitch implementations of VXLAN, the lack of >> >>>>> MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to >> >> me as >> >>>>> making that alternate solution you suggest harder to implement. >> >>>>> WH> I would disagree to this. Tell me which switch/TOR handles >> >>>>> multiple UDP ports for VXLAN ? I mentioned _v_switches, and >> >>>>> many do support a variable destination port for VXLAN, which is >> >>>>> sufficient to implement what the draft proposes. -Thomas From: >> >>>>> Thomas Morin <thomas.morin@orange.com >> >>>>> >> >> >> <mailto:thomas.morin@orange.com><mailto:thomas.morin@orange.com >> >>>>> <mailto:thomas.morin@orange.com>>> Organization: Orange Date: >> >>>>> Friday 13 November 2015 at 09:57 To: Wim Henderickx >> >>>>> <wim.henderickx@alcatel-lucent.com >> >>>>> <mailto:wim.henderickx@alcatel- >> >> lucent.com><mailto:wim.henderickx@alc >> >>>>> atel-lucent.com >> >>>>> >> >>>>> >> >> <mailto:wim.henderickx@alcatel-lucent.com>>> >> >>>>> Cc: "bess@ietf.org <mailto:bess@ietf.org><mailto:bess@ietf.org >> >>>>> <mailto:bess@ietf.org>>" <bess@ietf.org >> >>>>> <mailto:bess@ietf.org><mailto:bess@ietf.org >> >>>>> <mailto:bess@ietf.org>>> Subject: Re: [bess] >> >>>>> draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, I agree on the >> >>>>> analysis that this proposal is restricted to implementations >> >>>>> that supports the chosen encap with non-IANA ports (which may >> >>>>> be hard to achieve for instance on hardware implementations, as >> >>>>> you suggest), or to context where managing multiple IPs would >> >>>>> be operationally viable. However, it does not seem obvious to >> >>>>> me how the alternative you propose [relying on 3-label option C >> >>>>> with an >> >>>>> MPLS/MPLS/(UDP|GRE) encap] addresses the issue of whether the >> >> encap >> >>>>> behavior is supported or not (e.g. your typical ToR chipset >> >>>>> possibly may not support this kind of encap, and even >> >>>>> software-based switches may not be ready to support that today). >> >>>>> My take is that having different options to adapt to various >> >>>>> implementations constraints we may have would have value. (+ >> >>>>> one question below on VXLAN...) -Thomas 2015-11-12, Henderickx, >> >>>>> Wim >> >>>>> (Wim): On VXLAN/NVGRE, do you challenge the fact that they >> >>>>> would be used with a dummy MAC address that would be replaced >> >>>>> by the right MAC by a sender based on an ARP request when >> >>>>> needed ? Is the above the issue you had in mind about VXLAN and >> >>>>> NVGRE ? WH> yes I you don't mind me asking : why do you challenge that ? >> >>>>> >> >> >> >> >> __________________________________________________________ >> >> >> __________________________________________________________ >> >> _____ >> >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> >> confidentielles ou privilegiees et ne doivent donc pas etre >> >> diffuses, exploites ou copies sans autorisation. Si vous avez recu >> >> ce message par erreur, veuillez le signaler a l'expediteur et le >> >> detruire ainsi que les pieces jointes. Les messages electroniques >> >> etant susceptibles d'alteration, France Telecom - Orange decline >> >> toute responsabilite si ce message a ete altere, deforme ou >> >> falsifie. Merci >> >> >> >> This message and its attachments may contain confidential or >> >> privileged information that may be protected by law; they should >> >> not be distributed, used or copied without authorization. >> >> If you have received this email in error, please notify the sender >> >> and delete this message and its attachments. >> >> As emails may be altered, France Telecom - Orange shall not be >> >> liable if this message was modified, changed or falsified. >> >> Thank you. >> >> >> >> _______________________________________________ >> >> BESS mailing list >> >> BESS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ >> >> BESS mailing list >> >> BESS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bess >> >> >> __________________________________________________________ >> __________________________________________________________ >> _____ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, France Telecom - Orange decline toute responsabilite si >> ce message a ete altere, deforme ou falsifie. Merci >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorization. >> If you have received this email in error, please notify the sender >> and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange shall not be liable >> if this message was modified, changed or falsified. >> Thank you. > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess
- [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Thomas Morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Linda Dunbar
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- [bess] unsubscribe Lidefeng
- [bess] unsubscribe Lidefeng
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Thomas Morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Thomas Morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Thomas Morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- [bess] unsubscribe Lidefeng
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc John E Drake
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Diego Garcia del Rio
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Zhuangshunwan
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Thomas Morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc UTTARO, JAMES
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Diego Garcia del Rio
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Osama Zia
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc UTTARO, JAMES
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Osama Zia
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc UTTARO, JAMES
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Osama Zia
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc UTTARO, JAMES
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc John E Drake
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc thomas.morin
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc John E Drake
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc UTTARO, JAMES
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Rabadan, Jorge (Jorge)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Martin Vigoureux
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Lucy yong
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Rabadan, Jorge (Jorge)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Martin Vigoureux
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Zhuangshunwan
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Haoweiguo
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Henderickx, Wim (Wim)
- Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc John E Drake