Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Haoweiguo]

Hi Diego,

Thanks for your comments. Pls see inline with  [weiguo3].

Thanks,

weiguo


From: BESS [bess-boun...@ietf.org] on behalf of Diego Garcia del Rio 
[di...@nuagenetworks.net]
Sent: Friday, November 20, 2015 2:00
To: Henderickx, Wim (Wim)
Cc: Thomas Morin; bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Weiguo,

If we're really talking about a public cloud operator where MOST of the 
endpoints would be software, interconnecting DC and WAN environments seems 
pretty blunt to be honest. You're going to be leaking every single /32 IP 
address of the virtual machines into the wide area and most carriers tend to 
avoid that kind of thing since its quite disrutptive in terms of scalability.
[weiguo3]: I just give an example for pure software based overlay network, i 
don't mean the option-c solution should be used in public cloud envionment or 
public cloud is the focus of the option-C. My meaning is that in pure software 
envionment, currently OVS can be modified for the UDP-port-variant VXLAN 
encapsulation. For hardware TOR, it relies on next generation chipset.


Furthermore, wim's proposal does NOT imply changes on the east-west traffic 
patterns. Those would remain on vxlan or whatever new encapsulation we manage 
to come up with at NVO3.
[weiguo3]: Yes, i understood wim's proposal that is east-west bound encap uses 
VXLAN and north-south bound encap uses MPLSoGRE. However, some DC operators 
don't use this pattern, they use VXLAN encapsulation for both north-south bound 
and east-west bound traffic.


Model C interconnect presuposes a high trust relationship between both parties, 
and if the cloud and WAN are operated by the same company, that is valid.
[weiguo3]: Yes, i agree.
Finally, as wim also mentions, the issue of the globally allocated VNIDs is 
quite an issue. This affects the existing TORs since now all the WAN PEs would 
have to organize themselves not to ever allocate overlapping labels (then 
converted to VNIDs) since the DC gear today cannot handle using the same VNID 
on different "services".
[weiguo3]: In data center, normally globally unique VN ID mechanism is used for 
management simplicity. In the option-c solution, similarly, MPLS VPN Label and 
VN ID also is recommended to be globally managed through SDN solution.

Again, you dismiss the top of racks, but I don't think we can propose a 
standard that just simply ignores a good chunk of the DC space.
[weiguo3]: Currently if the UDP-port-variant VXLAN encap solution is deployed, 
the top of racks need to be dismissed, the hardware capability status quo on 
the TOR switch  is limited. In the future, if there are some chipsets support 
the encapsulation, it can also be used on TORs. In summay, TOR dismissing is 
only for current deployment, that's not for the future.

And at the same time, all the DC edge routers where we propose to implement 
these complex mapping have larger and larger scaling tables with route 
capacities in the order of millions of prefixes these days. And while model A 
has the burden of provisioning the DC edge with the VRF instance, the fact it 
can do prefix lookups means it doesnt need to leak every single /32 to the wide 
area and instead expose the aggregates.
[weiguo3]: This is the common issue for Option-C. Just as you said, it is very 
suitable for a high trustworthy and security envionment, such as cloud data 
center and WAN PE belongs to same company.


Best Regards,




On Thu, Nov 19, 2015 at 7:02 AM, Henderickx, Wim (Wim) 
mailto:wim.henderi...@alcatel-lucent.com>> 
wrote:
Thomas, thx for the time summarising this and great summary.




On 19/11/15 02:52, "BESS on behalf of Thomas Morin" 
mailto:bess-boun...@ietf.org> on behalf of 
thomas.mo...@orange.com> wrote:

>I don't believe the discussion can be usefully summarized in terms of
>"fatal flaws".
>Let me try to summarize my understanding of the thing discussed in this
>thread.
>
>The solution in the draft has an impact on ASBR hardware due to the new
>kind of stitching required (as well summarized by Diego). Whether this
>is a big issue or not depends on the vendor. The solution in the draft,
>for the NVE part, would be implementable in software quite easily. But,
>because of the limitations in the widespread ToR chipsets for VXLAN (and
>their lack of support for MPLS/(GRE or UDP)), its multiple-UDP-port
>variant would be harder to implement in ToRs or at least not without a
>performance hit (people who know that better, feel free to correct).

