Hi Zu, My responses are inline below.
- Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Thursday, September 12, 2013 9:04 AM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Questions to draft-ietf-nvo3-nve-nva-cp-req-00 Hello, Larry I have some clarification questions on section 3 of this draft. - Section 3.3: the text is a little bit confused. Please clarify it. 1) At VN connect/disconnect, the attached/detached NVE may be notified by the hypervisor. Then the NVE will inform the NVA, where the NVA is going to update the remote NVEs with a new address mapping table. 2) Or the NVA may learn the VN connect/disconnect from somewhere (e.g. orchestration). Then it will notify the NVE where the VN was attached/detached and update the remote NVEs with a new address mapping table. 3) Or both 1) and 2) are allowed? LK> In my opinion, number 1) makes the most sense. Doing thing this way eliminates the need for a central orchestrator that must manage all NVEs regardless of where they might reside (hypervisors, ToR switches, routers, firewalls, load balancers etc). However, section 6.1 of draft-marten-nvo3-arch leaves it open for number 2) as well. As long as we have a protocol to federate NVAs, one might have one NVA only for hypervisors with embedded NVEs where VN connect/disconnect is communicated directly to the NVA (perhaps through an internal software interface), and another NVA for various physical NVEs. - Because of my confusion from the reading of section 3.3, it may be good to make it more clear in section 3.1 and 3.2 on which direction the notification is sent. For instance, “A protocol is needed for the NVA to provide this inner to outer mapping and VN Context to each NVE that requires it and keep the mapping updated in a timely manner.” LK> Yes, this section is meant to express the need for an NVE to get a mapping from the NVA. I can add the text you suggest above to make it clearer. However your comment made me realize that the other direction (NVE telling the NVA what inner addresses to outer mappings it terminates) is missing. I can add subsections to 3.1 to cover each direction of inner/outer mapping information flow. - Section 3.4: I agree that VN name into VN ID mapping may be needed. However, we may need to allow different implementations. For instance, one can have this mapping in NVA only and use VN ID in all interfaces. Therefore, supporting this mapping in NVA-NVE protocol shall be optional. LK> I agree that it is optional. The wording in section 3.4 was trying to convey this. It mentions both approaches. It is probably better to come out and say this is optional instead of inferring it with statements such as "Thus, it may be useful for the NVE-to-NVA protocol to support an operation that maps VN Names into VN IDs.". Have a nice day Zu Qiang
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
