Hi Wim, It is used for layer 3 VPN CE device to visit IP based overlay data center network. For layer 3 traffic forwarding, the MAC address in VXLAN/NVGRE is restricted only in data center inside domain. For the traffic from data center inside to outside, the inner MAC address(destination MAC is ASBR-d's MAC, src MAC is NVE's MAC) in VXLAN/NVGRE will be dropped at ASBR-d, only IP payload will continue to be carried into MPLS network. I can emphasize this point in my later version, it doesn't have much impact on the whole solution.
This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP network to interconnect with MPLS VPN network. In VXLAN-GPE, it supports IP in IP encapsulation, so no inner MAC concerns. Thanks, weiguo ________________________________ From: BESS [[email protected]] on behalf of Henderickx, Wim (Wim) [[email protected]] Sent: Thursday, November 12, 2015 22:33 To: [email protected] Subject: [bess] draft-hao-bess-inter-nvo3-vpn-optionc 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. The draft does not talk about any of this and introduces a lot of complexity for nothing. 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.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