WH> some HW cannot do this at all, so lets dismiss this idea.

>The multiple-loopback approach has operational drawbacks, but whether or
>not these are killer issues may depend on the targeted scale (in terms
>of number of NVEs) and may depend on other factors (operator practices,
>ability to automate ASBR configs).

WH> ok now we have not discussed the constraints some HW vendors have with 
respect to global VN

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[thomas.morin]

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 p

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[thomas.morin]

2015-11-20, Haoweiguo:

WH> ok now we have not discussed the constraints some HW vendors have
with respect to global VNIDs. To make this work all VNID/Labels need
to be globally unique. Hm

> [weiguo2]:  In SDN scenario, a virtual

network normally is represented by a global VN ID or MPLS VPN Label
to simplify network management. I think it's not strange to allocate
global unique MPLS VPN Label or VN ID for a virtual network now.


In an option C scenario you have to take into account what is done in 
the WAN. Globally-assigned labels are not an option there at all.


-Thomas




The alternative approach, put forward by Wim, consist in using existing
Option-C with a variant of the 3-label variant relying on an
MPLS/MPLS/UDP-or-GRE encap (instead of the 3-label MPLS stack).  This
approach would not necessitate new standardized procedures, would
require less changes on ASBRs. However it is not supported today by
vswitches or ToRs (unless the bottom MPLS label is passed to the VM,
which I think would restrict the application to a subset of the
scenarios for which Option C is interesting). Having it supported in
vswitches may be a simple matter of writing the software, but ToR
support seems to require evolution in chipsets ; whether such a support
is likely to appear hasn't been discussed in the thread.

All in all, it seems there is no solution to cover an Option C scenario
with today's generation ToRs, and the question for tomorrow's generation
ToRs hasn't been really discussed.

Based on the above, I would think the question boils down to whether it
is desirable to specify an Option C variant usable with vswitches as
they are today and possibly usable with a performance hit with today's
ToRs chipsets, at the expense of a required evolution on ASBRs.  The
alternative requiring some evolution on vswitches and waiting for future
ToRs chipsets.

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.
[weiguo2]:  I think it's better not to change current TOR hardware to realize 
option-C interconnection. No TOR hardware modification solution must be 
provided. But for future case, we can propose extra hardware requirements for 
TORs.
The other options requires baggage forever on the ASBR elements that does not 
bring value and it is better to avoid this and build an architecture which is 
future proof and more cost effective. My 2 cents


-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

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Henderickx, Wim (Wim)]

In-line with WH>




On 20/11/15 01:01, "BESS on behalf of thomas.mo...@orange.com" 
 wrote:

>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 ?)
WH> the next generation TOR chips seem to support it, at least this is the info 
I got from 3 vendors
>- 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)
WH> in my view no, since we also have the global VNID issue and a continuous 
tax and ASBR boxes for this.
>
>-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, 

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Henderickx, Wim (Wim)]

On 20/11/15 01:05, "thomas.mo...@orange.com"  wrote:


>2015-11-20, Haoweiguo:
>> WH> ok now we have not discussed the constraints some HW vendors have
>> with respect to global VNIDs. To make this work all VNID/Labels need
>> to be globally unique. Hm
> > [weiguo2]:  In SDN scenario, a virtual
>> network normally is represented by a global VN ID or MPLS VPN Label
>> to simplify network management. I think it's not strange to allocate
>> global unique MPLS VPN Label or VN ID for a virtual network now.
>
>In an option C scenario you have to take into account what is done in 
>the WAN. Globally-assigned labels are not an option there at all.

WH> Agreed. As I said before the proposal in the draft has too many 
implications/restrictions in existing network deployments + requires a 
dedicated data plane in ASBR devices, which we cannot reuse and will add a 
continuous tax in SW/HW (add cost for nothing).
This is why I am against this draft and we should drive the industry to a 
proper solution that does not have these implications.
 
