From: Lucy yong <[email protected]<mailto:[email protected]>>
Date: Friday 13 November 2015 at 22:06
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
Haoweiguo <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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
[Lucy4] do you mean VXLAN GRE or VXLAN GRE+NSH?
WH5> no regular VXLAN GPE and will also work with VXLAN GRE if this ever get
adopted/supported by IETF, NSH is orthogonal
Lucy
Will write something on what I proposed when I get some time, not soon
From: Lucy yong <[email protected]<mailto:[email protected]>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
Haoweiguo <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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:[email protected]] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, November 12, 2015 11:00 PM
To: Haoweiguo
Cc: [email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>>
Date: Friday 13 November 2015 at 02:44
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 [[email protected]<mailto:[email protected]>] on behalf of
Henderickx, Wim (Wim)
[[email protected]<mailto:[email protected]>]
Sent: Thursday, November 12, 2015 22:33
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
