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".
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 ?
-Thomas
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
