Hi Zu, Please see inline with LK>.
- Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Tuesday, August 13, 2013 6:45 AM To: NVO3 <[email protected]<mailto:[email protected]>> Subject: [nvo3] draft-ietf-nvo3-nve-nva-cp-req: VN Name to VN ID mapping Hi, Authors In section 3.4, there is VN Name to VN ID mapping. “…it may be useful for the NVE-to-NVA protocol to support an operation that maps VN Names into VN IDs.” This may or may not be an NVA-NVE function. It is true that there are so many ways this might be done, including especially the potential for NVA functions being not so much distributed as addressed by a set of "servers" – some of which already exist – intended to support a subset of the required control functions. For instance, the VN Name to VN ID could be handled by a DNS like service, or by either Radius or Diameter. LK> I expect in the end the NVA will have more duties than just inner to outer address mappings. We could put each function into a separate server, but that adds complication to NVE configuration. It is much simpler to configure a single NVA than a bunch of sub-NVAs that each take a piece of the puzzle. Furthermore, it is simpler to manage one NVA than a jumble of them. And this is really a management/operational requirement since this information will be configured in NVA or each NVE. LK> Configuring each NVE for the VN Name to VN IDs it needs, creates a management headache. What if you configure one wrong? What if you fail to configure one? How do you decide which NVEs to configure (every single one?)? What VN Name to VN ID mappings an NVE needs depends on what TS connect to it, which can be changing continually. It will be much simpler operationally to configure it in one single place. In fact, the NVA could actually manage the VN IDs itself by allocating one when a new VN is created. In the NVA-to-NVE operation, either VN name or the VN ID is used, but it does not need both. LK> It may well need both. The VM orchestration system want to create a new VN. It allocates a globally unique VN-Name. The overlay needs some VN Context to identify the VN in each packet. If a global VN ID is used (as is done in VXLAN or NVGRE or LISP) for the VN Context, then it is needed too. LISP would use this as the IID to identify the VN, not only in the data plane, but in the control plane too. I don't know how many current control planes use a globally unique name, so to use a control plane that does not, you need to translate the VN Name to a VN ID. Adding the mapping function into the NVA-NVE protocol is really not effective. As mentioned in the next section, a large scale data center may contain hundreds of thousands of these NVEs (which may be several independent implementations); Therefore, any savings in per-NVE resources can be multiplied hundreds of thousands of times. LK> I'm not following you on how using the NVA to lookup the VN ID is not effective. Best Regards Zu Qiang
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
