A) Not per prefix (at least not without serious amount of end-to-end BGP
multipathing+BGP AddPath or multiple RDs)
B) There's no liveliness check in *VPN (apart from LISP)
In MPLS/VPN we rely on the host route to PE loopback and/or LSP to the
/32 prefix to indicate next hop validity. That won't work for
hypervisor-based NVEs
On 9/4/12 8:00 PM, Balus, Florin Stelian (Florin) wrote:
AFAIK the text in NVO3 framework and requirements drafts allows multiple IPs
per NVE. We have multiple IPs per PE in current VPN implementations. This is an
implementation matter though in my opinion.
-----Original Message-----
From: Somesh Gupta [mailto:[email protected]]
Sent: Tuesday, September 04, 2012 10:51 AM
To: Ivan Pepelnjak; Balus, Florin Stelian (Florin)
Cc: [email protected]
Subject: RE: [nvo3] Support for multi-homed NVEs
Florin,
Regarding the multi-homing, my assumption is that the NVE in the
hypervisor would not (want to) run a routing protocol. So as Ivan
points out, the standard would need to accommodate multiple IP
addresses per NVE.
Somesh
-----Original Message-----
From: Ivan Pepelnjak [mailto:[email protected]]
Sent: Tuesday, September 04, 2012 9:58 AM
To: Balus, Florin Stelian (Florin)
Cc: Somesh Gupta; [email protected]
Subject: Re: [nvo3] Support for multi-homed NVEs
Ah, that other can of worms ;) Mine was simpler.
On the underlay side, we might decide that NVEs have a single IP
address or multiple IP addresses (like some NVGRE load balancing
proposals). If we decide NVEs have a single IP address (potential per
virtual network segment), then the rest is implementation details
(and
we're back to MLAG/SMLT land for true redundancy). Alternatively we
might implement the option of having multiple IP addresses per NVE,
and the NVEs might use the IP-address-per-link option (thus no need
for L2 or MLAG at all).
On the overlay side, the real problem (as you stated) is the
multi-homing of NVO3-to-legacy gateways. I don't see any other need
for overlay NVE multihoming.
BTW, Nicira has nicely solved the NVO3 gateway multihoming - the
whole
NVO3 network works exactly like VMware's vSwitch: split horizon
bridging (thus no forwarding loops through NVO3), with every VM MAC
address being dynamically assigned to one of the gateways, which also
solves the return path issues (dynamic MAC learning in legacy network
takes care of that). Maybe we should just use the wheel that has
already been invented?
Kind regards,
Ivan
On 9/4/12 6:45 PM, Balus, Florin Stelian (Florin) wrote:
I understand the discussion below is about the NVE multi-homing
towards the IP core, on the tunnel side.
We did not focus in the framework draft on the core redundancy as
in
our opinion there was no need to standardize anything here. There are
no differences from what is available today in regular IP networks:
if
NVEs are multi-homed directly to the next IP router, regular routing
will take care of it. If there is Ethernet switching in between NVE
and the next IP hop, L2 resiliency mechanisms need to be employed.
From what I read below it looks more of an implementation discussion
than a standardization requirement. Am I right?
By Multi-homed NVEs one can also understand a set of NVEs
multi-homed
on the access side to other devices. That is a discussion we need to
have in my opinion. An use case example: NVO3 network - NVE GWs
multi-
homed to external non-NVO3 networks. Handoff can be VLANs, VPLS PWs,
or BGP EVPN labels...
I think the latter is worth discussing although there are some
mechanisms and some standardization initiatives in place already.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of
Ivan Pepelnjak
Sent: Friday, August 31, 2012 12:23 AM
To: 'Somesh Gupta'; [email protected]
Subject: Re: [nvo3] Support for multi-homed NVEs
This is definitely an interesting can of worms ;)
While I don't think we should go down the path of IP-A/IP-B
networks similar to some other DC technology, we will face the
reality of
some
NVE elements (hypervisor soft switches) not being underlay IP
routers.
We could either:
(A) ignore the issue and expect the network designer to solve it
using
any one of the existing NIC teaming/MLAG kludges while retaining a
single encapsulation IP address per NVE;
(B) provide support for multiple encapsulation addresses per NVE
so
a
multi-homed NVE could have one IP address per physical interface
and send and receive nvo3-encapsulated frames using more than one
address.
Option (A) is the easy way out similar to existing MPLS/VPN
behavior and would fit well with existing DC deployments. It would
also
retain
all the server-to-ToR multihoming complexity.
Option (B) would reduce the complexity of the underlay DC network
(which would become a simple L3 network with single-homed IP
addresses), but we'd have to deal with a bunch of additional
problems
(peer IP address liveliness check).
Just speculating ...
Ivan
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Somesh Gupta
Sent: Friday, August 31, 2012 6:58 AM
To: [email protected]
Subject: [nvo3] Support for multi-homed NVEs
I did not see any mention of multi-homed NVEs in draft-lasserre-
nvo3-
framework-03.txt. NVEs are connected together by an L3 network -
does
that mean only one?
Can it be multi-homes to two L3 networks?
Somesh
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
