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

Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 19 February 2014 17:28 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B951A0500 for <dhcwg@ietfa.amsl.com>; Wed, 19 Feb 2014 09:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00EaXiQIQvp5 for <dhcwg@ietfa.amsl.com>; Wed, 19 Feb 2014 09:28:21 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6A1A0249 for <dhcwg@ietf.org>; Wed, 19 Feb 2014 09:28:19 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id e16so524774lan.12 for <dhcwg@ietf.org>; Wed, 19 Feb 2014 09:28:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Lu4yP2CO3WqAAJsyozs+UJPOOhqCxRu+WRu2UqaHUP8=; b=Z+BkJeCou2LaLc4EaONfDnz4V2tpzx4Vbp02gBIRe440Of053ob5nE6gwK++Yb4Th4 LF2mxGSLiTBzAYfwHwcqJ8j3e3SAKHDH2Xmwe+RPBxuahu4OkLoziOo2GX/4OY8ux+wC xthCDhCmzK/sxlZIUd6ey8Ocgqk8qTVyahi32374K8JNoz+V7GY/IgzUquZJq3X0/f9U GOw271rt6KU1xZuMAhy/9aiCK3Cz+41cuIHCKDCYIJyrsTVhtbYvxLl78eQBxMLGtj8H pNB4ULMIzGLtB6LoiE7Bi3QKFzf+WHJAvNWhAY+jcIwqmRkspleLLybHiP3wfN5PZgyk FOZQ==
MIME-Version: 1.0
X-Received: by 10.152.43.47 with SMTP id t15mr11017935lal.38.1392830896077; Wed, 19 Feb 2014 09:28:16 -0800 (PST)
Received: by 10.114.170.195 with HTTP; Wed, 19 Feb 2014 09:28:16 -0800 (PST)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com>
References: <20140214173114.23812.70162.idtracker@ietfa.amsl.com> <CAC8QAcfGgayrUkXZp4hNdGeZpfv3hazpg4n=2kx8qUHqObhUAg@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AE72D20@xmb-rcd-x04.cisco.com>
Date: Wed, 19 Feb 2014 11:28:16 -0600
Message-ID: <CAC8QAcfn-EQEvr6Mzvc7iQw2wQGL+YdGtMQuh2JxLr8jpmRvmg@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c24100caff1d04f2c5b62a"
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZSdlxtXuATWQJrBtRlLwm91hBOk
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Dhc Chairs <dhc-chairs@tools.ietf.org>
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 17:28:24 -0000

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) <volz@cisco.com> 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:sarikaya2012@gmail.com]
> *Sent:* Friday, February 14, 2014 12:36 PM
> *To:* Dhc Chairs
> *Cc:* dhcwg@ietf.org
> *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
>
>
>