Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

["Bernie Volz (volz)" <[e-mail]>]

Behcet:

Just so we can properly prioritize (though at present we seem to have sufficient time), is this intended to be an informational presentation, or do you have issues to discuss/resolve? We'll give preference to those drafts that have issues to discuss/resolve.

Also, as this is now (I think) primarily targeted for the NVO3 (Network Virtualization Overlays) WG, is there anything of significance to discuss in DHC - there does seem to be some server processing involved as the client supplied option triggers the server to return a specific multicast address.

A few comments from a quick look at the document:

1.       Why does the client set the address to 0 in the address option? Why have the client include this option at all (server can just add it either because the network identifier option is present or as client can request in PRL/ORO)?

2.       The option lengths are wrong? In DHCPv6 (& DHCPv4), the option length covers just the data itself (not the option code and option type).

3.       Why is the "VXLAN Identifier" apparently 3 bytes for the DHCPv6 option and 4 bytes for the DHCPv4 option? What is the relationship between this VXLAN Identifier and the "24-bit Virtual Subnet Identifier (VSID)"? It does state "Note that VSID is simlar to VNI" - but that is still something different than the VXLAN Identifier (though even earlier is stated "VXLAN header contains 24-bit VNI"). So I would guess this is 3 byte (octet) field and this is the VNI? Why call it something else then?

4.       There's no relay option ... perhaps that is intentional but can the client's "Network Identifier" option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would know and therefore it has to be trusted?
Probably some of the above is because of my lack of understanding of this entire space.


-          Bernie

From: Behcet Sarikaya [mailto:[e-mail]]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: [e-mail]
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Dear Chairs,
We submitted a draft, see below for details.
Please reserve a short slot in IETF 89.
Note that this is a revised and renamed version of draft-sarikaya-dhc-vxlan-multicast-02.

A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-multicast
Revision:       00
Title:          DHCP Options for Configuring Multicast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00


Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning
   multicast addresses for the Tunnel End Point in the Virtual
   eXtensible Local Area Network (VXLAN) environments.  New DHCP options
   are defined which allow a VXLAN Tunnel End Point to request any
   source multicast address for the newly created virtual machine and
   possibly IPv4/IPv6 address(es) for the virtual machine.



Regards,

Frank & Behcet