Lucy Yong :
[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.
I don't think Wim mentioned 3-labels over UDP or GRE.
Wim proposal works with 2-labels over an IP encap (the topmost label of
the typical 3-label option C being replaced by an IP transport).
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.
( Note that I merely mentioned the problem of vswitch/ToR support for
MPLS/MPLS/(UDP or GRE), but had mentioned nothing about overall DC
architecture. )
-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
