Linda, Please view the term "NVA" as a logical construct that may have multiple physical instances/components. 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. 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] 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
