Thomas,
A couple of subtle points about this discussion:
1) if the intent is to document the architecture agreed to within the NVO3
working
group, it would be clearer if we cleaned up the first paragraph in the
Introduction
so that it is consistent with this goal. In particular, the first
sentence in the section
indicates that the draft "presents a high-level overview of a possible
architecture"
(which begs a question - "have other possibilities been
considered/addressed?").
2) if we want to ensure that we have an architecture likely to have any
long-term
viability, we should use some care in making sure that it doesn't break
under some
set of reasonable use-cases we are discussing already.
This said, I believe the fact that - even with extensive colocation of NVA
functionality
- unless we contemplate requiring this, there will be a need to define a
standard way
for one vendor's NVE to conduct transactions with another vendor's NVA (and vice
versa).
So the thing we might want to ensure is that we do not impose any unreasonable
architectural restrictions that would preclude solutions that rely on (or
support) some
arbitrary degree of co-location of (for instance) NVE and NVA functionality.
I am pretty sure we could do exactly that, if we insist on making the
architecture simpler
than it needs to be.
--
Eric
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Thomas
Narten
Sent: Friday, October 18, 2013 6:11 PM
To: Zu Qiang
Cc: [email protected]
Subject: [nvo3] NVE-NVE control plane interactions [was Re: NVO3 Architecture
document]
Hi Zu.
OK, I see where you are coming from now.
> [Zu Qiang] I see three alternatives which are all described in the
> draft
> [http://tools.ietf.org/html/draft-zu-nov3-security-requirements-01]
> A) If either the NVA is collocated with the VM Orchestration Systems,
> or there is an interface between the VM Orchestration Systems and NVA,
> it can be assumed that the NVA may learn the VN connection /
> disconnection and vNIC association / disassociation from the VM
> Orchestration Systems. Then the NVA configures the attached NVE with
> the VN context of the connected / disconnected VN and the associated /
> disassociated vNIC addresses. The next step is that the NVA updates
> the inner-outer address mapping table of the VN at both the attached
> NVE and all the participating remote NVEs.
> B) The attached NVE is informed by the hypervisor using the
> Hypervisor-NVE protocol at VN connection / disconnection and vNIC
> association / disassociation. Then the attached NVE notifies the NVA
> with the received VN updating information. The next step is that the
> NVA updates the inner-outer address mapping table of the VN at both
> the attached NVE and all the participating remote NVEs.
> C) It is also possible to use a NVE-NVE control plane protocol to
> update the peer NVEs' inner-outer address mapping table timely at VN
> connection / disconnection or vNIC association / disassociation.
> However, this approach may require the NVE-NVE control plane packets
> to be flooded to all NVEs when no mapping exists.
C) is another possible approach. In some sense, this is a highly distributed
NVA where the NVEs are really part of the NVA. I.e., NVEs are talking directly
to other NVEs to obtain and exchange information, rather than relying on an
NVA. In this model, I think we lose a clean separation between NVEs and NVAs,
since NVEs are implementing NVA functionality.
While I agree this is one model, I don't think we should put it in the
architecture unless the WG decides it wants to support such a model. Remember,
the goal of the architecture document is not to show all possible alternatives,
but to show the one NVO3 will support.
That said, another possible interaction model has NVEs sending information to
other NVEs that one might consider part of the control plane, such as an egress
NVE responding with a "target VM not here" or "target VM has moved to NVE XXX",
etc. Such messages could be treated as authoritative, in which case they are
accepted as updates. Or, they could be treated as hints to go check with the
NVA for updated information. The two approaches have very different trust
assumptions.
Note that draft-sridharan-virtualization-nvgre-ext-00.txt defines UNREACHABLE
and REDIRECT messages between NVEs.
As a strawman for discussion, I'd suggest that the architecture:
1) Support messages between NVEs that provide hints that an NVE has
stale information and should go back to the NVA for
updated/authoritative information. and
2) That the architecture does not merge NVE/NVA functionality in such
a way that the NVE effectively is part of the NVA.
Thoughts?
Thomas
_______________________________________________
nvo3 mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
