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

[Martin Vigoureux <[e-mail]>]

Lucy,

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

-m

Le 20/11/2015 21:36, Lucy yong a écrit :
> Martin,
>
> Sorry not to express my mind precisely.
>
> I mean to say, debating which solution is a better solution here does not make a sense. There is no need for the two solutions interwork.
>
> Regards,
> Lucy
>
> -----Original Message-----
> From: BESS [mailto:[e-mail]] On Behalf Of Martin Vigoureux
> Sent: Friday, November 20, 2015 2:13 PM
> To: [e-mail]
> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>
> Lucy,
>
> there is no such thing as voting in IETF WGs And I haven't seen anything like voting as part of this discussion.
>
> Thank you
> Martin
>
> Le 20/11/2015 20:57, Lucy yong a écrit :
>> IMHO: voting on this thread does not make a sense. Both solutions will work and scales.
>>
>> Lucy
>>
>> -----Original Message-----
>> From: Rabadan, Jorge (Jorge) [mailto:[e-mail]]
>> Sent: Friday, November 20, 2015 1:32 PM
>> To: UTTARO, JAMES; John E Drake; EXT - [e-mail]; Lucy
>> yong; Henderickx, Wim (Wim); [e-mail]
>> 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" <[e-mail] on behalf of [e-mail]> wrote:
>>
>>> +1
>>>
>>> -----Original Message-----
>>> From: BESS [mailto:[e-mail]] On Behalf Of John E Drake
>>> Sent: Friday, November 20, 2015 12:19 PM
>>> To: EXT - [e-mail]; Lucy yong; Henderickx, Wim (Wim);
>>> [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]]
>>>> Sent: Friday, November 20, 2015 12:04 PM
>>>> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); [e-mail]
>>>> 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:[e-mail]] On Behalf Of Lucy yong
>>>>>> Sent: Friday, November 20, 2015 11:49 AM
>>>>>> To: EXT - [e-mail]; Henderickx, Wim (Wim);
>>>>>> [e-mail]
>>>>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>>>>>
>>>>>> Share my 2 cent.
>>>>>>
>>>>>> Cloud providers want to tunnel its customer traffic through DC (AS)BR.
>>>>>> Option C is a way to realize it. Both solutions summarized by
>>>>>> Thomas have no change on WAN VPN side and seamlessly work with WAN
>>>>>> VPN
>>>> option C.
>>>>>> However, to support either solution, DC has to do some enhancement
>>>>>> on DC BR or ToR switch, etc, which dictates to different
>>>>>> implementations within a DC. Option C pro and con remains
>>>>>> regardless what implementation is used in a DC.
>>>>>>
>>>>>> Two solutions should not coexist in one DC (does not make a
>>>>>> sense), but it does not matter if one DC operator prefers to use
>>>>>> one solution and another DC prefers to use another solution. Since
>>>>>> there are many cloud providers today, it is worth for the WG to
>>>>>> document both solutions and point out the implementation
>>>>>> requirements on impacted components. Then, up to vendors and
>>>>>> operators to select a solution for
>>>> their DC.
>>>>>>
>>>>>> It does not make a sense for us to vote which solution is better
>>>>>> here because a better solution for a DC depends on many factors.
>>>>>>
>>>>>>
>>>>>> Lucy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: BESS [mailto:[e-mail]] On Behalf Of
>>>>>> [e-mail]
>>>>>> Sent: Friday, November 20, 2015 3:02 AM
>>>>>> To: Henderickx, Wim (Wim); [e-mail]
>>>>>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
>>>>>>
>>>>>> 2015-11-19, Henderickx, Wim (Wim):
>>>>>>> WH> I vote for a an evolution of switches/TORs that have proper
>>>>>>> support for this. I hope some HW vendors of TOR chips shime in,
>>>>>>> but I am told the MPLS solution is possible in the next
>>>>>>> generation chips they are working on.
>>>>>>
>>>>>> Well, it looks like the key questions are:
>>>>>> - when would ToR chips support MPLS/MPLS/UDP ?  (the generation
>>>>>> that has been released recently but not present in most shipping
>>>>>> ToRs yet, the next one ?)
>>>>>> - do we want an interim VXLAN-based solution ? (that will involve
>>>>>> at best a performance penalty with existing chips, and at worse
>>>>>> impossible to implement -- we haven't seen clear information in
>>>>>> this
>>>>>> thread)
>>>>>>
>>>>>> -Thomas
>>>>>>
>>>>>>
>>>>>>>> Zhuangshunwan  :
>>>>>>>>>
>>>>>>>>> Hi Diego,
>>>>>>>>>
>>>>>>>>> Thanks for your comments. Pls see inline with [Vincent].
>>>>>>>>>
>>>>>>>>> Vincent
>>>>>>>>>
>>>>>>>>> *发件人:*BESS [mailto:[e-mail]] *代表 *Diego Garcia
>>>>>> del Rio
>>>>>>>>> *发送时间:*2015年11月18日14:25 *收件人:*[e-mail] *主题
>>>>>> :*Re: [bess]
>>>>>>>>> draft-hao-bess-inter-nvo3-vpn-optionc
>>>>>>>>>
>>>>>>>>> Some comments from my side, I think the draft makes quite a few
>>>>>>>>> assumptions on specific implementation details that are way too
>>>>>>>>> general to be considered widely available. Most of the TOR
>>>>>>>>> devices today already pay a double-pass penalty when doing
>>>>>>>>> routing of traffic in/out of vxlan-type tunnels. Only the
>>>>>>>>> newest generation can route into tunnels without additional
>>>>>>>>> passes. And are definitively limited in being able to arbitrary
>>>>>>>>> select UDP ports on a per tunnel basis. In fact, most are even
>>>>>>>>> limited at using more than one VNID per "service" of sorts.
>>>>>>>>> [Vincent]: Yes, the new generation BCM chipset has already
>>>>>>>>> supported VXLAN routing
>>>> without
>>>>>>>>> additional passes. For OVS/TOR, VXLAN encapsulation is more
>>>>>>>>> popular than MPLSoGRE/UDP, and has better performance. The
>>>>>>>>> IP-addressed based implementation which would, I assume, imply
>>>>>>>>> assigning one or more CIDRs to a loopback interface on the
>>>>>>>>> ASBR-d is also quite arbitrary and does not seem like a
>>>>>>>>> technically "clean" solution. (besides burning tons of IPs). As
>>>>>>>>> a side-note, most PE-grade routers i've worked with were quite
>>>>>>>>> limited in terms of IP addresses used for tunnel termination
>>>>>>>>> and it wasn't that just a simple pool can be used. [Vincent]: I
>>>>>>>>> think the larger VTEP IP address range on ASBR-d has no limitations.
>>>>>>>>> For the hardware on ASBR-d, it has capability to terminate
>>>>>>>>> multiple VXLAN tunnels with arbitrary destination VTEP IP
>>>>>>>>> addresses. Wim's mentions on cases where the Application
>>>>>>>>> itself, hosted in a datacenter, would be part of the option-C
>>>>>>>>> interconnect, was dismissed without much discussion so far,
>>>>>>>>> while, if we look in detail at the type of users which will
>>>>>>>>> even consider a complex topology like model-C its most likely
>>>>>>>>> users and operators very familiar with MPLS VPNs in the WAN.
>>>>>>>>> Those type of operators will most likely be very interested in
>>>>>>>>> deploying MPLS or WAN-grade applications (i.e., virtual-routers
>>>>>>>>> or other
>>>>>>>>> VNFs) in the DC and thus its highly likely that the
>>>>>>>>> interconnect would not terminate at the NVE itself but rather
>>>>>>>>> the TS (the virtual machine). Also, the use of UDP ports at
>>>>>>>>> random would imply quite complex logic on the ASBR-d IMHO. Im
>>>>>>>>> not saying its impossible, but since the received packet now
>>>>>>>>> not only has to be received on a random (though locally chosen)
>>>>>>>>> UDP port and this information preserved in the pipeline to be
>>>>>>>>> able to do the double-tunnel-stitching, it sounds quite
>>>>>>>>> complex. I am sure someone in the list will mention this has
>>>>>>>>> already been implemented somewhere, and I won't argue with
>>>>>>>>> that. And let's not even bring into account what this would do
>>>>>>>>> to any DC middlebox that now has to look at vxlan over almost
>>>>>>>>> any random port. We have to go back to the "is it a 4 or is it
>>>>>>>>> a 6 in byte x" heuristics to try to guess whether the packet is
>>>>>>>>> vxlan or just something entirely different running over IP.
>>>>>>>>> [Vincent]: Using NP or multi-core CPU hardware technology, it
>>>>>>>>> can be implemented although deeper packet inspection is needed
>>>>>>>>> to perform UDP port and MPLS stitching. In general I feel the
>>>>>>>>> proposed solution seems to be fitting of a specific use-case which is not really detailed
>>>>>>>>> in the draft and does not describe   a solution that would
>>>>>>>>> "elegantly" solve the issues at hand. It just feels like we're
>>>>>>>>> using any available bit-space to stuff data into places that do
>>>>>>>>> not necesarily belong. Yes, MPLS encapsulations on virtual
>>>>>>>>> switches are not yet fully available, and there can be some
>>>>>>>>> performance penalty on the TORs, but the solutions are much
>>>>>>>>> cleaner from a control and data plane point of view. Maybe I'm
>>>>>>>>> too utopic. [Vincent]: I think pure VXLAN solution has its
>>>>>>>>> scenario, it's general rather than specific. We can't require
>>>>>>>>> all OVS/NVEs support VXLAN + MPLSoGRE at the same time. Best
>>>>>>>>> regards, Diego
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> ---
>>>>>>>>> --
>>>>>>>>> -------------
>>>>>>>>>
>>>>>>>>>
>>>>>> Hi,
>>>>>>>>> The problem we are trying to solve is to reduce data center
>>>>>>>>> GW/ASBR-d's forwarding table size, the motivation is same as
>>>>>>>>> traditional MPLS VPN option-C. Currently, the most common
>>>>>>>>> practise on ASBR-d is to terminate VXLAN encapsulation, look up
>>>>>>>>> local routing table, and then perform MPLS encapsulation to the
>>>>>>>>> WAN
>>>> network.
>>>>>>>>> ASBR-d needs to maintain all VM's MAC/IP. In Option-C method,
>>>>>>>>> only transport layer information needed to be maintained at
>>>>>>>>> GW/ASBR-d, the scalability will be greatly enhanced. Traditonal
>>>>>>>>> Option-C is only for MPLS VPN network interworking, because
>>>>>>>>> VXLAN is
>>>> becoming
>>>>>>>>> pervasive in data center, the solution in this draft was
>>>>>>>>> proposed for the heterogeneous network interworking. The
>>>>>>>>> advantage of this solution is that only VXLAN encapsulation is required for OVS/TOR.
>>>>>>>>> Unlike Wim's solution, east-west bound traffic uses VXLAN
>>>>>>>>> encap, while north-south bound traffic uses MPLSoGRE/UDP encap.
>>>>>>>>> There
>>>> are
>>>>>>>>> two solutions in this draft: 1. Using VXLAN tunnel destination
>>>>>>>>> IP for stitching at ASBR-d. No data plane modification
>>>>>>>>> requirements on OVS or TOR switches, only hardware changes on
>>>>>>>>> ASBR-d. ASBR-d normally is router, it has capability to realize
>>>>>>>>> the hardware changes. It will consume many IP addresses and the
>>>>>>>>> IP pool for allocation needs to be configured on ASBR-d
>>>>>>>>> beforehand. 2. Using VXLAN destination UDP port for stitching
>>>>>>>>> at ASBR-d. Compared with solution 1, less IP address will be
>>>>>>>>> consumed for allocation. If UDP port range is too large, we can combine with solution 1 and 2.
>>>>>>>>> In this solution, both data plane modification changes are
>>>>>>>>> needed at OVS/TOR and ASBR-d. ASBR-d also has capability to
>>>>>>>>> realize the hardware changes. For OVS, it also can realize the
>>>>>>>>> data plane changes. For TOR switch, it normally can't realize this function.
>>>>>>>>> This solution mainly focuses on pure software based overlay
>>>>>>>>> network, it has more scalability. In public cloud data center,
>>>>>>>>> software based overlay network is the majority case. Whether
>>>>>>>>> using solution 1 or 2 depends on the operators real envionment.
>>>>>>>>> So I think our solution has no flaws, it works fine.
>>>>>>>>> Thanks, weiguo ________________________________ From: BESS
>>>>>>>>> [[e-mail] <mailto:[e-mail]>] on
>>>>>>>>> behalf of John E Drake [[e-mail]
>>>>>>>>> <mailto:[e-mail]>]
>>>>>>>>> Sent: Wednesday, November 18, 2015 2:49 To: Henderickx, Wim
>>>> (Wim);
>>>>>>>>> EXT - [e-mail]
>>>> <mailto:[e-mail]>;
>>>>>> 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:[e-mail]
>>>>>>>>> <mailto:[e-mail]>] On Behalf Of Henderickx, Wim
>>>>>>>>> (Wim) Sent: Tuesday, November 17, 2015
>>>>>>>>> 12:49 PM To: EXT - [e-mail]
>>>>>>>>> <mailto:[e-mail]>; 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:
>>>>>>>>> "[e-mail]
>>>>>>>>>
>>>>>>
>>>> <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>" <[e-mail]
>>>>>>>>>
>>>>>>
>>>> <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>> Organization: Orange Date:
>>>>>>>>> Tuesday 17 November 2015 at 01:37 To: Wim Henderickx
>>>>>>>>> <[e-mail]
>>>>>>>>> <mailto:wim.henderickx@alcatel-
>>>>>> lucent.com><mailto:wim.henderickx@alc
>>>>>>>>> atel-lucent.com
>>>>>>>>>
>>>>>>>>>
>>>>>> <mailto:[e-mail]>>>, BESS <[e-mail]
>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>> Subject: Re: [bess]
>>>>>>>>> draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, WG, 2015-11-16,
>>>>>>>>> Henderickx, Wim (Wim): 2015-11-13, Henderickx, Wim (Wim):
>>>> Thomas,
>>>>>> we
>>>>>>>>> can discuss forever and someone need to describe requirements,
>>>>>>>>> but the current proposal I cannot agree to for the reasons explained.
>>>>>>>>> TM> Well, although discussing forever is certainly not the
>>>>>>>>> TM> goal, the
>>>>>>>>> reasons for rejecting a proposal need to be thoroughly understood.
>>>>>>>>> WH> my point is what is the real driver for supporting a plain
>>>>>>>>> WH> VXLAN
>>>>>>>>> data-plane here, the use cases I have seen in this txt is
>>>>>>>>> always where an application behind a NVE/TOR is demanding
>>>>>>>>> option c, but none of the NVE/TOR elements.
>>>>>>>>> My understanding is that the applications  are contexts where
>>>>>>>>> overlays are present is when workloads (VMs or baremetal) need
>>>>>>>>> to be interconnected with VPNs. In these contexts, there can be
>>>>>>>>> reasons to want Option C to reduce the state on ASBRs. In these
>>>>>>>>> context, its not the workload (VM or baremetal) that would
>>>>>>>>> typically handle VRFs, but really the vswitch or ToR. WH2> can
>>>>>>>>> it not
>>>> be all cases:
>>>>>>>>> TOR/vswitch/Application. I would make the solution flexible to
>>>>>>>>> support all of these not? 2015-11-13, Henderickx, Wim (Wim):
>>>>>>>>> TM> The right trade-off to make may in fact depend on whether
>>>>>>>>> you
>>>> prefer:
>>>>>>>>> (a) a new dataplane stitching behavior on DC ASBRs (the
>>>>>>>>> behavior specified in this draft) or
>>>>>>>>> (b) an evolution of the encaps on the vswitches and ToRs to
>>>>>>>>> support MPLS/MPLS/(UDP or GRE) WH> b depends on the use case I
>>>>>>>>> don't get what you mean by "b depends on the use case". WH> see
>>>> my
>>>>>>>>> above comment. If the real use case is an application behind
>>>>>>>>> NVE/TOR requiring model C, than all the discussion on impact on
>>>>>>>>> NVE/TOR is void. As such I want to have a discussion on the
>>>>>>>>> real driver/requirement for option c interworking with an IP
>>>>>>>>> based Fabric. Although I can agree than detailing requirements
>>>>>>>>> can always help, I don't think one can assume a certain
>>>>>>>>> application to dismiss the proposal. WH> for me the proposal is
>>>>>>>>> not acceptable for the reasons explained: too much impact on
>>>>>>>>> the data-planes I wrote the above based on the idea that the
>>>>>>>>> encap used in MPLS/MPLS/(UDP or GRE), which hence has to be
>>>>>>>>> supported on the
>>>> ToRs and vswitches.
>>>>>>>>> Another possibility would be
>>>>>>>>> service-label/middle-label/Ethernet
>>>>>>>>> assuming an L2 adjacency between vswitches/ToRs and ASBRs, but
>>>>>>>>> this certainly does not match your typical DC architecture. Or
>>>>>>>>> perhaps had you something else in mind ? WH> see above. The
>>>>>>>>> draft right now also requires changes in existing TOR/NVE so
>>>>>>>>> for me all this discussion/debate is void. No, the spec as it
>>>>>>>>> is can be implemented in its VXLAN variant with existing
>>>>>>>>> vswitches (e.g. OVS allows to choose the VXLAN destination
>>>>>>>>> port, ditto for the linux kernel stack). (ToR is certainly
>>>>>>>>> another story, most of them not having a flexible enough VXLAN
>>>>>>>>> dataplane nor support for any
>>>>>>>>> MPLS-over-IP.)
>>>>>>>>> WH> and how many ports simultaneously would they support? WH>
>>>> and
>>>>>>>>> depending on implementation you don’t need to change any of the
>>>>>>>>> TOR/vswitches. Does this mean that for some implementations you
>>>>>>>>> may not need to change any of the TOR/vswitches, but that for
>>>>>>>>> some others you may ? WH> any proposal on the table requires
>>>>>>>>> changes, so for me this is not a valid discussion See above,
>>>>>>>>> the proposal in the draft does not necessarily need changes in
>>>>>>>>> vswitches. Let me take a practical example : while I can quite
>>>>>>>>> easily see how to implement the procedures in
>>>>>>>>> draft-hao-bess-inter-nvo3-vpn-optionc
>>>>>>>>> based on current vswitch implementations of VXLAN, the lack of
>>>>>>>>> MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to
>>>>>> me as
>>>>>>>>> making that alternate solution you suggest harder to implement.
>>>>>>>>> WH> I would disagree to this. Tell me which switch/TOR handles
>>>>>>>>> multiple UDP ports for VXLAN ? I mentioned _v_switches, and
>>>>>>>>> many do support a variable destination port for VXLAN, which is
>>>>>>>>> sufficient to implement what the draft proposes. -Thomas From:
>>>>>>>>> Thomas Morin <[e-mail]
>>>>>>>>>
>>>>>>
>>>> <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>> Organization: Orange Date:
>>>>>>>>> Friday 13 November 2015 at 09:57 To: Wim Henderickx
>>>>>>>>> <[e-mail]
>>>>>>>>> <mailto:wim.henderickx@alcatel-
>>>>>> lucent.com><mailto:wim.henderickx@alc
>>>>>>>>> atel-lucent.com
>>>>>>>>>
>>>>>>>>>
>>>>>> <mailto:[e-mail]>>>
>>>>>>>>> Cc: "[e-mail] <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>" <[e-mail]
>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]
>>>>>>>>> <mailto:[e-mail]>>> Subject: Re: [bess]
>>>>>>>>> draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, I agree on the
>>>>>>>>> analysis that this proposal is restricted to implementations
>>>>>>>>> that supports the chosen encap with non-IANA ports (which may
>>>>>>>>> be hard to achieve for instance on hardware implementations, as
>>>>>>>>> you suggest), or to context where managing multiple IPs would
>>>>>>>>> be operationally viable. However, it does not seem obvious to
>>>>>>>>> me how the alternative you propose [relying on 3-label option C
>>>>>>>>> with an
>>>>>>>>> MPLS/MPLS/(UDP|GRE) encap] addresses the issue of whether the
>>>>>> encap
>>>>>>>>> behavior is supported or not (e.g. your typical ToR chipset
>>>>>>>>> possibly may not support this kind of encap,  and even
>>>>>>>>> software-based switches may not be ready to support that today).
>>>>>>>>> My take is that having different options to adapt to various
>>>>>>>>> implementations constraints we may have would have value. (+
>>>>>>>>> one question below on VXLAN...) -Thomas 2015-11-12, Henderickx,
>>>>>>>>> Wim
>>>>>>>>> (Wim): On VXLAN/NVGRE, do you challenge the fact that they
>>>>>>>>> would be used with a dummy MAC address that would be replaced
>>>>>>>>> by the right MAC by a sender based on an ARP request when
>>>>>>>>> needed ? Is the above the issue you had in mind about VXLAN and
>>>>>>>>> NVGRE ? WH> yes I you don't mind me asking : why do you challenge that ?
>>>>>>>>>
>>>>>>
>>>>>>
>>>> __________________________________________________________
>>>>>>
>>>> __________________________________________________________
>>>>>> _____
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le
>>>>>> detruire ainsi que les pieces jointes. Les messages electroniques
>>>>>> etant susceptibles d'alteration, France Telecom - Orange decline
>>>>>> toute responsabilite si ce message a ete altere, deforme ou
>>>>>> falsifie. Merci
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law; they should
>>>>>> not be distributed, used or copied without authorization.
>>>>>> If you have received this email in error, please notify the sender
>>>>>> and delete this message and its attachments.
>>>>>> As emails may be altered, France Telecom - Orange shall not be
>>>>>> liable if this message was modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> BESS mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>> _______________________________________________
>>>>>> BESS mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>
>>>>
>>>> __________________________________________________________
>>>> __________________________________________________________
>>>> _____
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le
>>>> detruire ainsi que les pieces jointes. Les messages electroniques
>>>> etant susceptibles d'alteration, France Telecom - Orange decline
>>>> toute responsabilite si ce message a ete altere, deforme ou
>>>> falsifie. Merci
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they should not
>>>> be distributed, used or copied without authorization.
>>>> If you have received this email in error, please notify the sender
>>>> and delete this message and its attachments.
>>>> As emails may be altered, France Telecom - Orange shall not be
>>>> liable if this message was modified, changed or falsified.
>>>> Thank you.
>>>
>>> _______________________________________________
>>> BESS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bess
>>> _______________________________________________
>>> BESS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bess
>> _______________________________________________
>> BESS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bess
>>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>