From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Organization: Orange Date: Thursday 12 November 2015 at 16:24 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Wim Henderickx <[email protected]<mailto:[email protected]>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
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) 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, 2 for the IP addressing it is way to complex to configure and maintain. 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 ? 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 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. -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 [email protected] https://www.ietf.org/mailman/listinfo/bess
