Hello, Thomas
Thanks for your email. see inline.
Have a nice day
Zu Qiang
>-----Original Message-----
>From: Thomas Narten [mailto:[email protected]]
>Sent: Thursday, October 17, 2013 5:29 PM
>To: Zu Qiang
>Cc: [email protected]
>Subject: Re: [nvo3] NVO3 Architecture document
>
>Zu Qiang <[email protected]> writes:
>
>> I have one comment which I have sent in the control plane draft
>> discussion. But it may have an impact on the architecture draft as
>> well. In section 7.1, there are two alternatives described. However it
>> shall be possible for an implementation to use NVE-NVE protocol for
>> inner-outer mapping updating. Using NVE-NVE protocol may not be the
>> best solution. But as an architecture document, it may be good to list
>> all the possibilities.
>
>Agreed. That is why both are mentioned.
[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.
In implementation, maybe two of the alternatives or three alternatives are
needed in some cases. So hybrid approach might be desirable in some development
cases.
A) is described in section 7.1 in the architecture draft. B) is described as an
alternative in section 7.1 in the architecture draft. However, I don't see
alternative C). Do I miss anything in my reading?
>
>> And it may be better to have some
>> analysis text on the pros and cons of each alternatives.
>
>That I would like to avoid. The architecture document should describe the
>direction the WG has chosen to go in. I don't think we should document the
>pros/cons of various approaches (that is more what the framework does).
[Zu Qiang] So your suggestion is to keep the analysis text in different
document? For instance, we may have the security aspect analysing in security
requirement document. Does that make sense?
>
>Also, in the specific case above, I'm not sure listing pros/cons of the two
>approaches helps. I don't expect folk to pick one or the other based on the
>pros/cons. One of the starting premises is that there are already existing
>orchestration systems that provide the functionality of the NVA, and existing
>deployments use them. I don't expect implementations already using such a
>facility to change. I do think we will need to coexist with such approaches,
>hence they need to be part of the architecture.
>
>Does that make sense?
[Zu Qiang] I agree that it's not the intention to change any existing
implementations. The analysis text is just to show the considerations of each
implementations. For instance, one alternative may have additional security
requirements, which mean different security solutions may be needed.
So I think analysis text is needed. But we shall avoid to give any conclusion
of which alternative is better than others.
>
>Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
