After discussing with several people this week, we realized that IS-IS is out 
of the NVO3 scope.

Therefore, we suggest the following alternative to move the draft forward:

We can take the IS/IS portion out of the draft, make the draft only focus on 
the handshake needed and the information definition (like TLV) for the NVA-NVE 
mapping distribution.

Once the NVO3 WG reaches consensus, we can bring it to other relevant WGs. 
Right now it is a chicken-egg problem, we bring this to IS/IS for example, they 
will question if the proposed handshake and the information definition have 
been agreed by NVO3.

What do you think?

Thanks, Linda


From: Linda Dunbar
Sent: Wednesday, July 22, 2015 1:02 AM
To: '[email protected]'
Cc: Alia Atlas
Subject: RE: NVA-NVE mapping control plane : solicit input on how to use OVSDB 
to achieve the handshake and auto-discovery of intereated VNs

Well, it has been over two weeks and there hasn't been any proposal coming up 
to specify how to use OVSDB to achieve the control plane between NVA and NVE.

Instead of waiting forever, which will cause NVO3 missing its milestone:

-          Oct 2015 NVE - NVA Control Plane Solution submitted for IESG review


How about we add the following section in the draft to address the 
alternatives? So NVO3 can move forward?




12.Other Theoretical Approaches
Several different protocols have been suggested as candidates but the methods 
to use them have not been defined (OVSDB) or are already handled in a different 
WG (BGP in BESS). OVSDB (Open vSwitch Database Management protocol - RFC7047 by 
individual submission), is to bootstrap a vSwitch with the needed configuration 
(e.g. number of flow tables, the pipeline among those flow tables, path/link 
cost, Timer for Spanning Tree, Hello Timer, enabling Multicast snooping, etc). 
After OVSDB bootstrap a vSwitch, OpenFlow is used to dynamically pass down the 
flow entries.
Theoretically, some components of OVSDB can be potentially adopted (with 
update) to achieve the control plane between NVA and NVE. For example, changes 
to OVSDB are needed to address:
-      How Edge nodes request for Push?
-      How Edge nodes express the participated VNs?
-      How NVA express the supported VNs ranges/list/?
-      How Edge nodes feedback newly discovered attached TSs to NVA
-      How Edge nodes exchange mapping among themselves.

Thanks, Linda

From: Linda Dunbar
Sent: Friday, July 10, 2015 5:48 PM
To: [email protected]<mailto:[email protected]>; '[email protected]'; '[email protected]'
Subject: NVA-NVE mapping control plane : solicit input on how to use OVSDB to 
achieve the handshake and auto-discovery of intereated VNs


As agreed at today's interim meeting, in order to make the discussion 
productive, we need to break the discussion into two categories:



- The information model and handshakes for the NVA-NVE mapping distribution 
protocol.



- The mechanism to carry the data (whether OVSDB or ISIS, both have been 
deployed in production networks).





We are soliciting input from the community on how to use OVSDB to achieve the 
following handshakes, auto-discovery and control negotiation:




*       How to use OVSDB to achieve:
-      NVA multicast mappings to all interested NVEs?
-      NVA auto discover all the NVEs that are interested in receiving mappings
-      Edge nodes request for Push?
-      Edge nodes express the participated VNs?
-      NVA express the supported VNs ranges/list/?
-      Edge nodes feedback newly discovered attached TSs to NVA
-      Edge nodes exchange mapping among themselves.
-      How to use OVSDB to distribute incremental changes of inner-outer 
mappings to all edge nodes?

Thank you in advance.

Linda
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to