Re: [bess] Introducing a one-implementation requirement before WG last calls

[Henderickx, Wim (Wim)]

Martin, for me this seems a reasonable way forward




On 14/12/15 10:28, "BESS on behalf of Martin Vigoureux"  wrote:

>WG,
>
>we have reviewed the different comments posted on the list in response 
>to our initial proposal.
>After thinking further about that, we'd like to propose the following as 
>a way forward:
>
>At the same time we issue a Working Group Last Call we would ask for 
>knowledge of existing implementations, and the more details provided at 
>that time, the better.
>In the situation where an implementation would exist we would proceed 
>with submission to IESG.
>In the opposite situation (no implementation exists), we would 
>systematically ask the WG for reasoned opinions regarding whether we 
>should nevertheless proceed with submission to IESG.
>We will gauge consensus on that aspect. In case consensus is in favour 
>of proceeding with submission to IESG we will do so. In the opposite 
>case, we will put the document in a "Waiting for implementation" state 
>until information on an existing implementation is brought to our 
>knowledge or of the WG.
>
>Please share your views on that.
>
>Thank you
>
>M
>
>
>Le 24/11/2015 10:03, Thomas Morin a écrit :
>> Hello everyone,
>>
>> Following the positive feedback received during BESS meeting in Yokohama
>> about introducing a one-implementation requirement in BESS, we propose
>> to do the following for future WG last calls:
>>
>> As a prerequisite before doing a working group last call on a document,
>> the chairs will ask the working group for known implementations of the
>> specifications; a relatively detailed level of information will be
>> required (e.g. "release x.y of solution z shipping date d", "all
>> features implemented", "partial implementation only", etc.) and everyone
>> will be invited to reply (not only co-authors of the specifications);
>> the chairs will then do the working group last call if satisfying
>> information was provided on at least one implementation.
>>
>> We are open for comments on this proposal until December 7th.
>>
>> Martin & Thomas
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>>
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

It also works with VXLAN/GPE btw. On top the solution I outlined is future 
proof as well.

The key question is do people want a native VXLAN/NVGRE solution in the DC 
using existing TOR HW and/or vwitches. This will imply dealing with:
- Global VNID/labels -> driven by current TOR HW (most people will never deploy 
this)
- We have not spoken about the MAC manipulation in all details but will most 
likely require a routing lookup in the TOR and will limit performance in some 
HW TOR(s).

- An implementation on ASBR that only is required for this use case. It will be 
very expensive to carry forward -> the cost versus the benefit is big and if 
people want a uniform data plane VXLAN-GPE is an option which is very close to 
native VXLAN.



On 20/11/15 22:21, "Haoweiguo" <haowei...@huawei.com> wrote:

>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" <bess-boun...@ietf.org 
>on behalf of ju1...@att.com> wrote:
>
>>+1
>>
>>-Original Message-
>>From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
>>Sent: Friday, November 20, 2015 12:19 PM
>>To: EXT - thomas.mo...@orange.com; Lucy yong; Henderickx, Wim (Wim); 
>>bess@ietf.org
>>Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>
>>Lucy,
>>
>>My apologies, I misunderstood.
>>
>>I think we have to accept the fact that we will have to deal with a 
>>multiplicity of different encapsulations in the data plane along a packet's 
>>e2e path and that we should take a more measured approach to deciding how to 
>>deal with this in a general and extensible way before accepting any solutions.
>>
>>Yours Irrespectively,
>>
>>John
>>
>>> -Original Message-
>>> From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
>>> Sent: Friday, November 20, 2015 12:04 PM
>>> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); bess@ietf.org
>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>>
>>> 2015-11-20, John E Drake:
>>> > That presupposes that the group likes either of the two proposed solutions
>>> in your draft.
>>>
>>> John, I think Lucy's "two solutions" was referring to draft-hao-bess-inter-
>>> nvo3-vpn-optionc solution and the 3-label Optionc MPLS/MPLS/UDP solution
>>> described by Wim.
>>>
>>> -Thomas
>>>
>>>
>>>
>>> >
>>> >> -Original Message-
>>> >> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Lucy yong
>>> >> Sent: Friday, November 20, 2015 11:49 AM
>>> >> To: EXT - thomas.mo...@orange.com; Henderickx, Wim (Wim);
>>> >> bess@ietf.org
>>> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>> >>
>>> >> Share my 2 cent.
>>> >>
>>> >> Cloud providers want to tunnel its customer traffic through DC (AS)BR.
>>> >> Option C is a way to realize it. Both solutions summarized by Thomas
>>> >> have no change on WAN VPN side and seamlessly work with WAN VPN
>>> option C.
>>> >> However, to support either solution, DC has to do some enhancement on
>>> >> DC BR or ToR switch, etc, which dictates to different implementations
>>> >> within a DC. Option C pro and con remains regardless what
>>> >> implementation is used in a DC.
>>> >>
>>> >> Two solutions should not coexist in 

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" 
<bess-boun...@ietf.org 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 b

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

[Henderickx, Wim (Wim)]

 OVS/TOR. Unlike Wim's solution, east-west bound traffic
