See my comments inline with LK>. - Larry From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Friday, October 25, 2013 1:37 PM To: David Black <[email protected]<mailto:[email protected]>>, Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] "a single NVE only uses a single NVA"?
David, Comments inserted below: Linda, Please view the term “NVA” as a logical construct that may have multiple physical instances/components. [Linda] Then each physical instance has its own address. Yes, you can use “floating IP address” for all of NVAs. But it shouldn’t be the only option. “Floating IP address” will require either all those NVAs to be on the same LAN, or having another NVA load balancer to direct traffic. It is really unnecessary in many environments. For example, see the new text on multiple IP addresses (and ports) for NVA access in section 6.3 of draft-narten-nvo3-arch-01. [Linda] I read the text, but I think people should also look at a few running code of how “authoritative entity” providing mapping information to encapsulation nodes (TRILL directory, LISP MAPserver, etc). We don’t have to re-invent the wheel. LK> Since you brought up LISP… The LISP Mapping System could be made up of a single Map Server/Map Resolver (MS/MR), or there can be multiple MS/MR connected together internally using one of multiple mechanisms (e.g. DDT). Any MR can be used to resolve a mapping. If it doesn't have the mapping it would (e.g. using DDT) forward the Map-Request to the proper MS. This is an example of a logically centralized NVA with multiple IP addresses, but each NVE could be configured to use just one (e.g. the "closest"), or two for backup if the first doesn't respond. This is consistent with the 3rd paragraph of section 6.3 in draft-narten-nvo3-arch-01. This is clearly a valid model for an NVA. The same logical construct concept applies to NVEs, but in the opposite direction. If multiple distinct (logical) NVAs for separate NVO3 domains “talk to” the same NVE implementation, I strongly prefer to view that single NVE implementation as a collection of logical NVEs, one per NVO3 domain (hence one per logical NVA), as hard boundaries on the NVE side will be needed to prevent the independent NVAs from interfering with each other. Thanks, --David From: Linda Dunbar [mailto:[email protected]] Sent: Thursday, October 24, 2013 2:19 PM To: Larry Kreeger (kreeger); Linda Dunbar; Thomas Narten; Black, David Cc: [email protected]<mailto:[email protected]> Subject: RE: Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00" Larry, Please see my comments inserted below: 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 Linda
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