>
>-Thomas
>
>
>>>
>>> The alternative approach, put forward by Wim, consist in using existing
>>> Option-C with a variant of the 3-label variant relying on an
>>> MPLS/MPLS/UDP-or-GRE encap (instead of the 3-label MPLS stack).  This
>>> approach would not necessitate new standardized procedures, would
>>> require less changes on ASBRs. However it is not supported today by
>>> vswitches or ToRs (unless the bottom MPLS label is passed to the VM,
>>> which I think would restrict the application to a subset of the
>>> scenarios for which Option C is interesting). Having it supported in
>>> vswitches may be a simple matter of writing the software, but ToR
>>> support seems to require evolution in chipsets ; whether such a support
>>> is likely to appear hasn't been discussed in the thread.
>>>
>>> All in all, it seems there is no solution to cover an Option C scenario
>>> with today's generation ToRs, and the question for tomorrow's generation
>>> ToRs hasn't been really discussed.
>>>
>>> Based on the above, I would think the question boils down to whether it
>>> is desirable to specify an Option C variant usable with vswitches as
>>> they are today and possibly usable with a performance hit with today's
>>> ToRs chipsets, at the expense of a required evolution on ASBRs.  The
>>> alternative requiring some evolution on vswitches and waiting for future
>>> ToRs chipsets.
>> 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.
>> [weiguo2]:  I think it's better not to change current TOR hardware to 
>> realize option-C interconnection. No TOR hardware modification solution must 
>> be provided. But for future case, we can propose extra hardware requirements 
>> for TORs.
>> The other options requires baggage forever on the ASBR elements that does 
>> not bring value and it is better to avoid this and build an architecture 
>> which is future proof and more cost effective. My 2 cents
>>>
>>> -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.

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Henderickx, Wim (Wim)]

In-line with WH2>




On 19/11/15 22:37, "Haoweiguo"  wrote:

>Hi Wim,
>Pls see inline with [weiguo2].
>weiguo
>
>From: BESS [bess-boun...@ietf.org] on behalf of Henderickx, Wim (Wim) 
>[wim.henderi...@alcatel-lucent.com]
>Sent: Thursday, November 19, 2015 23:02
>To: Thomas Morin; bess@ietf.org
>Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>Thomas, thx for the time summarising this and great summary.
>
>
>On 19/11/15 02:52, "BESS on behalf of Thomas Morin" behalf of thomas.mo...@orange.com> wrote:
>>I don't believe the discussion can be usefully summarized in terms of
>>"fatal flaws".
>>Let me try to summarize my understanding of the thing discussed in this
>>thread.
>>
>>The solution in the draft has an impact on ASBR hardware due to the new
>>kind of stitching required (as well summarized by Diego). Whether this
>>is a big issue or not depends on the vendor. The solution in the draft,
>>for the NVE part, would be implementable in software quite easily. But,
>>because of the limitations in the widespread ToR chipsets for VXLAN (and
>>their lack of support for MPLS/(GRE or UDP)), its multiple-UDP-port
>>variant would be harder to implement in ToRs or at least not without a
>>performance hit (people who know that better, feel free to correct).
>WH> some HW cannot do this at all, so lets dismiss this idea.
>[weiguo2]:  Currently TOR switches can't realize multiple-UDP-port variant 
>VXLAN encapsulation, but we can't give conclusion that hardware can't realize 
>this function forever.
>The TOR only need to do the a little more complicated encap work for the 
>traffic from DC to WAN direction. For the traffic from WAN to DC direction, 
>the encapsulation is normal VXLAN encapsulation, it has no extra decap 
>requirements for the TOR switches. Normally encapsulation process is simpler 
>than decapsulation. The more complicated decap work is performed at ASBR-d 
>which is router device and has more flexibility.
>Currently MPLS+MPLS+GRE encap and decap process may be possible to be realized 
>relying on internal loop in TOR switch, but just as i have mentioned before, 
>many switch doesn't use MPLS over GRE for north-south bound traffic 
>forwarding, they just want to use VXLAN encapsulation for both north-south and 
>east-west bound traffic. I think variant UDP port solution is reasonable, it 
>can't be dismissed.