>>>> uses VXLAN encap, while north-south bound traffic uses MPLSoGRE/UDP encap.
>>>> There are two solutions in this draft:
>>>> 1. Using VXLAN tunnel destination IP for stitching at ASBR-d.
>>>> No data plane modification requirements on OVS or TOR switches, only
>>>> hardware changes on ASBR-d. ASBR-d normally is router, it has
>>>> capability to realize the hardware changes. It will consume many IP
>>>> addresses and the IP pool for allocation needs to be configured on
>>>> ASBR-d beforehand.
>>>> 2. Using VXLAN destination UDP port for stitching at ASBR-d.
>>>> Compared with solution 1, less IP address will be consumed for
>>>> allocation. If UDP port range is too large, we can combine with
>>>> solution 1 and 2.
>>>> In this solution, both data plane modification changes are needed at
>>>> OVS/TOR and ASBR-d. ASBR-d also has capability to realize the hardware
>>>> changes. For OVS, it also can realize the data plane changes. For TOR
>>>> switch, it normally can't realize this function.  This solution mainly
>>>> focuses on pure software based overlay network, it has more
>>>> scalability. In public cloud data center, software based overlay
>>>> network is the majority case.
>>>> Whether using solution 1 or 2 depends on the operators real envionment.
>>>> So I think our solution has no flaws, it works fine.
>>>> Thanks,
>>>> weiguo
>>>> 
>>>> From: BESS [bess-boun...@ietf.org <mailto:bess-boun...@ietf.org>] on
>>>> behalf of John E Drake [jdr...@juniper.net <mailto:jdr...@juniper.net>]
>>>> Sent: Wednesday, November 18, 2015 2:49
>>>> To: Henderickx, Wim (Wim); EXT - thomas.mo...@orange.com
>>>> <mailto:thomas.mo...@orange.com>; BESS
>>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>>> Hi,
>>>> I think Wim has conclusively demonstrated that this draft has fatal
>>>> flaws and I don’t support it.  I also agree with his suggestion that
>>>> we first figure out what problem we are trying to solve before solving it.
>>>> Yours Irrespectively,
>>>> John
>>>> From: BESS [mailto:bess-boun...@ietf.org
>>>> <mailto:bess-boun...@ietf.org>] On Behalf Of Henderickx, Wim (Wim)
>>>> Sent: Tuesday, November 17, 2015 12:49 PM
>>>> To: EXT - thomas.mo...@orange.com <mailto:thomas.mo...@orange.com>; BESS
>>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>>> — Snip —
>>>> No, the spec as it is can be implemented in its VXLAN variant with
>>>> existing vswitches (e.g. OVS allows to choose the VXLAN destination
>>>> port, ditto for the linux kernel stack).
>>>> (ToR is certainly another story, most of them not having a flexible
>>>> enough VXLAN dataplane nor support for any MPLS-over-IP.)
>>>> WH> and how many ports simultaneously would they support? For this to
>>>> work every tenant needs a different VXLAN UDP destination port/receive
>>>> port.
>>>> There might be SW elements that could do some of this, but IETF
>>>> defines solutions which should be implemented across the board
>>>> HW/SW/etc. Even if some SW switches can do this, the proposal will
>>>> impose so many issues in HW/data-plane engines that I cannot be behind
>>>> this solution.
>>>> To make this work generically we will have to make changes anyhow.
>>>> Given this, we better do it in the right way and guide the industry to
>>>> a solution which does not imply those complexities. Otherwise we will
>>>> stick with these specials forever with all consequences (bugs, etc).
>>>> - snip -
>>>> From: "thomas.mo...@orange.com
>>>> <mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com
>>>> <mailto:thomas.mo...@orange.com>>" <thomas.mo...@orange.com
>>>> <mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com
>>>> <mailto:thomas.mo...@orange.com>>>
>>>> Organization: Orange
>>>> Date: Tuesday 17 November 2015 at 01:37
>>>> To: Wim Henderickx <wim.henderi...@alcatel-lucent.com
>>>> <mailto:wim.henderi...@alcatel-lucent.com><mailto:wim.henderi...@alcatel-lucent.com
>>>> <mailto:wim.henderi...@alcatel-luc

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

[Henderickx, Wim (Wim)]

ters i've worked with were quite limited in terms of IP addresses 
>> used for tunnel termination and it wasn't that just a simple pool can 
>> be used.
>> [Vincent]: I think the larger VTEP IP address range on ASBR-d has no 
>> limitations. For the hardware on ASBR-d, it has capability to 
>> terminate multiple VXLAN tunnels with arbitrary destination VTEP IP 
>> addresses.
>> Wim's mentions on cases where the Application itself, hosted in a 
>> datacenter, would be part of the option-C interconnect, was dismissed 
>> without much discussion so far, while, if we look in detail at the 
>> type of users which will even consider a complex topology like model-C 
>> its most likely users and operators very familiar with MPLS VPNs in 
>> the WAN. Those type of operators will most likely be very interested 
>> in deploying MPLS or WAN-grade applications (i.e., virtual-routers or 
>> other VNFs) in the DC and thus its highly likely that the interconnect 
>> would not terminate at the NVE itself but rather the TS (the virtual 
>> machine).
>> Also, the use of UDP ports at random would imply quite complex logic 
>> on the ASBR-d IMHO. Im not saying its impossible, but since the 
>> received packet now not only has to be received on a random (though 
>> locally chosen) UDP port and this information preserved in the 
>> pipeline to be able to do the double-tunnel-stitching, it sounds quite 
>> complex. I am sure someone in the list will mention this has already 
>> been implemented somewhere, and I won't argue with that. And let's not 
>> even bring into account what this would do to any DC middlebox that 
>> now has to look at vxlan over almost any random port. We have to go 
>> back to the "is it a 4 or is it a 6 in byte x" heuristics to try to 
>> guess whether the packet is vxlan or just something entirely different 
>> running over IP.
>> [Vincent]: Using NP or multi-core CPU hardware technology, it can be 
>> implemented although deeper packet inspection is needed to perform UDP 
>> port and MPLS stitching.
>> In general I feel the proposed solution seems to be fitting of a 
>> specific use-case which is not really detailed in the draft and does 
>> not describe   a solution that would "elegantly" solve the issues at 
>> hand. It just feels like we're using any available bit-space to stuff 
>> data into places that do not necesarily belong.
>> Yes, MPLS encapsulations on virtual switches are not yet fully 
>> available, and there can be some performance penalty on the TORs, but 
>> the solutions are much cleaner from a control and data plane point of 
>> view. Maybe I'm too utopic.
>> [Vincent]: I think pure VXLAN solution has its scenario, it's general 
>> rather than specific. We can't require all OVS/NVEs support VXLAN + 
>> MPLSoGRE at the same time.
>> Best regards,
>> Diego
>> -
>> Hi,
>> The problem we are trying to solve is to reduce data center 
>> GW/ASBR-d's forwarding table size, the motivation is same as 
>> traditional MPLS VPN option-C. Currently, the most common practise on 
>> ASBR-d is to terminate VXLAN encapsulation, look up local routing 
>> table, and then perform MPLS encapsulation to the WAN network. ASBR-d 
>> needs to maintain all VM's MAC/IP. In Option-C method, only transport 
>> layer information needed to be maintained at GW/ASBR-d, the 
>> scalability will be greatly enhanced. Traditonal Option-C is only for 
>> MPLS VPN network interworking, because VXLAN is becoming pervasive in 
>> data center,  the solution in this draft was proposed for the 
>> heterogeneous network interworking.
>> The advantage of this solution is that only VXLAN encapsulation is 
>> required for OVS/TOR. Unlike Wim's solution, east-west bound traffic 
>> uses VXLAN encap, while north-south bound traffic uses MPLSoGRE/UDP encap.
>> There are two solutions in this draft:
>> 1. Using VXLAN tunnel destination IP for stitching at ASBR-d.
>> No data plane modification requirements on OVS or TOR switches, only 
>> hardware changes on ASBR-d. ASBR-d normally is router, it has 
>> capability to realize the hardware changes. It will consume many IP 
>> addresses and the IP pool for allocation needs to be configured on 
>> ASBR-d beforehand.
>> 2. Using VXLAN destination UDP port for stitching at ASBR-d.
>> Compared with solution 1, less IP address will be consumed for 
>> allocation. If UDP port range is too large, we can combine with 
>> solution 1 and 2.
>> In this solution, both data plane modi

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

[Henderickx, Wim (Wim)]

In-line

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Sunday 15 November 2015 at 13:51
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

Thanks for your detail explanation.

In your solution, MPLSoGRE/oUDP needs to be supported in data center network. 
To support option-c interconnection with WAN network, TORs/NVEs need to add one 
BGP LSP Label in middle layer, so TORs/NVEs need to perform MPLS(VPN Layer) + 
MPLS (BGP LSP Label) + GRE/UDP encapsulation for the traffic from local 
connecting end systems to WAN network. In your solution, GRE/UDP layer is not 
used for transport layer stitching at ASBR-d, traditonal end to end BGP LSP is 
still used for transport layer.

