RE: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

["LASSERRE, MARC (MARC)" <marc.lasserre@xxxxxxxxxxxxxxxxxx>]

Linda,

 

It is a local decision to assign whatever VNI value is best suited. As I have mentioned before, it is a locally significant value that is used as a demultiplexer.

An NVE can use a VLAN ID as a locally significant value if it wants to.

 

Marc

---

From: Linda Dunbar [mailto:linda.dunbar@xxxxxxxxxx]
Sent: Friday, May 30, 2014 5:02 PM
To: LASSERRE, MARC (MARC); Larry Kreeger (kreeger); Ken Gray (kegray)
Cc: nvo3@xxxxxxxx; ietf@xxxxxxxx; IETF-Announce
Subject: RE: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Marc,

 

Questions inserted below:

 

From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@xxxxxxxxxxxxxxxxxx]

 

-       Page 13 Second bullet: the text says that each VNI is automatically generated by the egress NVE. Isn’t each VNI supposed to match a local virtual network (e.g. represented by VLAN)? When the same NVE acts as Ingress NVE for the attached VMs, aren’t the VNI for ingress direction statically provisioned? Why need automatic egress VNI generation?  

 

The value of the VN context identifier is a value locally significant to an NVE and does not have to match a local virtual network. It is simply used as a demultiplexer. This value can be automaticaly computed or provisioned.

 

[Linda]If the NVE’s VAPS (VNI) are connected to VMs via Ethernet where VLAN is used, it is much easier to use locally significant VLAN. Why require egress to automatically generate local VNI value?  It would be better to change the text to:

 

“Each VNI value on egress NVE is either mapped to locally significant Virtual Network identifier (e.g. VLAN for Ethernet), or generated by NVA or Control Plane”.

 

Linda

 

nvo3 mailing list

nvo3@xxxxxxxx

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