WH2> this is where we disagree since there are to many implication: global 
VNID, HW tax, etc
>
>>The multiple-loopback approach has operational drawbacks, but whether or
>>not these are killer issues may depend on the targeted scale (in terms
>>of number of NVEs) and may depend on other factors (operator practices,
>>ability to automate ASBR configs).
>WH> ok now we have not discussed the constraints some HW vendors have with 
>respect to global VNIDs. To make this work all VNID/Labels need to be globally 
>unique. Hm
>[weiguo2]:  In SDN scenario, a virtual network normally is represented by a 
>global VN ID or MPLS VPN Label to simplify network management. I think it's 
>not strange to allocate global unique MPLS VPN Label or VN ID for a virtual 
>network now.

WH2> I also disagree on this -> see other email/thread
>>
>>The alternative approach, put forward by Wim, consist in using existing
>>Option-C with a variant of the 3-label variant relying on an
>>MPLS/MPLS/UDP-or-GRE encap (instead of the 3-label MPLS stack).  This
>>approach would not necessitate new standardized procedures, would
>>require less changes on ASBRs. However it is not supported today by
>>vswitches or ToRs (unless the bottom MPLS label is passed to the VM,
>>which I think would restrict the application to a subset of the
>>scenarios for which Option C is interesting). Having it supported in
>>vswitches may be a simple matter of writing the software, but ToR
>>support seems to require evolution in chipsets ; whether such a support
>>is likely to appear hasn't been discussed in the thread.
>>
>>All in all, it seems there is no solution to cover an Option C scenario
>>with today's generation ToRs, and the question for tomorrow's generation
>>ToRs hasn't been really discussed.
>>
>>Based on the above, I would think the question boils down to whether it
>>is desirable to specify an Option C variant usable with vswitches as
>>they are today and possibly usable with a performance hit with today's
>>ToRs chipsets, at the expense of a required evolution on ASBRs.  The
>>alternative requiring some evolution on vswitches and waiting for future
>>ToRs chipsets.
>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.
>[weiguo2]:  I think it's better not to change current TOR hardware to realize 
>option-C interconnection. No TOR hardware modification solution must be 
>provided.

WH2> our mission in IETF to help dri

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

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 

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[John E Drake]

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-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
>

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

That is my 2 cents. Anyone can share his/her opinion. :)
Lucy

-Original Message-
From: John E Drake [mailto:jdr...@juniper.net] 
Sent: Friday, November 20, 2015 10:54 AM
To: Lucy yong; EXT - thomas.mo...@orange.com; Henderickx, Wim (Wim); 
bess@ietf.org
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

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-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 mos

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[thomas.morin]

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 (

Re: [bess] draft-morin-bess-mvpn-fast-failover

[Nehal Bhau]

Besides the below IPR, I am not aware of any other IP related to the draft.

https://datatracker.ietf.org/ipr/2697/

https://datatracker.ietf.org/ipr/2696/

Thanks,

-Nehal
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[John E Drake]

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 ro

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[UTTARO, JAMES]

+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 i

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Rabadan, Jorge (Jorge)]

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"  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 tu

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

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"  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 

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Martin Vigoureux]

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"  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

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

Martin,

Sorry not to express my mind precisely.

I mean to say, debating which solution is a better solution here does not make 
a sense. There is no need for the two solutions interwork.

Regards,
Lucy

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Friday, November 20, 2015 2:13 PM
To: bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

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" 
>  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 VX

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Rabadan, Jorge (Jorge)]

As you said, Lucy, "that is my 2 cents. Anyone can share their opinion” :-)




On 11/20/15, 11:57 AM, "Lucy yong"  wrote:

>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" 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
>>> >>

Re: [bess] One question about Route-type2 usage in EVPN base protocol

[Rabadan, Jorge (Jorge)]

Hi Weiguo,

I would recommend you to check out the L2VPN archives… we discussed this at 
length.
For instance:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg04519.html

But check the other emails in the thread.
Sending one or two routes, really depend on how the learning is done.

Hope it helps.
Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Haoweiguo mailto:haowei...@huawei.com>>
Date: Thursday, November 19, 2015 at 1:37 AM
To: "saja...@cisco.com" 
mailto:saja...@cisco.com>>
Cc: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] One question about Route-type2 usage in EVPN base protocol

