Subject: [nvo3] Suggestion for the Control Plane starting point ( was RE: the role of a standard (was: Consensus call on moving forward with a single encap.)

From: Linda Dunbar <[email-masked]>
Date: Mon, 25 Jul 2016 19:01:30 +0000

Alia,

Glad to see you stating that “Work on a control plane solution is absolutely in scope for NVO3”.

This draft on the Information Model/Data Model for the Control Plane between NVA and NVE has been stalled for more than a year, (we were asked to present it at the NVO3 sessions multiple times, but no action from on the following up steps, like we are going in cycles,  which is making us not motivated to bring it up again on session nor NVO3 mailing list).
https://datatracker.ietf.org/doc/draft-dunbar-nvo3-nva-mapping-distribution/

How about NVO3 adopt this draft as WG draft, making the Information model and Data model for the control plane between  NVA <-> NVE as the Starting Point?

The NVO3 WG  can collectively enhance the Information/Data models. Then decide if the Data Model can be achieved by BGP or choose another more appropriate protocol?

My 2 cents.

Linda Dunbar

From: nvo3 [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, July 25, 2016 8:35 AM
To: Fabio Maino
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] the role of a standard (was: Consensus call on moving forward with a single encap.)

Hi Fabio,

Thanks for the discussion.  I think that it is really important to share our different perspectives
so that we can end up someplace beneficial for the industry.

I am encouraging very active discussion on the control plane - including having some virtual
interims to educate folks on all the different options out there.  So far, there has been very little
discussion on what is being used or what might be brought in as potential starting points.  Of course,
work has actively progressed on a BGP control-plane based solution in BESS, since that discussion
was removed from NVO3 - but there was very far from any agreement that the BGP-based approach was the way to go.  Perhaps there are changes in perception as BGP is increasingly common in data-centers.

Work on a control plane solution is absolutely in scope for NVO3 - but I have not seen it happening and
I have strong concerns about whether this group can come to consensus on anything implementable.

As far as publishing existing encapsulations as Experimental, I do not see any experiments that would cause us to reevaluate and think that Informational is more accurate.  In either case, it does not provide a solid standards-track basis for additional work.

Regards,
Alia

On Sun, Jul 24, 2016 at 11:06 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,
reality is that existing implementations do support multiple encapsulations already. To avoid adding complexity to the control plane then we mandate to add complexity to the data plane?

If work on or compromise on a control plane is out scope for NVO3, maybe the architecture should assume that the control plane (whichever it is) will take care of selecting the appropriate encapsulation. The control plane I know better (LISP) has a way to do this, so I assume the others will do as well.

Then it might be reasonable to publish the encapsulations as experimental, and let the deployments speak.

Fabio

On 7/24/16 7:27 PM, Alia Atlas wrote:
Hi Fabio,

Why do you believe that there is actual interest to work on or compromise on a control plane?
I have seen no such evidence.  I can certainly agree that having a control plane able to deal
with multiple encapsulations for backwards compatibility would be useful; it does increase
complexity of the solution.

Having multiple encapsulations multiplies the complexity for everything on top.

Regards,
Alia

On Sun, Jul 24, 2016 at 10:19 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:
I think Uri makes an important point when he says that adding a 4th encapsulation will compound the problem rather than solving it, especially considering where the HW/SW implementations are today.

IMO this WG should focus on designing a control plane that allows to discover and select the appropriate encapsulation, based on receiver's capability.

Once that is done the overall architecture will be able to deal with multiple encapsulations, and more than one can be moved to standard track.

This kind of work will also help with backward compatibility with encapsulations (such as VXLAN, for example) that will be around for quite some time.

Fabio

On 7/24/16 6:54 AM, Alia Atlas wrote:

Uri,

Thank you very much for your thoughts on the standards process.

We do need to understand significant technical objections to whatever existing solution might be stated from.

Unfortunately,  the solutions haven't responded to much input or changed from the WG yet.

Regards,
Alia

On Jul 24, 2016 5:19 AM, "Elzur, Uri" <[email-masked]<mailto:[email-masked]>> wrote:
Reading the threads here, it may be good to take a moment to discuss expectations out of a std process. To me, a “standard” is about an industry agreement, on a path forward, in a timely fashion, that paves the way (ushers in) the next wave of innovation. Let me try to parse it

-          Industry agreement: in singular (not in plural). The process is to produce ONE agreed upon solution that ideally gives no party any unfair advantage. It is conceivable, however, that leaders retain some of the first mover advantage. If the outcome is MULTITUDE of “standards”, and in this particular case, it may mean simply documentation of 3 separate commercial camps where vendors have created competing approaches, we may have missed the mark.

-          In a timely fashion: One can’t ignore the time aspect. When the std process is not moving fast enough, it jeopardizes the value of the “industry agreement”. In the last years, a significant productivity gains by the software development and open source, enables much faster evolution, one risks therefore, a catch up scenario, lost relevance and falling into documentation. The IETF process has to be updated to cope with the faster evolution, so that within a year of emerging open source direction (where relevant) the WG has narrowed down the options to one and is very close to being done. (yes, I know this is ideal…but this is what is needed)

-          Path forward: that is a suitable technical solution to a given set of problems with a limited set of forward looking mechanism based on experience ( the “limit” is really a judgment call to help with the goal of timeliness); Including however, a reasonable evolution of HW + SW. i.e. assuming HW (NICs in this case) is to be of stagnant limited functionality (i.e. XSUM like feature invented in 1996 – 20 years ago) as a base assumption, should not be the lead assumption. IETF has historically been more SW oriented, but data path encapsulation should not be SW only discussion! Also the emergence of programmable HW and modeling of HW to allow easier programming, means that the std may be relaxed in terms of rigid assumptions of HW functionality. (also not to ignore other aspects, in most cases, the std needs to be backwards compatible to not break existing solutions)

-          New innovation: a successful timely process, keeping pace with the industry, with less vendor specific options will do the trick here…

If we have similar expectations, it may be easier to converge on the complicated problem at hand. 3 options on the table for prolonged time, where the HW and SW have already made progress. So I for one, don’t think in THIS CASE, creating a 4th option is the way forward. We may be better served by picking one out of the existing ones

Thx

Uri (“Oo-Ree”)
C: 949-378-7568<tel:949-378-7568>

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Linda Dunbar
Sent: Friday, July 22, 2016 1:11 PM
To: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

+1.

Besides, IETF already has specified many encapsulations, is it really that bad having one extra?

Linda

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Friday, July 22, 2016 7:55 AM
To: Bocci, Matthew (Nokia - GB)
Cc: NVO3
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Please respond to this email on the NVO3 list by 29th July 2016:
- Given the IETF's mission, should NVO3 move forward on the standards track with a single encapsulation on the standards track?  If not, please explain your concern in detail.

While the world would be a better place with only one encapsulation, I think it's better to stick with the original path of allowing the 3 encapsulations as experimental.

The NVO3 charter says:
Based on these requirements the WG will select, extend, and/or
develop one or more data plane encapsulation format(s).

Based on the charter, the WG has gone through the process of accepting to work on 3 encapsulations.  What do we know now that we did not know back then?

If we were going to progress only a single encapsulation, I think there would have been more critical feedback and strong suggestions for changing that "winning" encapsulation to accommodate what the other encapsulations perceive as their relative strengths.  And we risk opening up that discussion now and delaying progress even more.

Otherwise, not having a standard has not been a hinderance for getting protocols deployed in the past, and I suspect that if the developers of these encapsulations care enough, we will see deployments of all of them regardless of whether or not we progress them within the working group.

Thanks,
Anoop

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________

nvo3 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Mon, 25 Jul 2016 21:48:01 +0000

Support to work on this one draft for control plane IM/Data Model.

Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, July 25, 2016 2:02 PM
To: Alia Atlas; NVO3; [email-masked]
Subject: [nvo3] Suggestion for the Control Plane starting point ( was RE: the role of a standard (was: Consensus call on moving forward with a single encap.)

Alia,

My 2 cents.

Linda Dunbar

Hi Fabio,

Regards,
Alia

Fabio

Regards,
Alia

Fabio

Uri,

Regards,
Alia

Thx

Uri (“Oo-Ree”)

+1.

Linda

The NVO3 charter says:

Thanks,
Anoop

nvo3 mailing list