> I think there are multiple scenarios here to consider, and the details
> matter.
Agree.
> Scenario 1: Bare metal server has 2 separate connections to two
> different boxes. How are these two connections presented to the
> (bare-metal) TS?
I am going to fail at describing this with the NVO3 terminology. A TS to me is
a site, that has lots of hosts, switches, routers in it. They are addressable.
I call those addresses EIDs. So we are talking about a single EID. An IP
address assigned to a bare-metal server that has two connections, one to each
physical NVE.
> 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?)
I can't answer this because I am not sure you and I agree on what a TS is. I am
not disagreeing how NVO3 defines a TS but I think it is not specific enough for
this context.
> 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?)
Yes, they have to connect to the same L2 network.
> 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. :-)
This called multi-homing. ;-) That is equivalent to a LISP EID that has a
locator-set. The reason there is a locator-set is because there can be multiple
RLOCs (read: NVEs) used reach the EID.
> Do you mean the NVE has two physical connections to the ToR? If so,
No, I am simply generalizing it to this topology:
EIDs
/ \
/ \
NVE NVE
/ \
/ \
Where there are multiple from the EID to 1-or-more NVEs. And the NVEs have
multiple paths leading to the core.
> 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.
That is correct. And many-to-one as well.
> Is this something we need to support? I agree it has some
> benefits. But it also adds some complications...
>
> Thomas
It depends how close topologically the NVE is to the endpoint. If the NVE was
in the application, then for the same IP address there would be multiple NVEs.
So the point could be taken to an extreme.
Dino
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