WH> The proposal I made is supportable on NVE/TOR/Applications in the DC and 
this is something that is feasible today without any extra standardisation.


In our solution, VXLAN/NVGRE are two of the focuses, and for VXLAN/NVGRE and 
MPLS VPN network option-c mode interconnection, our solution seems to be the 
only choice. For MPLS Over GRE/UDP, it's the debating point.We propose the same 
interconnecting solution for MPLSoGRE/oUDP, your proposal provides another 
optional solution, i think it works and is good. However, i think an 
independent informational draft only for this point maybe not necessary, we can 
describe it in same single draft which includes all possible solutions for IP 
overlay network(VXLAN/NVGRE/VXLAN-GPE/MPLSoGRE/MPLSoUDP) and MPLS VPN network 
interworking using option-c mode.

WH> I understand what you try to achieve but your proposal requires changes in 
the NVE/TOR as well since the TOR/NVE(s) out there don’t support multiple VXLAN 
ports and on top the whole MAC handling is not described and will require 
additional changes in the NVE/TOR data-planes. So the proposal you have I don’t 
support for being adopted since it requires to drastic changes in the data 
plane elements.


In summary, Option-c mode interconnecting solution between IP overlay network 
and MPLS VPN network is needed for BESS working group, and we should cover all 
possible solutions for all possible mainstream IP overlay encapsulations in 
single draft.

WH> The point is that your proposal requires too drastic impact in the DP and 
this is why I oppose to the draft being adopted. On top I am also questioning 
the real need for an NVE/TOR requiring to support this. Most use case I have 
seen require the application inside the DC consume the 3rd label and as such is 
very well supported with the proposal I suggested.


Thanks,

weiguo

____
From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
Sent: Saturday, November 14, 2015 15:12
To: Linda Dunbar; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Linda, first of all the draft does not say anything about this and 2nd I am not 
confused and 3rd I explained the reasons why this does not fly. So read them

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Friday 13 November 2015 at 23:18
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Wim,

If the draft adds some description to say that the VxLAN header is 
decapsulated, and the MAC header is terminated. It is the inner IP data frames 
to be passed to the MPLS IP-VPNs.

Will it clear out the confusion?

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 8:34 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

In-line

From: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Date: Monday 16 November 2015 at 08:29
To: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc



From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Monday 16 November 2015 at 07:47
To: "bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>, Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Wim,

Henderickx, Wim (Wim) :
VXLAN has a dedicated UDP port and is very clear in the RFC7348

Well, having a port reserved for this use that won't be the default for another 
protocol is one thing, but that does not prevent in itself the same protocol to 
be applied on another range of ports. (Because HTTP specs says port 80 does not 
prevent the URI scheme to allow specifying the port in the URL)

Even reading the VXLAN (Informational) specs, we see room for flexibility wrt 
ports:

  -  Destination Port: IANA has assigned the value 4789 for the
 VXLAN UDP port, and this value SHOULD be used by default as the
 destination UDP port.  Some early implementations of VXLAN have
 used other values for the destination port.  To enable
 interoperability with these implementations, the destination
 port SHOULD be configurable.

I read "4789 SHOULD be used by default" and "SHOULD be configurable".

WH> true but it does not say to use multiple at the same time. My read on this 
is that it allows a non standard port to be used, but not multiple at the same 
time.




Will write something on what I proposed when I get some time, not soon

The co-chair in me needs to ask the following question: should this call for 
adoption be kept on hold until an outline of an alternative solution is 
provided ?

WH> I first want to understand the requirements for this use case and I don’t 
agree to adoption since there are major DP implications in this.


-Thomas






From: Lucy yong 
<<mailto:lucy.y...@huawei.com>lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<<mailto:wim.henderi...@alcatel-lucent.com>wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>,
 Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane. This draft is 
to provide the solution for this use case.

Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate 
to use another UDP port for the VXLAN encapsulation, I don’t see it breaks 
anything. Not sure if hw has this restriction either. Even yes, we can consider 
using UDP source port for this purpose. UDP source port is used for transit 
ECMP and filled by flow entropy, tunnel egress can determine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before sending toward WAN.

Hope we together work out the solution for this valid use case and like to hear 
any better alternative.

Regards,
Lucy





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo 
<<mailto:haowei...@huawei.com>haowei...@huawei.com<mailto:haowei.

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

[Henderickx, Wim (Wim)]

From: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Date: Monday 16 November 2015 at 08:29
To: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

In-line

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Monday 16 November 2015 at 07:37
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

Well, although discussing forever is certainly not the goal, the reasons for 
rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


(more below)



2015-11-13, Henderickx, Wim (Wim):
Thomas, we need a solution that is implementable and will scale in 
control/data-plane. As such the solution I outline is standardised today and 
does not need new extensions in control/data-plane. Hence informational draft 
and can be implemented if there is market demand.

The above argument would fully make sense to me if support MPLS/MPLS/(UDP or 
GRE) was common place in ToRs or vswitches.

With respect to MAC you need to address both directions and does not make sense 
to manage this if it is not required/doe snot add value.

On VXLAN and the Ethernet header: it looks to me that addressing both direction 
is just a matter of documenting in the draft (if not already there) what is the 
expected behavior for VXLAN/NVGRE. But VXLAN and NVGRE are not the only encaps 
proposed in the specs anyway.

Compared to 3-label option C, my understanding is that the added-value is to 
not require the support of an MPLS/MPLS/(UDP or GRE) encap in ToRs and 
vswitches.

The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you something else in mind ?

WH> see above. The draft right now also requires changes in existing TOR/NVE so 
for me all this discussion/debate is void.


WH> and depending on implementation you don’t need to change any of the 
TOR/vswitches.

Does this mean that for some implementations you may not need to change any of 
the TOR/vswitches, but that for some others you may ?

WH> any proposal on the table requires changes, so for me this is not a valid 
discussion

Let me take a practical example : while I can quite easily see how to implement 
the procedures in draft-hao-bess-inter-nvo3-vpn-optionc based on current 
vswitch implementations of VXLAN, the lack of MPLS/MPLS/(UDP, GRE) support in 
commonplace vswitches seems to me as making that alternate solution you suggest 
harder to implement.

WH> I would disagree to this. Tell me which switch/TOR handles multiple UDP 
ports for VXLAN ?


-Thomas







From: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>" 
<<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

I agree on the analysis that this proposal is restricted to implementations 
th

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

[Henderickx, Wim (Wim)]

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 20:42
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Wim,

