Wim, VXLAN has a dedicated UDP port and is very clear in the RFC7348 [Lucy] This does not prevent other implementation to use VXLAN with other UDP port. If someone wants to stick on the dedicate UDP port, we can use the src UDP port to achieve that. The proposal I gave works with an IP data plane [Lucy] I am not clear what is your proposal in this piled thread. Could you state or copy/paste again?
Lucy Will write something on what I proposed when I get some time, not soon From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>> Date: Friday 13 November 2015 at 17:10 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, OptionC is very useful for DCI use case. In this case, multi-hop EBGP redistributes VN routes between the end NVEs in source and destination Ass, ASBRs do not maintain and distribute the VN routes; a tunnel is built between the end NVEs in source and destination Ass for traffic transport. Due to the different data planes in DC and WAN, the tunnel is stitched by several segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN. Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. However, there are many DCs that do not support MPLS data plane. This draft is to provide the solution for this use case. Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate to use another UDP port for the VXLAN encapsulation, I don’t see it breaks anything. Not sure if hw has this restriction either. Even yes, we can consider using UDP source port for this purpose. UDP source port is used for transit ECMP and filled by flow entropy, tunnel egress can determine the flow entropy value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can maintain UDP source port and MPLS label table; when DC ASBR receives a packet from NVE, by lookup the table, it gets the label for the packet, push the label on the packet before sending toward WAN. Hope we together work out the solution for this valid use case and like to hear any better alternative. Regards, Lucy From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, November 12, 2015 11:00 PM To: Haoweiguo Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc The whole draft complicates any data plane we defined so far and since there is simpler solutions I don’t support this proposal. Arguments have been given as to why. From: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>> Date: Friday 13 November 2015 at 02:44 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>] Sent: Thursday, November 12, 2015 22:33 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
