In-line From: BESS <[email protected]<mailto:[email protected]>> on behalf of Haoweiguo <[email protected]<mailto:[email protected]>> Date: Sunday 15 November 2015 at 13:51 To: Wim Henderickx <[email protected]<mailto:[email protected]>>, Linda Dunbar <[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
Hi Wim, Thanks for your detail explanation. In your solution, MPLSoGRE/oUDP needs to be supported in data center network. To support option-c interconnection with WAN network, TORs/NVEs need to add one BGP LSP Label in middle layer, so TORs/NVEs need to perform MPLS(VPN Layer) + MPLS (BGP LSP Label) + GRE/UDP encapsulation for the traffic from local connecting end systems to WAN network. In your solution, GRE/UDP layer is not used for transport layer stitching at ASBR-d, traditonal end to end BGP LSP is still used for transport layer. WH> The proposal I made is supportable on NVE/TOR/Applications in the DC and this is something that is feasible today without any extra standardisation. In our solution, VXLAN/NVGRE are two of the focuses, and for VXLAN/NVGRE and MPLS VPN network option-c mode interconnection, our solution seems to be the only choice. For MPLS Over GRE/UDP, it's the debating point.We propose the same interconnecting solution for MPLSoGRE/oUDP, your proposal provides another optional solution, i think it works and is good. However, i think an independent informational draft only for this point maybe not necessary, we can describe it in same single draft which includes all possible solutions for IP overlay network(VXLAN/NVGRE/VXLAN-GPE/MPLSoGRE/MPLSoUDP) and MPLS VPN network interworking using option-c mode. WH> I understand what you try to achieve but your proposal requires changes in the NVE/TOR as well since the TOR/NVE(s) out there don’t support multiple VXLAN ports and on top the whole MAC handling is not described and will require additional changes in the NVE/TOR data-planes. So the proposal you have I don’t support for being adopted since it requires to drastic changes in the data plane elements. In summary, Option-c mode interconnecting solution between IP overlay network and MPLS VPN network is needed for BESS working group, and we should cover all possible solutions for all possible mainstream IP overlay encapsulations in single draft. WH> The point is that your proposal requires too drastic impact in the DP and this is why I oppose to the draft being adopted. On top I am also questioning the real need for an NVE/TOR requiring to support this. Most use case I have seen require the application inside the DC consume the 3rd label and as such is very well supported with the proposal I suggested. Thanks, weiguo ________________________________ From: BESS [[email protected]<mailto:[email protected]>] on behalf of Henderickx, Wim (Wim) [[email protected]<mailto:[email protected]>] Sent: Saturday, November 14, 2015 15:12 To: Linda Dunbar; [email protected]<mailto:[email protected]> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc 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
