Re: [nvo3] Draft NVO3 WG Charter

["Pat Thaler" <[e-mail]>]

Larry, 

The VSIID field can carry one thing that uniquely identifies the VSI but it isn't the only information in the TLV. Perhaps it would help to expand on the purpose of VDP and the information it carries to support that purpose. VDP assumes that there is some form of virtualization management system that holds profiles for Virtual Station Interfaces (VSI), i.e. the virtual network port of a virtual machine. Often a profile is created for the characteristics needed by a VM of a certain type and multiple VMs can use that profile. VDP is intended to carry enough information to identify the profile and the particular VM so that a bridge (or other network device connected to the end node) can use the information to get the profile and determine whether it can support the configuration for that VM. 

A PDU for VDP carries TLVs. The first TLV in the PDU is a VSI manager TLV which can carry an IPv6 address for the manager holding the profiles for the rest of the TLVs in the PDU.

The rest of the TLVs are VDP association TLVs (and organizationally defined TLVs). 

The VDP association TLV has a type which indicates pre-association (i.e. the VM isn't moving here now, but fetch the profile and see if it can be supported for later), associate and de-associate. It carries the following information

VSI Type ID: 3  octets; identifies a type of VSI - i.e. a profile which could apply to multiple VSI instances
VSI Type Version: 1 octet; allows for multiple versions of a type.
VSSIID: 16 octets; uniquely identifies the VSI by IP address, MAC address, UUID or locally defined format

Filter info: this is information that can be used to filter frames to identify the VSI. An 8-bit filter info format field identifies the format of the filter info field. 4 formats are defined in 802.1Qbg. All of the currently defined filter formats start with a number of entries field - the VSI might have more than one.

The formats currently defined are: 
	VID (VLAN ID)
	MAC/VID
	GroupID/VID
	GroupID/MAC/VID

GroupID is 4 octets and is intended for cases where the network is too large for 12-bit VIDs to scale. For example, it can carry a 24-bit tenant ID appropriate to the network (e.g. PBB I-CID, NVGRE TNI, etc.). The station can put the null VID value in and the bridge can fill it in with a VID that it will map to the tenant ID. The mapping could be local to that physical port.

The currently defined format can carry the VMs MAC address(es) in addition to its IP address or UUID. If one wanted to get both a UUID and an IP address, currently it would have to come from the VM manager along with the profile, e.g. the bridge sends the Type ID and the UUID from the VDP to the virtualization manager and it sends back the profile and the IP address.  Another possibility is that IEEE 802.1 could define additional filter info formats in the future if there is a need.

There are two status bits in the VDP TLV that may be helpful for migration. The M-bit = 1 indicates that the VM is migrating to this port. The S-bit = 1 indicates that the VM is suspended.

Regards,
Pat


-----Original Message-----
From: Larry Kreeger [mailto:[e-mail]] 
Sent: Friday, February 17, 2012 6:04 PM
To: Pat Thaler; Yakov Rekhter; David Black
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [nvo3] Draft NVO3 WG Charter

Hi Pat,

Thanks for educating me about VDP.  Based on what you wrote, it sounds like
it might indeed by useful for the VM attach/detach protocol.  One concern is
that you seem to say the VSI ID can be one of a list of things you mention
that sound promising, but can it support multiple of these?  For example,
the encap/decap device may want to know a Virtual Network's UUID and the
VM's MAC and the VM's IP.

Thanks, Larry


On 2/17/12 5:34 PM, "Pat Thaler" <[e-mail]> wrote:

> VDP (in IEEE P802.1Qbg) does not assume that the VM is defined by a layer 2
> "inner" address. It identifies a VSI by a VSI ID which can be an IP address
> (v4 or v6), MAC address, UUID (RFC 4122) or locally defined format. It can
> also carry filter information - several formats are currently defined for
> filter info - some of them have a 32-bit GroupID to cover the cases where a 12
> bit VID isn't large enough to identify the virtual network. That was added
> based on the need to support a larger identifier when PBB was used, but it
> could serve for other 24 bit tenant identifiers.
> 
> VDP is a protocol that runs between the end system (e.g. a hypervisor) to an
> adjacent bridge so it serves to communicate from the end system to the device
> on the edge of the network that a VM is moving, but it doesn't cover how to
> propagate news of that move across the network. It might be a piece of the
> broader solution but it isn't a complete solution.
> 
> Pat
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Larry
> Kreeger
> Sent: Friday, February 17, 2012 4:22 PM
> To: Yakov Rekhter; David Black
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [nvo3] Draft NVO3 WG Charter
> 
> Yakov,
> 
> On 2/17/12 1:39 PM, "Yakov Rekhter" <[e-mail]> wrote:
>> Dave,
>> 
>>> John,
> <snip>
>> Wrt the protocol that would allow to communicate the VM "move" to
>> the network, I agree with you that it is indeed desirable. Having
>> said this, should we consider the work going on now in IEEE on VDP ?
> 
> I'm not an expert on VDP, but my understanding is that (since it is IEEE),
> it would only work for a layer 2 "inner" address.  Since we want the
> protocol to be layer agnostic (i.e. also support L3 VM addresses), it would
> need to be extended in some way...and it is not an IETF protocol to extend.
> 
>