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. 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. 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. Thanks, weiguo ________________________________ From: BESS [bess-boun...@ietf.org] on behalf of Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com] Sent: Saturday, November 14, 2015 15:12 To: Linda Dunbar; bess@ietf.org 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 <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> Date: Friday 13 November 2015 at 23:18 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> 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:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, November 12, 2015 8:34 AM To: bess@ietf.org<mailto:bess@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
