Hi Linda. > LK> I'm pretty sure this is covered in the architecture document, > but we could do some repeating here. Regarding "each holding the > mapping information for a subset of VNs", part, this gets into > federation of NVAs. I think we can leave that part in the > architecture document since it will probably open more questions, > than provide answers. Also, it is not relevant to the NVA to NVE > protocol since a single NVE only uses a single NVA. > > [Linda] âa single NVE only uses a single NVAâ? What if the NVE is > disconnected from its âonlyâ NVA? Or its only âNVAâ has failure or > is going through software restart? For the distributed case, each > NVA only has mapping for a subset of VNs. It is very possible that > the VNs being participated by one NVE are carried by multiple NVAs
Couple of things. The terminology may not be perfect/precise, but we need to distinguish between the term NVA (as in the entity responsible for operating within one specific NV Domain) vs. an NVA in a broader sense when we talk about multiple different sites (each operating their own NVA) but that share (some) information to create NV regions. If above you are thinking of the latter notion of an NVA, I want to push back on that. Within a specific NV Domain, in the current federated model, there is exactly one NVA; an NVE always/only talks to the NVA operating that NV Domain. If that NVA doesn't have information about a mapping, that info simply is not available to the NVE. An NVE does not contact a different NVA somewhere else to get that info. The whole federated model is intended to allow information from other outside/external NVAs to be imported into a local NVA (subject to policy). Thus, if information from another NVA is needed, it should be available via the local NVA. In that sense, what you write above is not supposed to happen. That said, even within an NV Region, an NVA will consist of multiple entities for redundancy. In that case, and NVE may need to failover from one NVA contact point to another. This will be needed for fault tolerance purposes. Have a look at the redone Section 6.3. There are some questions there that we need to discuss and make a decision on: > 6.3. NVA External Interface > > [note: the following section discusses various options that the WG > has not yet expressed an opinion on. Discussion is encouraged. ] > > Conceptually, from the perspective of an NVE, an NVA is a single > entity. An NVE interacts with the NVA, and it is the NVA's > responsibility for ensuring that interactions between the NVE and NVA > result in consistent behavior across the NVA and all other NVEs using > the same NVA. Because an NVA is built from multiple internal > components, an NVA will have to ensure that information flows to all > internal NVA components appropriately. > > One architectural question is how the NVA presents itself to the NVE. > For example, an NVA could be required to provide access via a single > IP address. If NVEs only have one IP address to interact with, it > would be the responsibility of the NVA to handle NVA component > failures, e.g., by using a "floating IP address" that migrates among > NVA components to ensure that the NVA can always be reached via the > one address. Having all NVA accesses through a single IP address, > however, adds constraints to implementing robust failover, load > balancing, etc. > > [Note: the following is a strawman proposal.] > > In the NVO3 architecture, an NVA is accessed through one or more IP > addresses (ir IP address/port combination). If multiple IP addresses > are used, each IP address provides equivalent functionality, meaning > that an NVE can use any of the provided addresses to interact with > the NVA. Should one address stop working, an NVE is expected to > failover to another. While the different addresses result in > equivalent functionality, one address may be more respond more > quickly than another, e.g., due to network conditions, load on the > server, etc. > > [Note: should we support the following? ] To provide some control > over load balancing, NVA addresses may have an associated priority. > Addresses are used in order of priority, with no explicit preference > among NVA addresses having the same priority. To provide basic load- > balancing among NVAs of equal priorities, NVEs use some randomization > input to select among equal-priority NVAs. Such a priority scheme > facilitates failover and load balancing, for example, allowing a > network operator to specify a set of primary and backup NVAs. > > [note: should we support the following? It would presumably add > considerable complexity to the NVE.] It may be desirable to have > individual NVA addresses responsible for a subset of information > about an NV Domain. In such a case, NVEs would use different NVA > addresses for obtaining or updating information about particular VNs > or TS bindings. A key question with such an approach is how > information would be partitioned, and how an NVE could determine > which address to use to get the information it needs. > > Another possibility is to treat the information on which NVA > addresses to use as cached (soft-state) information at the NVEs, so > that any NVA address can be used to obtain any information, but NVEs > are informed of preferences for which addresses to use for particular > information on VNs or TS bindings. That preference information would > be cached for future use to improve behavior - e.g., if all requests > for a specific subset of VNs are forwarded to a specific NVA > component, the NVE can optimize future requests within that subset by > sending them directly to that NVA component via its address.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
