Wim,
(below)
2015-11-12, Henderickx, Wim (Wim):
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.
This comment only relates to a subset of the encaps proposed in the
solution, right ?
(e.g. does not apply to MPLS/GRE and MPLS/UDP)
WH> even for the encapsulations that don’t have this issue, 1 the UDP
port proposal breaks some of the protocols so we should never do this,
Sorry to insist, but where do some protocol break when used with a
non-standard port as dstport ?
2 for the IP addressing it is way to complex to configure and maintain.
I agree with that.
As such the proposal for me would be to do the 3 label stack as we
have in standard MPLS option C which you can do with the
encapsulations I mentioned.
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 ?
The draft [...] introduces a lot of complexity for nothing.
Can you detail what you consider is a lot of complexity ?
WH> UDP ports and IP address prefix maintenance
I agree for the alternative in which multiple IPs are used.
But I don't think using multiple port would be complex, the
configuration on the box can simply consist of a range of ports to use
and the rest would be (quite simply) automated.
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.
My understanding of this draft's value is the fact that it avoids
having service-label related state (forwarding and BGP state) on the
routers at the DC-WAN border. This is one of the typical property of
4364 option C. It is not obvious at all to me, based on existing
spec, how to get the same benefit on the DC-side router in an
architecture where the DC-side router also terminates the overlay tunnels.
Do you challenge the goal itself (not having service-label related
state on the overlay tunnels router) or suggest that the same benefit
can be achieved with less complexity ?
WH> the proposal I mentioned is achieving the same goal w/o the
complexity in the DC GW and using already standardised mechanisms to
do so.
Let me try to recap.
For traffic going from the DC to the WAN, the DC/WAN router terminating
the overlay will have to translate from for instance an MPLS/UDP/IP
encap into an MPLS/MPLS(/MPLS) encap ; assuming that the bottom label
isn't changed the information to determine the other label(s) has to be
derived from the UDP or IP header. The draft we discuss relies on the
UDP port (or IP address).
You mention a 3-label option C, are you suggesting the use of
MPLS/MPLS/UDP where the top MPLS label would play the role of the middle
label in an typical 3-label option-C stack, and would be used to
determine the destination-PE label between ASBRs ?
Best,
-Thomas
_________________________________________________________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
