Lucy,
there is no such thing as voting in IETF WGs
And I haven't seen anything like voting as part of this discussion.
Thank you
Martin
Le 20/11/2015 20:57, Lucy yong a écrit :
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.raba...@alcatel-lucent.com]
Sent: Friday, November 20, 2015 1:32 PM
To: UTTARO, JAMES; John E Drake; EXT - thomas.mo...@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-boun...@ietf.org on
behalf of ju1...@att.com> wrote:
+1
-----Original Message-----
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
Sent: Friday, November 20, 2015 12:19 PM
To: EXT - thomas.mo...@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.mo...@orange.com [mailto:thomas.mo...@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-boun...@ietf.org] On Behalf Of Lucy yong
Sent: Friday, November 20, 2015 11:49 AM
To: EXT - thomas.mo...@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-boun...@ietf.org] On Behalf Of
thomas.mo...@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-boun...@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-boun...@ietf.org <mailto:bess-boun...@ietf.org>] on
behalf of John E Drake [jdr...@juniper.net
<mailto:jdr...@juniper.net>]
Sent: Wednesday, November 18, 2015 2:49 To: Henderickx, Wim
(Wim);
EXT - thomas.mo...@orange.com
<mailto:thomas.mo...@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-boun...@ietf.org
<mailto:bess-boun...@ietf.org>] On Behalf Of Henderickx, Wim
(Wim) Sent: Tuesday, November 17, 2015
12:49 PM To: EXT - thomas.mo...@orange.com
<mailto:thomas.mo...@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.mo...@orange.com
<mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com
<mailto:thomas.mo...@orange.com>>" <thomas.mo...@orange.com
<mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com
<mailto:thomas.mo...@orange.com>>> Organization: Orange Date:
Tuesday 17 November 2015 at 01:37 To: Wim Henderickx
<wim.henderi...@alcatel-lucent.com
<mailto:wim.henderickx@alcatel-
lucent.com><mailto:wim.henderickx@alc
atel-lucent.com
<mailto:wim.henderi...@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.mo...@orange.com
<mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com
<mailto:thomas.mo...@orange.com>>> Organization: Orange Date:
Friday 13 November 2015 at 09:57 To: Wim Henderickx
<wim.henderi...@alcatel-lucent.com
<mailto:wim.henderickx@alcatel-
lucent.com><mailto:wim.henderickx@alc
atel-lucent.com
<mailto:wim.henderi...@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 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
