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)
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.
Best,
-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: "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 message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