VXLAN has a dedicated UDP port and is very clear in the RFC7348
[Lucy] This does not prevent other implementation to use VXLAN with other UDP 
port. If someone wants to stick on the dedicate UDP port, we can use the src 
UDP port to achieve that.
WH> they are used for entropy, you seem to be  creating a kludge.
[Lucy1] It works.
WH2> good luck, but does not mean IETF has to adopt it. Mine also works :-)
The proposal I gave works with an IP data plane
[Lucy] I am not clear what is your proposal in this piled thread. Could you 
state or copy/paste again?
WH> look at the archives it is in there
[Lucy1] Is this one?  “If we want to describe a model C VPN interconnect with a 
IP fabric in a DC I recommend to do an informational RFC that describes this 
using VXLAN-GPE, MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS 
label we defined in RFC4364.”

If yes, you suggest NVE to implement MPLSoGRE or MPLSoUDP, to support VXLAN-GPE 
for L3 payload. First of all, using MPLSoGRE or MPLSoUDP for this case, 
requires three labels + GRE/UDP tunnel, huge overhead is introduced here. This 
is very complex in my opinion. Our solution can apply VXLAN-GRE encap. and also 
support MPLSoX encap (5.1.1 and 5.1.2). BTW, this may be not what you suggested.
WH> it is less bits then you proposal and no changes in any CP/DP that is 
standardised today. Where is the complexity? Works today and is deployed in 
many networks

Lucy
Will write something on what I proposed when I get some time, not soon

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane. This draft is 
to provide the solution for this use case.

Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate 
to use another UDP port for the VXLAN encapsulation, I don’t see it breaks 
anything. Not sure if hw has this restriction either. Even yes, we can consider 
using UDP source port for this purpose. UDP source port is used for transit 
ECMP and filled by flow entropy, tunnel egress can determine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before sending toward WAN.

Hope we together work out the solution for this valid use case and like to hear 
any better alternative.

