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 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.
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.
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.
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 depending on implementation you don’t need to change any of
the TOR/vswitches.
Does this mean that for some implementations you may not need to
change any of the TOR/vswitches, but that for some others you may ?
WH> any proposal on the table requires changes, so for me this is not
a valid discussion
See above, the proposal in the draft does not necessarily need changes
in vswitches.
Let me take a practical example : while I can quite easily see how to
implement the procedures in draft-hao-bess-inter-nvo3-vpn-optionc
based on current vswitch implementations of VXLAN, the lack of
MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to me as
making that alternate solution you suggest harder to implement.
WH> I would disagree to this. Tell me which switch/TOR handles
multiple UDP ports for VXLAN ?
I mentioned _v_switches, and many do support a variable destination port
for VXLAN, which is sufficient to implement what the draft proposes.
-Thomas
From: Thomas Morin <thomas.mo...@orange.com>
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx <wim.henderi...@alcatel-lucent.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Hi Wim,
I agree on the analysis that this proposal is restricted to
implementations that supports the chosen encap with non-IANA ports
(which may be hard to achieve for instance on hardware
implementations, as you suggest), or to context where managing
multiple IPs would be operationally viable.
However, it does not seem obvious to me how the alternative you
propose [relying on 3-label option C with an MPLS/MPLS/(UDP|GRE)
encap] addresses the issue of whether the encap behavior is
supported or not (e.g. your typical ToR chipset possibly may not
support this kind of encap, and even software-based switches may not
be ready to support that today).
My take is that having different options to adapt to various
implementations constraints we may have would have value.
(+ one question below on VXLAN...)
-Thomas
2015-11-12, Henderickx, Wim (Wim):
On VXLAN/NVGRE, do you challenge the fact that they would be used
with a dummy MAC address that would be replaced by the right MAC
by a sender based on an ARP request when needed ?
Is the above the issue you had in mind about VXLAN and NVGRE ?
WH> yes
I you don't mind me asking : why do you challenge that ?
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this
message was modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
