From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>> Date: Friday 13 November 2015 at 21:55 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
From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com] Sent: Friday, November 13, 2015 2:49 PM To: Lucy yong; Haoweiguo Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: Re: draft-hao-bess-inter-nvo3-vpn-optionc From: Lucy yong <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>> Date: Friday 13 November 2015 at 21:31 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 Wim, See [lucy2] 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. WH> they are used for entropy, you seem to be creating a kludge. [Lucy1] It works. WH2> good luck, but does not mean IETF has to adopt it. Mine also works :-) The proposal I gave works with an IP data plane [Lucy2] IETF does not specify how entropy value is generated yet. It can be provided by tunnel egress and tell the ingress. WH3> the RFC is pretty clear: — copy — The UDP source port number be calculated using a hash of fields from the inner packet -- one example being a hash of the inner Ethernet frame's headers. This is to enable a level of entropy for the ECMP/load- balancing of the VM-to-VM traffic across the VXLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335<https://tools.ietf.org/html/rfc6335>]. — copy -- [Lucy] I am not clear what is your proposal in this piled thread. Could you state or copy/paste again? WH> look at the archives it is in there [Lucy1] Is this one? “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.” If yes, you suggest NVE to implement MPLSoGRE or MPLSoUDP, to support VXLAN-GPE for L3 payload. First of all, using MPLSoGRE or MPLSoUDP for this case, requires three labels + GRE/UDP tunnel, huge overhead is introduced here. This is very complex in my opinion. Our solution can apply VXLAN-GRE encap. and also support MPLSoX encap (5.1.1 and 5.1.2). BTW, this may be not what you suggested. WH> it is less bits then you proposal and no changes in any CP/DP that is standardised today. Where is the complexity? Works today and is deployed in many networks [Lucy2] This is not compliant with many DCs’ architecture as Thomas pointed out. To make them doing it, it becomes very complex. WH3> it is even deployed in existing DC(s) [Lucy3] Yes, if existing DC supports MPLS, it can use your solution. For those DCs that do not support MPLS, and already use VXLAN+ip tunnels for intra-DC traffic, it is pain for them to implement your solution. Our draft is to provide a solution for those DCs that do not support MPLS. WH4> works also with VXLAN GPE 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