Regards,
Lucy





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data center 
network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is 
restricted only in data center inside domain. For the traffic from data center 
inside to outside,  the inner MAC address(des

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

[Henderickx, Wim (Wim)]

VXLAN has a dedicated UDP port and is very clear in the RFC7348
The proposal I gave works with an IP data plane
Will write something on what I proposed when I get some time, not soon

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane. This draft is 
to provide the solution for this use case.

Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate 
to use another UDP port for the VXLAN encapsulation, I don’t see it breaks 
anything. Not sure if hw has this restriction either. Even yes, we can consider 
using UDP source port for this purpose. UDP source port is used for transit 
ECMP and filled by flow entropy, tunnel egress can determine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before sending toward WAN.

Hope we together work out the solution for this valid use case and like to hear 
any better alternative.

Regards,
Lucy





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data center 
network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is 
restricted only in data center inside domain. For the traffic from data center 
inside to outside,  the inner MAC address(destination MAC is ASBR-d's MAC, src 
MAC is NVE's MAC) in VXLAN/NVGRE will be dropped at ASBR-d, only IP payload 
will continue to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.

This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP network to 
interconnect with MPLS VPN network. In VXLAN-GPE, it supports IP in IP 
encapsulation, so no inner MAC concerns.



Thanks,

weiguo

____________
From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
Sent: Thursday, November 12, 2015 22:33
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 20:15
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Wim,

VXLAN has a dedicated UDP port and is very clear in the RFC7348
[Lucy] This does not prevent other implementation to use VXLAN with other UDP 
port. If someone wants to stick on the dedicate UDP port, we can use the src 
UDP port to achieve that.
WH> they are used for entropy, you seem to be  creating a kludge.
The proposal I gave works with an IP data plane
[Lucy] I am not clear what is your proposal in this piled thread. Could you 
state or copy/paste again?
WH> look at the archives it is in there

Lucy
Will write something on what I proposed when I get some time, not soon

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane. This draft is 
to provide the solution for this use case.

Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate 
to use another UDP port for the VXLAN encapsulation, I don’t see it breaks 
anything. Not sure if hw has this restriction either. Even yes, we can consider 
using UDP source port for this purpose. UDP source port is used for transit 
ECMP and filled by flow entropy, tunnel egress can determine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before sending toward WAN.

Hope we together work out the solution for this valid use case and like to hear 
any better alternative.

Regards,
Lucy





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data center 
network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is 
restricted only in data center inside domain. For the traffic from data center 
inside to outside,  the inner MAC address(destination MAC is ASBR-d's MAC, src 
MAC is NVE's MAC) in VXLAN/NVGRE will be dropped at ASBR-d, only IP payload 
will continue to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.

This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP network to 
interconnect with MPLS VPN network. In VXLAN-GPE, it supports IP in IP 
encapsulation, so no inner MAC concerns.



Thanks,

weiguo


From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
Sent: Thursday, November 12, 2015 22:33
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:

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

[Henderickx, Wim (Wim)]

Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

More in-line.

From: "thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>" 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Friday 13 November 2015 at 17:36
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

2015-11-13, Henderickx, Wim (Wim):
Thomas, we need a solution that is implementable and will scale in 
control/data-plane. As such the solution I outline is standardised today and 
does not need new extensions in control/data-plane. Hence informational draft 
and can be implemented if there is market demand.

The above argument would fully make sense to me if support MPLS/MPLS/(UDP or 
GRE) was common place in ToRs or vswitches.

With respect to MAC you need to address both directions and does not make sense 
to manage this if it is not required/doe snot add value.

On VXLAN and the Ethernet header: it looks to me that addressing both direction 
is just a matter of documenting in the draft (if not already there) what is the 
expected behavior for VXLAN/NVGRE. But VXLAN and NVGRE are not the only encaps 
proposed in the specs anyway.

Compared to 3-label option C, my understanding is that the added-value is to 
not require the support of an MPLS/MPLS/(UDP or GRE) encap in ToRs and 
vswitches.

The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case and depending on implementation you don’t need to 
change any of the TOR/vswitches.


Note that the 3-label option C approach with an MPLS/MPLS/(UDP or GRE) encap 
also requires the introduction of a control plane in the DC (possibly in an 
'SDN' controller) to learn and advertise the middle MPLS label.  Whether one 
consider that the best path to a working solution may also depend on the 
context.

WH> we already have BGP for this.


Best,

-Thomas



From: Thomas Morin 
<<mailto:thomas.mo...@orange.com>thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx 
<<mailto:wim.henderi...@alcatel-lucent.com>wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

I agree on the analysis that this proposal is restricted to implementations 
that supports the chosen encap with non-IANA ports (which may be hard to 
achieve for instance on hardware implementations, as you suggest), or to 
context where managing multiple IPs would be operationally viable.

However, it does not seem obvious to me how the alternative you propose 
[relying on 3-label option C with an MPLS/MPLS/(UDP|GRE) encap] addresses the 
issue of whether the encap behavior is supported or not (e.g. your typical ToR 
chipset possibly may not support this kind of encap,  and even software-based 
switches may not be ready to support that today).

My take is that having different options to adapt to various implementations 
constraints we may have would have value.

(+ one question below on VXLAN...)

-Thomas


2015-11-12, Henderickx, Wim (Wim):
On VXLAN/NVGRE, do you challenge the fact that they would be used with a dummy 
MAC address that would be replaced by the right MAC by a sender based on an ARP 
request when needed ?

Is the above the issue you had in mind about VXLAN and NVGRE ?

WH> yes

I you don't mind me asking : why do you challenge that ?




_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this

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

[Henderickx, Wim (Wim)]

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 21:55
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc



From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Friday, November 13, 2015 2:49 PM
To: Lucy yong; Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: draft-hao-bess-inter-nvo3-vpn-optionc



From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 21:31
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc



Wim,

See [lucy2]

VXLAN has a dedicated UDP port and is very clear in the RFC7348
[Lucy] This does not prevent other implementation to use VXLAN with other UDP 
port. If someone wants to stick on the dedicate UDP port, we can use the src 
UDP port to achieve that.
WH> they are used for entropy, you seem to be  creating a kludge.
[Lucy1] It works.
WH2> good luck, but does not mean IETF has to adopt it. Mine also works :-)
The proposal I gave works with an IP data plane
[Lucy2] IETF does not specify how entropy value is generated yet. It can be 
provided by tunnel egress and tell the ingress.
WH3> the RFC is pretty clear:
— copy —


The UDP source port number

 be calculated using a hash of fields from the inner packet --

 one example being a hash of the inner Ethernet frame's headers.

 This is to enable a level of entropy for the ECMP/load-

 balancing of the VM-to-VM traffic across the VXLAN overlay.

 When calculating the UDP source port number in this manner, it

 is RECOMMENDED that the value be in the dynamic/private port

 range 49152-65535 [RFC6335<https://tools.ietf.org/html/rfc6335>].


— copy --
[Lucy] I am not clear what is your proposal in this piled thread. Could you 
state or copy/paste again?
WH> look at the archives it is in there
[Lucy1] Is this one?  “If we want to describe a model C VPN interconnect with a 
IP fabric in a DC I recommend to do an informational RFC that describes this 
using VXLAN-GPE, MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS 
label we defined in RFC4364.”

If yes, you suggest NVE to implement MPLSoGRE or MPLSoUDP, to support VXLAN-GPE 
for L3 payload. First of all, using MPLSoGRE or MPLSoUDP for this case, 
requires three labels + GRE/UDP tunnel, huge overhead is introduced here. This 
is very complex in my opinion. Our solution can apply VXLAN-GRE encap. and also 
support MPLSoX encap (5.1.1 and 5.1.2). BTW, this may be not what you suggested.
WH> it is less bits then you proposal and no changes in any CP/DP that is 
standardised today. Where is the complexity? Works today and is deployed in 
many networks
[Lucy2] This is not compliant with many DCs’ architecture as Thomas pointed 
out. To make them doing it, it becomes very complex.
WH3> it is even deployed in existing DC(s)
[Lucy3] Yes, if existing DC supports MPLS, it can use your solution. For those 
DCs that do not support MPLS, and already use VXLAN+ip tunnels for intra-DC 
traffic, it is pain for them to implement your solution.  Our draft is to 
provide a solution for those DCs that do not support MPLS.
WH4> works also with VXLAN GPE

Lucy
Will write something on what I proposed when I get some time, not soon

From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane

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

[Henderickx, Wim (Wim)]

termine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before sending toward WAN.

Hope we together work out the solution for this valid use case and like to hear 
any better alternative.

Regards,
Lucy





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data center 
network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is 
restricted only in data center inside domain. For the traffic from data center 
inside to outside,  the inner MAC address(destination MAC is ASBR-d's MAC, src 
MAC is NVE's MAC) in VXLAN/NVGRE will be dropped at ASBR-d, only IP payload 
will continue to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.

This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP network to 
interconnect with MPLS VPN network. In VXLAN-GPE, it supports IP in IP 
encapsulation, so no inner MAC concerns.



Thanks,

weiguo


From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
Sent: Thursday, November 12, 2015 22:33
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

Linda, first of all the draft does not say anything about this and 2nd I am not 
confused and 3rd I explained the reasons why this does not fly. So read them

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Friday 13 November 2015 at 23:18
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Wim,

If the draft adds some description to say that the VxLAN header is 
decapsulated, and the MAC header is terminated. It is the inner IP data frames 
to be passed to the MPLS IP-VPNs.

Will it clear out the confusion?

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 8:34 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Henderickx, Wim (Wim)]

The whole draft complicates any data plane we defined so far and since there is 
simpler solutions I don’t support this proposal.
Arguments have been given as to why.

From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc


Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data center 
network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is 
restricted only in data center inside domain. For the traffic from data center 
inside to outside,  the inner MAC address(destination MAC is ASBR-d's MAC, src 
MAC is NVE's MAC) in VXLAN/NVGRE will be dropped at ASBR-d, only IP payload 
will continue to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.

This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP network to 
interconnect with MPLS VPN network. In VXLAN-GPE, it supports IP in IP 
encapsulation, so no inner MAC concerns.



Thanks,

weiguo



From: BESS [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of 
Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>]
Sent: Thursday, November 12, 2015 22:33
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

I don’t support the adoption of this draft as a WG. There is a major flaw in 
this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. 
VXLAN/NVGRE contains a MAC address and IP-VPNs don’t. The draft does not talk 
about any of this and introduces a lot of complexity for nothing.

If we want to describe a model C VPN interconnect with a IP fabric in a DC I 
recommend to do an informational RFC that describes this using VXLAN-GPE, 
MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS label we defined in 
RFC4364.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

[Henderickx, Wim (Wim)]

Ali, ok I see the ARP cache sync and customer route sync is a benefit. Maybe we 
should make this clearer in the draft.

From: Ali Sajassi <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Friday 6 November 2015 at 15:46
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Jakob Heitz (jheitz)" <jhe...@cisco.com<mailto:jhe...@cisco.com>>, "Jeffrey 
(Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt


Wim,
The draft currently assumes that all the S-PEs are EVPN PEs. However, the 
remote S-PEs really don’t have to be EVPN PEs. They can be IP-VPN PEs and we 
can use evpn-ipvpn-interop draft for the interoperability between the two 
types. On the other hand, the S-PEs in the redundancy group have to be EVPN PEs.

Now, regarding using local edge PIC on the SPEs, it doesn’t give you the 
sych-up of prefixes for VRFs and ARP cache tables. We are talking about a 
single BGP session between the CE and S-PEs. And upon failure, we are talking 
about non-stop forwarding with min. traffic disruption.

-Ali

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Henderickx, Wim (Wim)" 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
Date: Thursday, November 5, 2015 at 1:17 AM
To: "Jakob Heitz (jheitz)" <jhe...@cisco.com<mailto:jhe...@cisco.com>>, 
"Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

Jakob, thx this is clear.
What I see is that the benefits of ESI and Mass withdraw indication are also 
solved based on implementation. By using PW/tunnel indications and local Edge 
PIC on the SPE connected to the access network can enable the same behaviour 
with similar convergence results.


From: "Jakob Heitz (jheitz)" <jhe...@cisco.com<mailto:jhe...@cisco.com>>
Date: Thursday 5 November 2015 at 15:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

The point is that the CE does not realize that it is multihomed.
The access node implements the multihoming, but the CE has only one BGP session 
and one interface.
The APE-SPE connections is an ethernet with the same ESI towards SPE1 and SPE2
The SPEs talk EVPN, using route type 5 to implement an L3VPN service.
This provides the ESI and mass withdrawal that RFC4364 routes do not.

--Jakob

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, November 04, 2015 9:46 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

IF you do Edge-PIC this is optional afais.

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Thursday 5 November 2015 at 14:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

My understanding is that an IP-VPN PE would not be able take advantage of 
“mass-withdraw”?

From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Thursday, November 05, 2015 2:42 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

Is the draft assuming also IP-VPN in the core or only EVPN?
I don’t see a reason for excluding one or another

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Thursday 5 November 2015 at 14:40
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

I did not get that either until Ali confirmed that in the meeting.

I had thought that SPEs were running regular L3VPN 

Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

[Henderickx, Wim (Wim)]

Jakob, thx this is clear.
What I see is that the benefits of ESI and Mass withdraw indication are also 
solved based on implementation. By using PW/tunnel indications and local Edge 
PIC on the SPE connected to the access network can enable the same behaviour 
with similar convergence results.


From: "Jakob Heitz (jheitz)" <jhe...@cisco.com<mailto:jhe...@cisco.com>>
Date: Thursday 5 November 2015 at 15:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

The point is that the CE does not realize that it is multihomed.
The access node implements the multihoming, but the CE has only one BGP session 
and one interface.
The APE-SPE connections is an ethernet with the same ESI towards SPE1 and SPE2
The SPEs talk EVPN, using route type 5 to implement an L3VPN service.
This provides the ESI and mass withdrawal that RFC4364 routes do not.

--Jakob

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, November 04, 2015 9:46 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

IF you do Edge-PIC this is optional afais.

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Thursday 5 November 2015 at 14:44
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

My understanding is that an IP-VPN PE would not be able take advantage of 
“mass-withdraw”?

From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Thursday, November 05, 2015 2:42 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

Is the draft assuming also IP-VPN in the core or only EVPN?
I don’t see a reason for excluding one or another

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Thursday 5 November 2015 at 14:40
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

I did not get that either until Ali confirmed that in the meeting.

I had thought that SPEs were running regular L3VPN (not EVPN) but the ones that 
a CE multi-home to would also use EVPN procedures. Now it looks like there is 
no “regular” L3VPN – everything is EVPN.

Jeffrey

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 05, 2015 2:25 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

Maybe good to clarify in this draft which nodes are involved in EVPN from the 
drawing on p3 in 
https://www.ietf.org/proceedings/94/slides/slides-94-bess-11.pdf?
Did I understood correctly in the meeting that this is required between all 
SPE(s), if so why?

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

[bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

[Henderickx, Wim (Wim)]

Maybe good to clarify in this draft which nodes are involved in EVPN from the 
drawing on p3 in 
https://www.ietf.org/proceedings/94/slides/slides-94-bess-11.pdf?
Did I understood correctly in the meeting that this is required between all 
SPE(s), if so why?

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

Re: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

[Henderickx, Wim (Wim)]

Is the draft assuming also IP-VPN in the core or only EVPN?
I don’t see a reason for excluding one or another

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Thursday 5 November 2015 at 14:40
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

I did not get that either until Ali confirmed that in the meeting.

I had thought that SPEs were running regular L3VPN (not EVPN) but the ones that 
a CE multi-home to would also use EVPN procedures. Now it looks like there is 
no “regular” L3VPN – everything is EVPN.

Jeffrey

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 05, 2015 2:25 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] draft-sajassi-bess-evpn-l3vpn- multihoming-00.txt

Maybe good to clarify in this draft which nodes are involved in EVPN from the 
drawing on p3 in 
https://www.ietf.org/proceedings/94/slides/slides-94-bess-11.pdf?
Did I understood correctly in the meeting that this is required between all 
SPE(s), if so why?

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

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

[Henderickx, Wim (Wim)]

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

https://datatracker.ietf.org/ipr/2697/
https://datatracker.ietf.org/ipr/2696/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] IPR related to draft-morin-bess-mvpn-fast-failover

[Henderickx, Wim (Wim)]

Attached is the IPR we disclosed recetnly related to this draft:

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


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

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

[Henderickx, Wim (Wim)]

We found out that there exist IPR related to this draft. We are in the process 
of disclosing this asap.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] draft-ietf-bess-evpn-vpws

[Henderickx, Wim (Wim)]

My comment in the meeting related to the entropy label is that the indication 
in the new EVPN Layer 2 attributes extended community is not necessary since 
the LSP(s) signalling protocols (LDP/RSVP – IGPs/BGP being extended as we 
speak) are signalling this capability and can be used to know if the egress PE 
supports entropy label or not.
Flow labels on the other hand are required here.

Now is this attribute only used in VPWS or can it be used across other EVPN 
services. Issue is that flow label is hard to identify in multipoint EVPN 
services due to the use of SHG labels, etc. As such it is best to rely only on 
entropy label as a whole for multipoint services in EVPN. My 2 cents on the 
later.



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

Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming

[Henderickx, Wim (Wim)]

Not aware of IPR related to this draft




On 12/06/15 17:09, BESS on behalf of Martin Vigoureux bess-boun...@ietf.org 
on behalf of martin.vigour...@alcatel-lucent.com wrote:

Hello

this email starts a Working Group Last Call on
http://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming
which is considered mature and ready for a last 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 June the 26th.

*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to this draft, 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* please respond 
to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be moved forward until a response has been received 
from each author and contributor.

If you are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.

Please note that IPR has already been disclosed for this document:
https://datatracker.ietf.org/ipr/1809/

Thank you
MT

___
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] ARP ND draft

[Henderickx, Wim (Wim)]

To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6.
I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
There is anycast at IPv4 level for sure but I am not ware this is supported at 
arp level.

From: Henderickx, Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto:bess@ietf.org, 
Jorge Rabadan
Subject: Re: [bess] ARP ND draft

At interface level you get dad in most stacks I know.

Sent from my iPhone

On 30 Mar 2015, at 06:45, Robert Raszuk 
rob...@raszuk.netmailto:rob...@raszuk.net wrote:

Hi Wim,

What makes you say that in IPv4 there is no anycast ? All anycase I have played 
so far is IPv4 :)

Cheers,
r.

On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) 
wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 
wrote:
We will update the draft to highlight the IPv6 anycast behaviour better as 
pointed out by RObert. In IPv4 there is no anycast behaviour and as such there 
should be one option possible.



On 30/03/15 04:59, Antoni Przygienda 
antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote:

Yes, but of course I brought it up to show that 'the last one simply wins' as 
suggested by the draft is not enough IMO. A good architecture should probably 
keep track of what it served as answer and when the answer is invalid or a 
new, better one exists, provide a GARP.

As well, when PE2 sends a newer MAC it may not be a good strategy to serve a 
GARP if PE1's MAC has already been offered. That could lead IMO to e.g. 
gateway chasing problems.

--- tony


There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain


 -Original Message-
 From: Henderickx, Wim (Wim) 
 [mailto:wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com]
 Sent: Thursday, March 26, 2015 6:01 AM
 To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
 Cc: bess@ietf.orgmailto:bess@ietf.org
 Subject: Re: [bess] ARP ND draft

 For this case you should sent a GARP with the new MAC/IP




 On 25/03/15 18:56, Antoni Przygienda 
 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com
 wrote:

   b)It is worth explaining what is suggested behavior if eVPN
   advertises the same IP with multiple MACs and what happens when
   e.g. the served MAC vanishes
  
  Doesn't the EVPN RFC already stating that the routes would be
  withdrawn in that case?
 
 The scenario I had in mind was when eVPN PE receives
 
 From PE2  IP1/M1  and  later
 From PE3  IP1/M2
 
 while having answered with IP1/M1 per proxy alrady. Additionally, in
 such situation ends up seeing
 
 From PE2   IP1/no MAC
 
 So the answer it gave is not valid anymore all of a sudden.
 
 --- tony
