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

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

>Since we are defining several DHC options and related client/server behaviour, we thought that it should also be presented in dhc WG, as is customary, no?

It is more important that it be "presented" on the mailing list than necessarily in a DHC WG session. If the draft is intended to be adopted by DHC WG, a presentation is typically a good idea to assure people know about it. But it is not required. Also, we are trying to move "simple" options (I.e., those that do not have an special processing requirements and follow the Option Guidelines drafts) work out of the DHC WG as other working groups should be able to handle those following the Option Guidelines.

>Yes, I think this is another way of doing it. Is there a preference by dhc WG on which way we should have it in the draft?

For options which are only intended for the information to go one way (I.e., server to client), having the client request the option in the PRL/ORO is the way to go; there's no benefit in having the client send the option. Only if the client must present some data to the server which the server needs to process the request, does it make sense for the client to include it (and in that case, either using two options (client -> server; server -> client) or using optional fields in the option makes more sense).

>VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to zero. Maybe we don't need to have a4, I thought DHCPv4 options are always given in 4-octets?

Field should be the size that the data is – padding isn't necessary. Alignment does make drawing the option diagrams easier, but there's really no benefit in client or server processing and it makes the packets larger for no good reason. So, if a field is 24-bits, only use 24-bits. (The examples typically used are for 8-bit, 16-bit, or 32-bit values as those line up with what usually makes the most sense, but that doesn't mean other sizes are not allowed.)



>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?

>We can clarify and say that the client MUST set it to zero, would that be OK?

I am not sure how this relates to my concern about whether a client or relay is best to provide this information. If the client has it and needs it, then client <-> server makes most sense. I suspect that this is a case where this is just client <-> server and relay is not involved.

- Bernie

From: Behcet Sarikaya <[e-mail]<mailto:[e-mail]>>
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 19, 2014 12:28 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: Dhc Chairs <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Hi Bernie,

Thanks for your review, sorry for the delay in my reply, apologies.

Please see my replies inline.

Regards,

Behcet


On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:
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.


Since we are defining several DHC options and related client/server behaviour, we thought that it should also be presented in dhc WG, as is customary, no?

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.


The aim is to get dhc specific comments about our draft, much like what you did below.

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)?

Yes, I think this is another way of doing it. Is there a preference by dhc WG on which way we should have it in the draft?


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

OK, to be corrected.

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?

VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to zero. Maybe we don't need to have a4, I thought DHCPv4 options are always given in 4-octets?



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?

We can clarify and say that the client MUST set it to zero, would that be OK?

Probably some of the above is because of my lack of understanding of this entire space.


Thanks again for taking the time and giving us very nice feedback.


-          Bernie

From: Behcet Sarikaya [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: [e-mail]<mailto:[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