Hello, Thomas
First of all, I'm not in favour of alternative C. As I said in my
email, hybrid approach might be desirable in some development cases. I do think
your proposed text make sense. It is more link a NVE-NVE control plane plus
NVA-NVE control plane. In additional, the architecture shall also have a clear
statement if alternative C is not supported by NVO3.
Have a nice day
Zu Qiang
>-----Original Message-----
>From: Thomas Narten [mailto:[email protected]]
>Sent: Friday, October 18, 2013 6:11 PM
>To: Zu Qiang
>Cc: [email protected]
>Subject: NVE-NVE control plane interactions [was Re: [nvo3] 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]
https://www.ietf.org/mailman/listinfo/nvo3