___
BESS mailing list
BESS@ietf.orgmailto: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] ARP ND draft

[Henderickx, Wim (Wim)]

Found it https://www.ietf.org/rfc/rfc1546.txt seems to specify it.

From: Henderickx, Wim Henderickx
Date: Monday 30 March 2015 08:10
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto:bess@ietf.org, 
Jorge Rabadan
Subject: Re: [bess] ARP ND draft

To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6.
I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
There is anycast at IPv4 level for sure but I am not ware this is supported at 
arp level.

From: Henderickx, Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto:bess@ietf.org, 
Jorge Rabadan
Subject: Re: [bess] ARP ND draft

At interface level you get dad in most stacks I know.

Sent from my iPhone

On 30 Mar 2015, at 06:45, Robert Raszuk 
rob...@raszuk.netmailto:rob...@raszuk.net wrote:

Hi Wim,

What makes you say that in IPv4 there is no anycast ? All anycase I have played 
so far is IPv4 :)

Cheers,
r.

On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) 
wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 
wrote:
We will update the draft to highlight the IPv6 anycast behaviour better as 
pointed out by RObert. In IPv4 there is no anycast behaviour and as such there 
should be one option possible.



On 30/03/15 04:59, Antoni Przygienda 
antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote:

Yes, but of course I brought it up to show that 'the last one simply wins' as 
suggested by the draft is not enough IMO. A good architecture should probably 
keep track of what it served as answer and when the answer is invalid or a 
new, better one exists, provide a GARP.

