Larry, Thomas, and David, Going through your current "draft-ietf-nvo3-nve-nva-cp-req-00" to enhance our "http://www.ietf.org/id/draft-dunbar-nvo3-nva-gap-analysis-01.txt";, I noticed that there are several detailed NVE<->NVA control plane requirement not yet identified in your draft. Some requirements of TRIL/LISP directory mechanism described in "draft-dunbar-nvo3-nva-gap-analysis" are applicable to NVE<->NVA control plane requirement because TRILL/LISP directory mechanisms are also about distributing "inner-outer" address mapping to edge nodes . Here are the some suggested additions to the current "draft-ietf-nvo3-nve-nva-cp-req-00", to make the NVE-NVA requirement draft more complete and easier for gap analysis.
1. The first paragraph of Section 4 describes the characteristics of NVEs. Since this draft is about control plane requirement between NVE and NVA, it is beneficial to add some description for the characteristics of NVAs. Here is my suggested addition after the first paragraph of Section 4: "NVAs can be centralized or distributed with each NVA holding the mapping information for a subset of VNs. Centralized NVA could have multiple entities for redundancy purpose. A NVA could be instantiated on a server/VM attached to a NVE, very much like a TS attached to a NVE, or could be integrated with a NVE. When a NVA is a standalone server/VM attached to a NVE, it has to be reachable via the attached NVE by other NVEs. A NVA can also be instantiated on a NVE that doesn't have any TSs attached. The NVE-NVA control plane for NVA being attached to NVE will require additional functions on NVEs than NVA being instantiated on NVE." 2. Section 4 should add the following additional requirement on how NVEs and NVAs discover each others, and which NVA for NVE to send pulling or pushing requests. * NVEs requesting for Push Services after restart: In the Push Model, it is necessary to have a way for NVE to request NVAs to start the pushing process, e.g. when the NVE is initialized or re-started. Or it can be like a routing protocol where it just happens automatically. The request for Push Service from NVE should be VN scoped, i.e. including the range of VNs that are enabled on the NVE. * NVAs should advertise their VN-scoped availability to the NVEs who participate in the VN. There could be multiple NVAs, with each having mapping information for a subset of VNs. For each VN, there could be multiple NVAs that have the mapping information. * When there are multiple NVAs holding mapping information for a particular VN, a pull request can be sent to any of them that is reachable but it is RECOMMENDED that Pull requests be sent to a NVA that is least cost from the requesting NVE. 3. Bullet 2 of Section 4: More detailed requirements are needed when "inner address that NVE doesn't have a mapping for". I suggest adding the following detailed requirement when inner address is not available on the NVE's mapping database: "If the destination of a data frame arriving at the Ingress NVE can't be found in NVE's inner-outer mapping database, the Ingress NVE should be configured with one or more of the following policies: * simply drop the data frame, * Using legacy method(s) to forward the data frames to other edges, or * start the "pull" process to get information from Pull NVA When the edge is waiting for reply from Pull process, the edge can either drop or queue the packet." 4. Section 4 Bullet 3 has requirement on "fast detection/update of stale cache". It would be clearer to add additional requirement on incremental update in Push Model. Here is the proposed text for "Incremental update" * Whenever there is any change in TS' association to an edge (NVE), which can be triggered by TS being added, removed, or de-commissioned, an incremental update can be sent to the edges that are impacted by the change. It is desirable for incremental update to only include the changed mapping entries. However per mapping entry incremental update can cause complexity of NVA in maintaining the state of each entry. A good balance between amount of data in each incremental update and the complexity of maintaining status of entries should be considered. 5. Section 4 should add the following additional requirement on what NVE should do when there is no response from Pull request. Here is my suggested text: * There are several possibilities of the Pull Response: o Valid inner-outer address mapping, coupled with the valid timer indicating how long the entry can be cached by the edge (NVE). The timer for cache should be short in an environment where VMs move frequently. The cache timer can also be configured. o The target being queried is not available. The response should include the policy if requester should forward data frame in legacy way, or drop the data frame. o The requestor is administratively prohibited from getting an informative response. If no response is received to a Pull request within a configurable timeout, the request should be re-transmitted with the same Sequence Number up to a configurable number of times. If errors occur at the query level, they MUST be reported in a response message separate from the results of any successful queries. If multiple queries in a request have different errors, they MUST be reported in separate response messages. If multiple queries in a request have the same error, this error response MAY be reported in one response message. 6. Section 4 should add the following additional requirement on the proper behavior on NVE when it loses its connection to its Push NVA. Here is my suggested addition: If an NVE notices that a Push NVA is no longer reachable, it MUST ignore any Push mapping entries from that NVA because it is no longer being updated and may be stale. There may be transient conflicts between mapping information from different Push NVAs, some kind of confidence level information with mapping entries can be considered in case of such conflicts. Information with a higher confidence value is preferred over information with a lower confidence. Thanks, Linda Dunbar
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
