In-line with WH> From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Organization: Orange Date: Thursday 12 November 2015 at 17:46 To: Wim Henderickx <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
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 ? WH> VXLAN destination port is fixed so if you don’t use this many implementations will break 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 ? WH> yes 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. WH> many HW implementation require a fixed port for certain encapsulations, so you will break these if you don’t use these 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). WH> yes + I did not discuss the global VNIDs that are used in some implementation 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 ? WH> yes 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
