Subject: Re: [nvo3] draft-ietf-nvo3-nve-nva-cp-req: VN Name to VN ID mapping

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 21 Oct 2013 08:02:49 +0000

Hi Zu,

Please see inline with LK>.

 - Larry

From: Zu Qiang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 13, 2013 6:45 AM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
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

---

From: Zu Qiang <[email-masked]>
Date: Mon, 21 Oct 2013 13:45:41 +0000

Hello, Larry
                I see your point. As far as the support of the VN name to VN ID is optional in the NVA-NVE protocol, it shall be ok.
Have a nice day
Zu Qiang

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Monday, October 21, 2013 4:03 AM
To: Zu Qiang; NVO3
Subject: Re: [nvo3] draft-ietf-nvo3-nve-nva-cp-req: VN Name to VN ID mapping

Hi Zu,

 - Larry

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.

Best Regards
Zu Qiang