As well, when PE2 sends a newer MAC it may not be a good strategy to serve a 
GARP if PE1's MAC has already been offered. That could lead IMO to e.g. 
gateway chasing problems.

--- tony


There are basically two types of people. People who accomplish things, and 
people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain


 -Original Message-
 From: Henderickx, Wim (Wim) 
 [mailto:wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com]
 Sent: Thursday, March 26, 2015 6:01 AM
 To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
 Cc: bess@ietf.orgmailto:bess@ietf.org
 Subject: Re: [bess] ARP ND draft

 For this case you should sent a GARP with the new MAC/IP




 On 25/03/15 18:56, Antoni Przygienda 
 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com
 wrote:

   b)It is worth explaining what is suggested behavior if eVPN
   advertises the same IP with multiple MACs and what happens when
   e.g. the served MAC vanishes
  
  Doesn't the EVPN RFC already stating that the routes would be
  withdrawn in that case?
 
 The scenario I had in mind was when eVPN PE receives
 
 From PE2  IP1/M1  and  later
 From PE3  IP1/M2
 
 while having answered with IP1/M1 per proxy alrady. Additionally, in
 such situation ends up seeing
 
 From PE2   IP1/no MAC
 
 So the answer it gave is not valid anymore all of a sudden.
 
 --- tony
___
BESS mailing list
BESS@ietf.orgmailto: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] EVPN Draft Comments

[Henderickx, Wim (Wim)]

To add to what John said, the remote NH proposal would be less efficient
than the EVPN draft in terms of BGP messaging.

On 03/02/15 13:47, John E Drake jdr...@juniper.net wrote:

Sue,

I think we have a tempest in a teapot.

The EVPN Overlay draft
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00) needs to
indicate different data plane encapsulations and initially we had
proposed using the RFC 5512 extended community for this.

Subsequently, Ali and Keyur proposed using Keyur's remote next hop draft
which you reference, below, because it also specifies data plane
encapsulations.  Ultimately, and w/ Yakov's assistance, we re-affirmed
our decision to use the RFC 5512 extended community and I believe that
the necessary additional code points have been allocated.

So to recap, we have no interest in or any need for remote next hops.

Yours Irrespectively,

John

 -Original Message-
 From: Susan Hares [mailto:sha...@ndzh.com]
 Sent: Tuesday, February 03, 2015 6:13 AM
 To: 'Ali Sajassi (sajassi)'; 'Russ White'; John E Drake; 'Rabadan,
Jorge (Jorge)'
 Cc: bess@ietf.org
 Subject: RE: [bess] EVPN Draft Comments
 
 Ali:
 
 I would be glad to inform Yakov, Keyur and Pedro of these issues I
perceive
 with the draft.  It would be delightful to see why they thought your
structure
 was reasonable.
 
 Yakov and Pedro have not been in active discussions regarding IDR
next-hop
 mechanisms in the last year.  For 2014, Keyur and others on the IDR
list have
 been discussing new next-hop drafts.  I suggest you consult the IDR
mail list
 for these discussion regarding that the following draft.
 
 https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/
 
 At:
 http://www.ietf.org/mail-archive/web/idr/current/msg13658.html  (my
 comments)
 http://www.ietf.org/mail-archive/web/idr/current/msg13689.html  (Eric
 Rosen's)
 
 
 Eric Rosen raises some very useful points on this specific draft, and
the
 design of reliable next-hop mechanism.  It is Eric's comments and others
 that have caused me to start a conversation regarding this topic.
 
  Please note I lead this discussion on the EVPN with a pragmatic note.
 If
 the EVPN is deployed and implemented by 2 vendors (as we require for IDR
 WC
 LC of protocol standards), then it should be standard rather than sit
on the
 shelf.  We can consider a revised BGP mechanism in the future, but it
must
 be deemed more efficient or better scaling.
 
 Best wishes,
 
 Sue
 
 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi
(sajassi)
 Sent: Tuesday, February 03, 2015 2:52 AM
 To: Susan Hares; 'Russ White'; 'John E Drake'; 'Rabadan, Jorge (Jorge)'
 Cc: bess@ietf.org
 Subject: Re: [bess] EVPN Draft Comments
 
 
 Sue,
 
 On 2/2/15, 9:25 PM, Susan Hares sha...@ndzh.com wrote:
 
 Russ and John:
 
 I have concerns about the issues Russ has raised as well as other
