Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Mon, 04 February 2019 18:37 UTC
Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4907130EE6 for <dhcwg@ietfa.amsl.com>; Mon, 4 Feb 2019 10:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 lGRjx1IvlDt9 for <dhcwg@ietfa.amsl.com>; Mon, 4 Feb 2019 10:37:30 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2374A130EE2 for <dhcwg@ietf.org>; Mon, 4 Feb 2019 10:37:30 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id y8so1002774wmi.4 for <dhcwg@ietf.org>; Mon, 04 Feb 2019 10:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m5nI1nXbJ9uuyWoEr1Q8sxQ2yiqqU2vNNuile/Fegxc=; b=lTl9m9wOzkXSmA4CTw0Uz7fyekddfNaeqX9m8AO8gVinTfVlupYDS89ydd00qejvMW Z3bFhEJ9S82ZXVbV5xRlVlhe+2qfntV+/ljb83RBiBFX82nM/S8gb6jePZv/INvyQF/E Zom9FIz96xq/wvUMk4jcZ9GdZXMQnJa/TpxiGn7fNLjX8Zsyxqu8ua1nf5huANPGn49O HCJp5VYF2Hir9XPuXxjFRKA1yPy5wblxz1H3/8/xk8oPHTW/OKhBQ9VInE//ijCWIErz /t5OBn2lHKsi04ksMDKHEH6uYOwzM7ECaehSvTo2PfsB3k2UBQDhQwidkv6SqPOJknvy /owg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m5nI1nXbJ9uuyWoEr1Q8sxQ2yiqqU2vNNuile/Fegxc=; b=k0Cso34LRAW3iGIrvznSHK9hoIdz6482ew0NVZEHVOydnOVidDCZ0wc0Y2vaQ4q74D h4h2fcZP3NYsJwtrC3uLk6ojEvmZU23ElhELXOQFRLOiMjy6UdKopTX2brooqmctmUVc u/0p+DRYvxw4s+ms3IZ06Z+h1TNF/AKBxB2L5OuWSr9Y83czlo2QFBa2Syw1Fi7p1cpt CtZk6+XE0hUQIrWwD6uuk00ijNqBWrKkh6RVNgup7C8Eqgtdc65ioC6gEvGhyRhztMUx zMxx6P993aN068EbMW+O69tMR/VmpfjgBitsfy+oRUUXSAWbW8kpA5jGL0KKPUekntve 7Irg==
X-Gm-Message-State: AHQUAubOKWG6PVfN+apKFlpwnYqq6tuRrXyYlCcHc9JA4dQt7s+A96Z8 7Zkzhz4VFRhKe7oyf/y3kB3Y/tUrm47T/YOJ4ziagw==
X-Google-Smtp-Source: AHgI3IZZIW207USRaMjDnynu6d9f2oNOuii13aJ1cEWcoReNJiZA486Ag/FnmDQXu0FliHHiHXUKhdbLjdYlwSFTJ/M=
X-Received: by 2002:a1c:c303:: with SMTP id t3mr553581wmf.94.1549305448143; Mon, 04 Feb 2019 10:37:28 -0800 (PST)
MIME-Version: 1.0
References: <154874417588.3009.15379484544595638729@ietfa.amsl.com> <CALypLp_CuX33xKaNPhh2aAsDm52puM2fSGRXPGZLVD5g-dFgyA@mail.gmail.com> <6fecdfca802247268613ec1896ce21b9@XCH-ALN-003.cisco.com>
In-Reply-To: <6fecdfca802247268613ec1896ce21b9@XCH-ALN-003.cisco.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Mon, 04 Feb 2019 19:37:11 +0100
Message-ID: <CALypLp_N1UyhVUi7r2t4Z_ZTn+4bqRMqXYm1W8jjuzhwUmzDEw@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2c8de058115c81c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/moDV1mJ5Ej_S57fELUVf35F0Yw4>
Subject: Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 04 Feb 2019 18:37:36 -0000
Hi Bernie, Thanks a lot for your comments. Please see inline below. On Wed, Jan 30, 2019 at 7:42 PM Bernie Volz (volz) <volz@cisco.com> wrote: > Hi: > > > > Below are some comments on this new individual submission draft: > > > > Abstract > > … > > > > The IEEE is working on mechanisms to allocate addresses in the one of > > these quadrants (IEEE 802.1CQ). There is work also in the IETF > > working on specifying new mechanism that extends DHCPv6 operation to > > BV> drop “working”, redundant? And, add “a” – specifying a new > CB> Thanks. We'll fix this. handle the local MAC address assignments. In this document, we > > complement this IETF work by defining a mechanism to allow choosing > > the SLAP quadrant to use in the allocation of the MAC address to the > > requesting terminal/client. > > > > This document proposes extensions to DHCPv6 protocols to enable a > > DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant > > to the server, so that the server allocates correspondingly the MAC > > address to the given client or relay. > > BV> This correspondingly is a big awkward and the address(es) are always > > BV> allocated to the client, not the relay. Perhaps “so that the server > > BV> allocates the MAC address to the given client out of the quadrant > > BV> requested by relay or client”. I would assume relay’s should “win”? > CB> Thanks for the proposal. It's definitely better than the original text. We'll update. > > … > > 1.1. Problem statement > > > > The IEEE is working on mechanisms to allocate addresses in the SAI > > quadrant (IEEE 802.1CQ project). There is also ongoing work in the > > IETF [I-D.bvtm-dhc-mac-assign] specifying new mechanism that extends > > BV> Add a – specifying a new > CB> OK! > DHCPv6 operation to handle the local MAC address assignments. In > > this document, we complement ongoing IETF work with mechanisms to > > BV> Add this - we complement this ongoing > CB> OK! > allow choosing the SLAP quadrant to use in the allocation of the MAC > > address to the requesting terminal/client. This document proposes > > extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 > > relay to indicate a preferred SLAP quadrant to the server, so that > > the server allocates correspondingly the MAC address to the given > > client or relay. > > BV> See Abstract comment. > CB> OK! > > > … > > > > 1.1.1. WiFi terminals > > > > Today, most of WiFi terminals come with interfaces that have a > > BV> Drop of – most WiFi terminals (perhaps devices may be better than > > BV> terminals – if changed, you need to do throughout) > CB> OK, I'll replace interfaces with terminals in all the document. > "burned" MAC address, allocated from the universal address space > > BV> “burned in”? > CB> OK, thanks. > … > > > > 1.1.2. Hypervisor: migratable vs non-migratable functions > > … > > > > o Migratable functions. If a VM (providing a given function) might > > need to be potentially migrated to another region of the data > > center (due to maintenance, resilience, end-user mobility, etc.) > > it is needed that this VM can keep its networking context in the > > new region, and this includes keeping its MAC addresses. > > Therefore, this makes better to allocate addresses from the ELI/ > > BV> “this makes better” is odd wording. “Therefore, for this case, it is > better”? > CB> OK, thanks. > SAI SLAP quadrant, which can be centrally allocated by the DHCP > > server. > > > > o Non-migratable functions. If a VM will not be migrated to another > > region of the data center, then there are no requirements > > BV> can drop then. > CB> OK! > associated to its MAC address, and then it is more efficient to > > allocate it from the AAI SLAP quadrant, which does not need to be > > same for all the data centers (i.e., each region can manage its > > own, without checking for duplicates globally). > > > > 2. Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > BV> Please use latest working for this. For example, see Section 2 of > RFC8415? > CB> OK, I'll fix that. > > > > > The DHCPv6 terminology relevant to this specification from the DHCPv6 > > Protocol [RFC8415] applies here. > > > > client A device that is interested in obtaining link-layer > > addresses. It implements the basic DHCPv6 mechanisms > > needed by a DHCPv6 client as described in [RFC8415] and > > supports the new options (IA_LL and LLADDR) specified > > in this document. The client may or may not support > > BV> Isn’t this what is specified in [I-D.bvtm-dhc-mac-assign], not this document? > > CB> Yes, you got me. I think I abused copy & paste :D. I'll fix this. Sorry. > address assignment and prefix delegation as specified > > in [RFC8415]. > > > > server Software that manages link-layer address allocation and > > is able to respond to client queries. It implements > > basic DHCPv6 server functionality as described in > > [RFC8415] and supports the new options (IA_LL and > > LLADDR) specified in this document. The server may or > > BV> Same issue as above here. > CB> Same. > may not support address assignment and prefix > > delegation as specified in [RFC8415]. > > > > … > > > > 3. Quadrant selection mechanisms > > > > … > > > > o Operation/battery lifetime: depending on the expected lifetime of > > the terminal a different quadrant might be preferred (as before, > > to minimize potential address collisions in the future). The > > BV> Shouldn’t a paragraph break go here? This seems to be different > > BV> material then operation/battery lifetime? > CB> Yes, you are right. We'll fix this. > previous are examples of parameters that an IoT terminal might use > > to select a given SLAP quadrant. IoT terminals are typically very > > resource constrained, so it might be as well that simple decisions > > are just taken, for example based on pre-configured preferences. > > > > … > > > > Additionally, the information can also be used to trigger subsequent > > changes of MAC address, to enhance location privacy. Besides, > > changing the SLAP quadrant used might also be used as an additional > > enhancement to make harder to track the user location. > > BV> Add it – to make it harder? > CB> OK! > > > Last, if we consider the data center scenario, an hypervisor might > > BV> Change “an” to “a”. > CB> OK! > request local MAC addresses to be assigned to virtual machines. As > > … > > > > > > +--------+ +--------+ > > | DHCPv6 | | DHCPv6 | > > | client | | server | > > +--------+ +--------+ > > | | > > +-------1. Solicit(IA_LL(quad))------->| > > | | > > |<--2. Advertise(IA_LL(LLADDR,quad))--+| > > | | > > +---3. Request(IA_LL(LLADDR,quad))---->| > > | | > > |<------4. Reply(IA_LL(LLADDR))--------+ > > | | > > . . > > . (timer expiring) . > > . . > > | | > > +------5. Renew(IA_LL(LLADDR))-------->| > > | | > > |<-----6. Reply(IA_LL(LLADDR))---------+ > > | | > > > > Figure 3: DHCPv6 signaling flow (client-server) > > > > 1. Link-layer addresses (i.e., MAC addresses) are assigned in > > blocks. The smallest block is a single address. To request an > > assignment, the client sends a Solicit message with a IA_LL > > option in the message. The IA_LL option MUST contain a LLADDR > > option. In order to indicate the preferred SLAP quadrant, the > > IA_LL option includes a new quad IA-LL-option, which contains the > > preferred quadrant. > > > > BV> I think you should just use QUAD (for OPTION_QUAD) and the text > > BV> should say “the IA_LL option includes the new OPTION_QUAD option > > BV> in the IA-LL-option field (with the LLAADR option). > CB> OK, so you mean to replace for example "Solicit(IA_LL(quad))" with " Solicit(IA_LL(QUAD))" and then also fix the text according to your suggestion, right? > > > > … > > > > 5. When the assigned addresses are about to expire, the client sends > > a Renew message. > > > > BV> I think the RENEW should also include the QUAD option. If the server > > BV> were unable to extend the lifetime on the existing address(es), it > > BV> would need to know what quadrant to use for any “new” addresses. > CB> OK, that makes sense. Thanks for the suggestion. > … > > > > 4.2. Address assignment from the SLAP quadrant indicated by the relay > > > > … > > 2. The DHCP relay receives the Solicit message and encapsulates it > > in a Relay-forw message. The relay, based on local knowledge > > and policies, includes in the Relay Agent Remote-ID Option the > > preferred quadrant. The relay might know which quadrant to > > request based on local configuration (e.g., the served network > > contains IoT devices only, thus requiring ELI/SAI) or other > > means such as based on analyzing the Solicit message from the > > client. > > > > BV> Use the QUAD option here to, but it is just added to Relay-Forw > > BV> message. Remove the text above about the “Relay Agent Remote-ID > > BV> option” and replace “The relay, based on local knowledge and > > BV> policies, includes in the Relay-Forw message the QUAD option > > BV> with the preferred quadrant.” > CB> OK. This also makes sense. > > > 3. The server, upon receiving the forwarded Solicit message > > including a IA_LL option, inspects its content and decide may > > offer an address or addresses for each LLADDR option according > > to its policy. The server sends back an Advertise message with > > an IA_LL option containing an LLADDR option that specifies the > > addresses being offered. This message is sent to the Relay in a > > Relay-reply message. If the server supports the semantics of > > the preferred quadrant included in the Relay Agent Remote-ID > > Option, and manages a block of addresses belonging to the > > requested quadrant, then the addresses being offered SHOULD > > belong to the requested quadrant. > > BV> Here, replace the Relay Agent Remote-ID option with the QUAD option. > CB> OK. > > > 4. The relay sends the received Advertise message to the client. > > > > 5. The client waits for available servers to send Advertise > > responses and picks one server as defined in Section 18.2.9 of > > [RFC8415]. The client then sends a Request message that > > includes the IA_LL container option with the LLADDR option > > copied from the Advertise message sent by the chosen server. > > > > 6. The relay forwards the received Request in a Relay-forw message. > > It adds in the Relay-forw a quad IA-LL-option with the preferred > > quadrant. > > BV> See step 2. > CB> OK. > … > > > > > > 5. DHCPv6 options definitions > > > > 5.1. Quad (IA-LL) option > > > > The quad option is used to specify the preferences for the selected > > quadrants within an IA_LL. The option must be encapsulated in the > > IA_LL-options field of an IA_LL option. > > > > BV> And, it can also be in a Relay-Forw message!!! So, “The option must > > BV> either be encapsulated in the IA-LL-options field of an IA_LL option > > BV> or in a Relay-Forw message in the options field. It MAY also be in > > BV> a Relay-Reply if the QUAD option code was specified in a ERO option > > BV> [RFC4994]. > CB> OK, thanks a lot for this and all previous good suggestions. We'll include them in the next revision. Carlos > > > - Bernie > > > > *From:* dhcwg <dhcwg-bounces@ietf.org> *On Behalf Of * CARLOS JESUS > BERNARDOS CANO > *Sent:* Tuesday, January 29, 2019 2:33 PM > *To:* dhcwg@ietf.org > *Subject:* [dhcwg] Fwd: I-D Action: > draft-bernardos-dhc-slap-quadrant-00.txt > > > > Hi, > > > > We have submitted a new draft describing DHCP extensions to allow a > client/relay specify which SLAP quadrant to use when requesting a MAC > address/set of addresses. > > > > Comments are very much appreciated. > > > > Thanks, > > > > Carlos > > > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: Tue, 29 Jan 2019 at 07:43 > Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt > To: <i-d-announce@ietf.org> > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SLAP quadrant selection options for DHCPv6 > Authors : Carlos J. Bernardos > Alain Mourad > Filename : draft-bernardos-dhc-slap-quadrant-00.txt > Pages : 14 > Date : 2019-01-28 > > Abstract: > The IEEE originally structured the 48-bit MAC address space in such a > way that half of it was reserved for local use. Recently, the IEEE > has been working on a new specification (IEEE 802c) which defines a > new "optional Structured Local Address Plan" (SLAP) that specifies > different assignment approaches in four specified regions of the > local MAC address space. > > The IEEE is working on mechanisms to allocate addresses in the one of > these quadrants (IEEE 802.1CQ). There is work also in the IETF > working on specifying new mechanism that extends DHCPv6 operation to > handle the local MAC address assignments. In this document, we > complement this IETF work by defining a mechanism to allow choosing > the SLAP quadrant to use in the allocation of the MAC address to the > requesting terminal/client. > > This document proposes extensions to DHCPv6 protocols to enable a > DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant > to the server, so that the server allocates correspondingly the MAC > address to the given client or relay. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bernardos-dhc-slap-quadrant/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-bernardos-dhc-slap-quadrant-00 > https://datatracker.ietf.org/doc/html/draft-bernardos-dhc-slap-quadrant-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- > > Sent from a mobile device, please excuse any brevity or typing errors. >
- [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)