Linda, first of all the draft does not say anything about this and 2nd I am not confused and 3rd I explained the reasons why this does not fly. So read them
From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Friday 13 November 2015 at 23:18 To: Wim Henderickx <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc Wim, If the draft adds some description to say that the VxLAN header is decapsulated, and the MAC header is terminated. It is the inner IP data frames to be passed to the MPLS IP-VPNs. Will it clear out the confusion? Linda From: BESS [mailto:[email protected]] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, November 12, 2015 8:34 AM To: [email protected]<mailto:[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