Hi Co-authors,
Through ARP process, each EVPN PE can learn local connecting CE’s MAC and IP 
correspondence, and will notify the MAC and IP association to all remote PEs 
through Route-type2 message. Theoretically, each remote PE can rely on the 
single route-type2 message to populate local Mac VRF(MAC table) , ARP Cache and 
IP VRF(IP routing table) at the same time. However, some vendor doesn’t do in 
this way. In its implementation, each PE will notify two route-type2 message to 
remote PEs, one message(say message 1) only carry MAC information(IP field is 
invalid), another message(say message 2) carry MAC and IP association 
information. The remote PEs rely on message 1 to populate local MAC VRF, and 
rely on message 2 to populate local ARP Cache and IP VRF.


I think EVPN protocol should give a clear suggestion for route type-2 message 
usage, what’s the scenario to announce only one message and what’s scenario to 
announce two messages?



Thanks,

weiguo
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Martin Vigoureux]

Lucy,

Thanks for your clarification.
Yet, the fact that two solutions need not interwork does not render 
useless a debate on the merits of each.


-m

Le 20/11/2015 21:36, Lucy yong a écrit :

Martin,

Sorry not to express my mind precisely.

I mean to say, debating which solution is a better solution here does not make 
a sense. There is no need for the two solutions interwork.

Regards,
Lucy

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Friday, November 20, 2015 2:13 PM
To: bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

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"  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-bo

Re: [bess] WG Last Call for draft-ietf-bess-multicast-damping-01

[Martin Vigoureux]

WG

This WG LC has ended some time ago but without any comment on the draft.
It might not have any flaw but I'd like to have the evidence that the 
document has been reviewed.
Please take a moment to read it and get back to this list to share your 
views.


Thanks
-m


Le 13/10/2015 15:40, Martin Vigoureux a écrit :

Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-multicast-damping-01 [1] which is considered mature and
ready for a final working group review.

Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than
*27th of October*.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-multicast-damping, to ensure that IPR has
been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879,
3669 and 5378 for more details).

*If* you are listed as a document author or contributor of
draft-ietf-bess-multicast-damping-01 please respond to this email and
indicate whether or not you are aware of any relevant IPR.

Thank you,
M&T

[1] https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-01

___
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

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Haoweiguo]

Jorge,
We all know that Wim's MPLS/MPLS/UDP solution works, but it's not the only 
choice. Wim's solution requires MPLSoGRE/UDP encap in data center, but many 
data centers only use VXLAN/NVGRE encapsulation for both north-south and 
east-west bound traffic, how to interconnect with outside MPLS VPN network for 
these data centers? So VXLAN/NVGRE and MPLS VPN network interworking is needed.
And for the interconnection solution, we suggest both no TOR/NVE hardware 
enhancement solution and future proof solution should be provided.
Thanks,
weiguo

From: BESS [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) 
[jorge.raba...@alcatel-lucent.com]
Sent: Saturday, November 21, 2015 3:31
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"  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
>> >>
>> >>
>> >>

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Zhuangshunwan]

+1

More popular deployments in data center is VXLAN/NVGRE, so the VXLAN/NVGRE and 
MPLS VPN network interconnecting is necessary. If all TOR/NVEs support 
MPLSoGRE/oUDP, Wim's solution also can be used, but currently it's not 
practical to require all TOR/NVEs to support MPLS/MPLS/UDPorGRE.

Vincent

From: Haoweiguo
Sent: Saturday, November 21, 2015 14:21
To: Rabadan, Jorge (Jorge); 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

Jorge,
We all know that Wim's MPLS/MPLS/UDP solution works, but it's not the only 
choice. Wim's solution requires MPLSoGRE/UDP encap in data center, but many 
data centers only use VXLAN/NVGRE encapsulation for both north-south and 
east-west bound traffic, how to interconnect with outside MPLS VPN network for 
these data centers? So VXLAN/NVGRE and MPLS VPN network interworking is needed.
And for the interconnection solution, we suggest both no TOR/NVE hardware 
enhancement solution and future proof solution should be provided.
Thanks,
weiguo

From: BESS [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) 
[jorge.raba...@alcatel-lucent.com]
Sent: Saturday, November 21, 2015 3:31
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"  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 vendor

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Haoweiguo]

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-boun...@ietf.org] on behalf of UTTARO, JAMES [ju1...@att.com]
Sent: Saturday, November 21, 2015 1:51
To: 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

+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 f