concerns
 regarding the EVPN.   As I mentioned at the last IETF's BESS meeting,
John
 Scudder and I have been discussing the next-hop issues in BESS drafts
 to see
 if IDR could create better BGP mechanism for the future BESS drafts.
In
 this review, it became clear that several of the mechanism in EVPN
could
 have been done in a simpler and more elegant way in BGP.It was not
the
 first EVPN specification that made this clear, but the review of
 several drafts.
 
 If there are any specific suggestions, I¹d like to hear it. At the IETF
BESS
 meeting, I believe I didn¹t hear anything specific.
 
 
 
 I am pragmatic.  It is auth-48. If the EVPN  is widely shipping and
 deployed in networks, it is unlikely that the vendors or providers want
 to change it at this point.  They have coded the EVPN solution.  My
 agreement with the BESS chairs was this investigation was not to derail
 their work.
 
 It should be noted that this draft was written in collaboration with
our BGP
 colleagues: Yakov, Pedro, and Keyur right from the beginning. So, if
there
 are any issues, I am sure not just me but these folks would also be
 interested in hearing them.
 
 Regards,
 Ali
 
 
 
 If you are interested, I would appreciate a phone conversation with
 both of you.  John Scudder indicated that John Drake would be the best
 person within Juniper to discuss this point with.  Perhaps we can talk
 about all of these issues.  Since it is a BGP mechanism, perhaps if we
 create a more elegant BGP mechanism it could be considered as a bis
 for EVPN drafts.  I suspect EVPN use is only going to grow, and better
 BGP mechanisms usually mean more efficient and scalable code.
 
 Best wishes,
 
 Sue Hares
 
 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Russ White
 Sent: Monday, February 02, 2015 7:12 PM
 To: 'John E Drake'; 'Rabadan, Jorge (Jorge)'
 Cc: bess@ietf.org
 Subject: Re: [bess] EVPN Draft Comments
 
 
  [JD]  What RFC 7432 actually says is:  The MAC Address Length field
  is in bits, and it is set to 48.
  MAC address length values other than 48 bits 

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree

[Henderickx, Wim (Wim)]

Support as a co-author, not aware of IPR related to this draft

On 02/02/15 15:02, Thomas Morin thomas.mo...@orange.com wrote:

Hello working group,

This email starts a two-week poll on adopting
draft-sajassi-bess-evpn-etree-00 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **February 16th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, 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 please
respond to this email and indicate whether or not you are aware of any
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please
explicitly respond only if you are aware of any IPR that has not yet
been disclosed in conformance with IETF rules.

Thank you,

Martin  Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-sajassi-bess-evpn-etree

___
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] Poll for adoption: draft-rabadan-bess-dci-evpn-overlay

[Henderickx, Wim (Wim)]

+ support adoption of the draft as WG

On 05/12/14 17:31, Henderickx, Wim (Wim)
wim.henderi...@alcatel-lucent.com wrote:

I am not aware of IPR related to this draft


Jorge

-Original Message-
From: Thomas Morin thomas.mo...@orange.com
Organization: Orange
Date: Friday, December 5, 2014 at 5:13 AM
To: bess@ietf.org bess@ietf.org
Cc: draft-rabadan-bess-dci-evpn-over...@tools.ietf.org
draft-rabadan-bess-dci-evpn-over...@tools.ietf.org
Subject: [bess]  Poll for adoption: draft-rabadan-bess-dci-evpn-overlay

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-dci-evpn-overlay [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **December 19th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, 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* please
respond to this email and indicate whether or not you are aware of any
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please
explicitly respond only if you are aware of any IPR that has not yet
been disclosed in conformance with IETF rules.

Thank you,

Martin  Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-rabadan-bess-dci-evpn-overlay

___
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] 答复: Flowspec for L2VPN and E-VPN

[Henderickx, Wim (Wim)]

I would do the separate AFI/SAFI when we add L2. Customers deployed
Ipv4/Ipv6 with VPN or without VPNs already so we should not change this.

On 19/11/14 03:56, Haoweiguo haowei...@huawei.com wrote:

Hi Bertrand,
Yes, unified fs safi is a good design, the fs safi can be used for all
kinds of BGP fs, like IPv4,VPNv4,IPv6,VPNv6, layer
2(EVPN,PBB-EVPN,TRILL-EVPN,NVO3-EVPN,VPLS,PBB-VPLS.etc).
Currently IPV4 and VPNv4 flowspec has already been defined in RFC [5575].
IPv6 and VPNv6 flowspec definition is a WG draft.
If we prefer unified fs safi, should layer 2 fs and IPv6 fs merge into
one single draft or evolve separately? I would like to hear WG co-chairs
and experts opinion on this point.
Thanks
weiguo

From: Bertrand Duvivier (bduvivie) [bduvi...@cisco.com]
Sent: Friday, November 14, 2014 16:00
To: Henderickx, Wim (Wim)
Cc: Haoweiguo; Thomas Morin; BESS; IDR Chairs
Subject: Re: [bess] 答复:  Flowspec for L2VPN and E-VPN

+1... Would to avoid to see multiplication of fs safi.

Sent from iPAD


 On Nov 14, 2014, at 01:15, Henderickx, Wim (Wim)
wim.henderi...@alcatel-lucent.com wrote:

 If we define a new things I prefer to address the wider issue and
include
 L2 in that.

 On 13/11/14 14:13, Haoweiguo haowei...@huawei.com wrote:

 Hi Wim,
 Allocating different AFI/SAFI(s) for each flow spec application is a
 applicable solution. Theoretically, unified mechanism for all flowspec
 can be designed, but it maybe a more harder work in IDR.
 Thanks
 weiguo

 
 发件人: BESS [bess-boun...@ietf.org] 代表 Henderickx, Wim (Wim)
 [wim.henderi...@alcatel-lucent.com]
 发送时间: 2014年11月14日 7:55
 收件人: Thomas Morin; BESS
 抄送: IDR Chairs
 主题: Re: [bess] Flowspec for L2VPN and E-VPN

 As I stated in the IDR meeting my observation is that we require to
many
 AFI/SAFI(s) for all flow spec functions. Flow spec in general is
providing
 match criteria¹s with related actions. Given the proposal on Flowspec
for
 L2 is new we should look at the bigger picture.
 In My view we need a mechanism in BGP to advertise Flowspec match
 criteria¹s with related actions and they should cover L2/L3-IPv4/IPv6.

 On 13/11/14 13:44, Thomas Morin thomas.mo...@orange.com wrote:

 Hi WG,

 A heads up...

 These two drafts relate to BESS and thus may be of interest to us:
 - draft-hao-idr-flowspec-l2vpn
 http://tools.ietf.org/html?draft=draft-hao-idr-flowspec-l2vpn-01 (on
 idr agenda, being presented right now)
 - draft-hao-idr-flowspec-evpn
 https://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00

 Best,

 -Thomas


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

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

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

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