Thomas, Comments inserted below:
> -----Original Message----- > > > > [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. > [Linda] I meant NVA within one specific VN Domain (as the entity responsible for operating within one specific VN Domain). One NVA entity may have mapping entries for multiple VN domains. > > Within a specific NV Domain, in the current federated model, there is > exactly one NVA; [Linda] That is one way of doing it. But why this has to be the only way? There are already multiple versions of running code that allow redundant entities to provide mapping entries for any given VN, e.g. TRILL's Directory & LISP MapServer. > 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. [Linda]What if the connection to the local NVA is broken? > > 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. [Linda] that is correct. The architecture should allow the NVAs to announce their supported VNs. Each NVE can be configured (with policies) on which one is the primary NVA and which one is the secondary NVA. My comments to your Section 6.3 are inserted below: > > 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 > > > > > > One architectural question is how the NVA presents itself to the > NVE. [Linda] The simplest approach, as done by various versions of running code, is for NVA to announce itself (via VN scoped broadcast) and send heartbeat periodically. > > 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 [Linda] That is one way of doing it. But this method requires the redundant NVAs to be in same LAN and in close proximity. Another way is to allow each NVA to announce itself. Or provision each NVE with NVAs' address for each VN that NVE is participating. > Snipped for ease of commenting: [Linda] There have been deployed mechanisms of using authoritative entities to provide information to routers/switches for decades. Look at the mechanisms that are used by DNS, DHCP, management system/monitoring systems/controller, the common behavior is for (network) elements to be configured with one or a list of the legitimate "authoritative entities". If there are multiple "authoritative entities", either policy (i.e. provisioning) is configured on the elements to enforce which "authoritative entity" is the primary one, or the elements can choose primary one among the list of "legitimate authoritative entities". Why need to re-invent the wheel for something that has been deployed? Linda _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
