Hi Wim,
Thanks for your feedback.
With my co-chair hat, let met ask a few questions for the sake of well
understanding the issue you raise.
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)
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 ?
The draft [...] introduces a lot of complexity for nothing.
Can you detail what you consider is a lot of complexity ?
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 ?
-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,
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
