Hi Wim, WH> I first want to understand the requirements for this use case and I don’t agree to adoption since there are major DP implications in this. [weiguo]: You proposed MPLS over GRE/UDP encapsulation for the traffic between data center inside and outside MPLS VPN network. However, for some TOR switches, they don't support MPLS Over GRE/UDP. Even if they support, they rely on internal loop and the forwarding performance will be reduced half. For option-c scenario, TOR switches need to realize MPLS+MPLS+GRE/UDP, it's more complicated for TOR switches. Current most of the TOR switches support VXLAN encapsulation and have no half forwarding performance issue. For ASBR-d, it is router device in most case, it has capability to realize more comlicated forwarding behavior.
Thanks, weiguo ________________________________ From: BESS [bess-boun...@ietf.org] on behalf of Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com] Sent: Tuesday, November 17, 2015 0:52 To: Thomas Morin; bess@ietf.org Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc In-line From: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Date: Monday 16 November 2015 at 08:29 To: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> Organization: Orange Date: Monday 16 November 2015 at 07:47 To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Wim, Henderickx, Wim (Wim) : VXLAN has a dedicated UDP port and is very clear in the RFC7348 Well, having a port reserved for this use that won't be the default for another protocol is one thing, but that does not prevent in itself the same protocol to be applied on another range of ports. (Because HTTP specs says port 80 does not prevent the URI scheme to allow specifying the port in the URL) Even reading the VXLAN (Informational) specs, we see room for flexibility wrt ports: - Destination Port: IANA has assigned the value 4789 for the VXLAN UDP port, and this value SHOULD be used by default as the destination UDP port. Some early implementations of VXLAN have used other values for the destination port. To enable interoperability with these implementations, the destination port SHOULD be configurable. I read "4789 SHOULD be used by default" and "SHOULD be configurable". WH> true but it does not say to use multiple at the same time. My read on this is that it allows a non standard port to be used, but not multiple at the same time. Will write something on what I proposed when I get some time, not soon The co-chair in me needs to ask the following question: should this call for adoption be kept on hold until an outline of an alternative solution is provided ? WH> I first want to understand the requirements for this use case and I don’t agree to adoption since there are major DP implications in this. -Thomas From: Lucy yong <<mailto:lucy.y...@huawei.com>lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>> Date: Friday 13 November 2015 at 17:10 To: Wim Henderickx <<mailto:wim.henderi...@alcatel-lucent.com>wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>> Cc: "<mailto:bess@ietf.org>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 <<mailto:haowei...@huawei.com>haowei...@huawei.com<mailto:haowei...@huawei.com>> Date: Friday 13 November 2015 at 02:44 To: Wim Henderickx <<mailto:wim.henderi...@alcatel-lucent.com>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 [<mailto:bess-boun...@ietf.org>bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Henderickx, Wim (Wim) [<mailto:wim.henderi...@alcatel-lucent.com>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<mailto:BESS@ietf.org>https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
