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

[Behcet Sarikaya <[e-mail]>]

Hi Bernie,

We will revise the draft based on your review (see inline below). Of
course   more comments are always welcome.

As for the presentation, we leave it up to you.

Regards,

Behcet


On Wed, Feb 19, 2014 at 12:56 PM, Bernie Volz (volz) <[e-mail]> wrote:

>  >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).
>
>
OK, so we get the client to request it using ORO
so the client adds an ORO with OPTION_VNI in the Solicit message.


>  >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.)
>
>
>
OK, so I remove a4.


>   >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 think that with ORO, we don't need a relay option, do we?



>  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.
>
>
Sure, it is client <-> server so relay is not involved.

Regards,

Behcet

>  - Bernie
>
>   From: Behcet Sarikaya <[e-mail]>
> Reply-To: "[e-mail]" <[e-mail]>
> Date: Wednesday, February 19, 2014 12:28 PM
> To: Cisco Employee <[e-mail]>
> Cc: Dhc Chairs <[e-mail]>, "[e-mail]" <
> [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]>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]]
>> *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
>>
>>
>>
>
>