Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
John E Drake <jdrake@juniper.net> Fri, 20 November 2015 16:53 UTC
Return-Path: <jdrake@juniper.net>
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 DCAD01B3870 for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 08:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 RDT_QmitrmzW for <bess@ietfa.amsl.com>; Fri, 20 Nov 2015 08:53:43 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB5E1B38F6 for <bess@ietf.org>; Fri, 20 Nov 2015 08:53:36 -0800 (PST)
Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 16:53:34 +0000
Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 16:53:34 +0000
From: John E Drake <jdrake@juniper.net>
To: Lucy yong <lucy.yong@huawei.com>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.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/4i3EuknzuoW5FiTp6hcc6AgAG7hoCAAEXDAIABLXKAgACCkICAAAC0wA==
Date: Fri, 20 Nov 2015 16:53:34 +0000
Message-ID: <SN1PR0501MB17097DB817349384430E64A9C71A0@SN1PR0501MB1709.namprd05.prod.outlook.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>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5721B124@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net;
x-originating-ip: [66.129.241.11]
x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 5:g6s2Y+QPmrrRg75EFTvOuF7IF2IizvJtrvhQy3aoK9m4gWyUKydGRz08BLVkiRUKI5WPsdbv0Nix9V/bhr5cmtBfKTRm9ZuJDtydTPLV74VceA8DVZv3goQHOxpbOqDSNM3pBVtIvJQ6Z7joUUOT3A==; 24:+gYxhL6Ot3+W3cbEhJ8Fperue7K4TpyDtAostcRlK9wOcG5iNnv3P8OOswM7QfD8GDVLpnw0yKMVD/VWxBDBiVPzQcjZtoeEWrjI28CtPvU=; 20:peA6OTb1/sVrUyL69YHHRid7/yjP456HUnuHCni4r4DR5cnIlPuJt1RrJijy8zCIdGLs1rQRxFnlCaTF4cXIiQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710;
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <SN1PR0501MB171001475C2175548486707CC71A0@SN1PR0501MB1710.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(18271650672692);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(199003)(13464003)(189002)(377424004)(2950100001)(561944003)(86362001)(74316001)(87936001)(76176999)(92566002)(106356001)(19580395003)(77096005)(2501003)(5008740100001)(99286002)(106116001)(5007970100001)(50986999)(54356999)(93886004)(11100500001)(33656002)(105586002)(5002640100001)(107886002)(101416001)(76576001)(97736004)(5004730100002)(230783001)(122556002)(5003600100002)(189998001)(6116002)(4001150100001)(5001770100001)(81156007)(15975445007)(3846002)(586003)(2900100001)(10400500002)(5001960100002)(66066001)(102836003)(19580405001)(5890100001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 16:53:34.8305 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/duPFWiAizcY1yY7yzo02T4Y2NHc>
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 16:53:48 -0000
Lucy, That presupposes that the group likes either of the two proposed solutions in your draft. Yours Irrespectively, John > -----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, the > >>> reasons for rejecting a proposal need to be thoroughly understood. > >>> WH> my point is what is the real driver for supporting a plain 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
- [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