Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Haoweiguo <haoweiguo@huawei.com> Sat, 21 November 2015 07:18 UTC
Return-Path: <haoweiguo@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 12CB51B4110 for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 23:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level:
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 WwZeEZvOKJO4 for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 23:18:09 -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 873E41B4109 for <bess@ietf.org>; Fri, 20 Nov 2015 23:18:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEK24775; Sat, 21 Nov 2015 07:18:05 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 21 Nov 2015 07:18:04 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Sat, 21 Nov 2015 15:17:53 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: "UTTARO, JAMES" <ju1738@att.com>, John E Drake <jdrake@juniper.net>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Lucy yong <lucy.yong@huawei.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Thread-Index: AQHRIcnnJGngb/4i3EuknzuoW5FiTp6hcc6AgAG7hoCAAEXDAIABLXKAgACCkICAAAC0wP//fWyAgAAEJwCAAAkBAIABZOjN
Date: Sat, 21 Nov 2015 07:17:52 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F8E9D35@nkgeml501-mbs.china.huawei.com>
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>
In-Reply-To: <B17A6910EEDD1F45980687268941550F0CD4F501@MISOUT7MSGUSRCD.ITServices.sbc.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.23.94]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56501AAE.0128, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, 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/_Yiifl_VPDkC298b7g9DDs9brPo>
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: Sat, 21 Nov 2015 07:18:14 -0000
Hi Jim & John, Firstly i think option-C interconnection between cloud data center and MPLS VPN network exists. Secondly, i think for different encapsulations, different interconnecting methods are needed. For VXLAN/NVGRE, VTEP IP/UDP Port allocation solutions are needed. Only for MPLSoGRE/oUDP, both standard MPLS+MPLS+GRE/UDP and VTEP IP/UDP Port allocation solution can work, it shoud be measured which one is more suitable or both solutions are proposed to the industry for reference. Thanks, weiguo ________________________________________ From: BESS [bess-bounces@ietf.org] on behalf of UTTARO, JAMES [ju1738@att.com] Sent: Saturday, November 21, 2015 1:51 To: 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 +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 goal, > >>>>> TM> 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