Doesn't your item 2 assume that what is being delivered is an L3
service? What if the TS is multi-connected to two NVEs, and is getting
L2 service to the same tenant bridged space from both of them? Even if
the service is layer 3, I would expect the tenant to want all IP
addresses to work even if on NVE connection fails. To some degree what
you seem to be saying below is that we should always treat multiple
TS-NVE connections as if they were separate TS. That seems to be very
restrictive on the redundancy models people expect.
Yes, as you comment in another note, if we assume the NVE is in the
hyperviso then this is a non-problem. But I was under the impression
that we were not to make that assumption.
Yours,
Joel
On 11/20/13 2:59 PM, Thomas Narten wrote:
Hi Dino.
I suspect we need to dive a bit deeper into this. i.e., what does
"dual attached" mean?
A bare-metal server has 2 physical connections to different boxes
(where a box is a swtich or a router). In some cases, the 2
connections are active/active, but mostly active/backup. There is
some assumption from the server OSes that the upstream boxes are
layer-2 switches. But it doesn't have to be the case, they can be
layer-3 routers.
I think there are multiple scenarios here to consider, and the details
matter.
Scenario 1: Bare metal server has 2 separate connections to two
different boxes. How are these two connections presented to the
(bare-metal) TS?
1A) two different interfaces are visible to the TS, both with their
own separate IP addresses. This is not an issue for NVO3, since this
is modeled as two interfaces to two separate VNs. (Right?)
B) TS sees only one interface, the CNA hides the details of two
physical uplinks from TS. Links could be active/active or
active/backup. In this case, the TS has one IP adddress (I presume)
with the CNA hiding the details of multiple uplinks from the TS.
This is a messier case... Do both uplinks have to connect to the same
NVE? In the standard L2 case, don't both L2 uplinks have to connect to
the "same L2 network"? That only means that both ToRs would need to
support the same VLANs and connect to the same LAN domains. (Right?)
If above we allow the two uplinks to go to two different NVEs, the
implication is that from an NVO3 perspective, a given TS mapping is
reachable through different NVE addresses. That raises all sorts of
interesting questions. :-)
Do you mean the NVE has two physical connections to the ToR? If so,
No, that would be the NVE being able to get ECMP support from the
underlay. I am talking about the NVE in the TOR, as one example.
Right, NVE is doing IP and each uplink would be to different L3 dest.
than the question presumably is about allowing/supporting multi-homed
NVEs.
That is right Thomas.
Yikes. I guess we need to have that discussion. :)
If the question is about the TS having two attachements to the ToR,
wouldn't that be modeled (architecturally) as two distinct
interfaces/ports, in which case each one can connect to its own NVE,
in which case we are good?
The questions is about the return traffic coming to the TS. Do you
want it load-split across all the NVEs associated with the TS. The
answer is a definite yes, as Joel stated for robustness and to take
advantage of all cross-sectional cheap bandwidth in a data center.
Fundamentally, it means that address mappings (inner to outer) are not
one-to-one, but are one-to-many.
Is this something we need to support? I agree it has some
benefits. But it also adds some complications...
Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
