From yusuke.doi@toshiba.co.jp Thu Aug 1 01:11:44 2013 Return-Path: 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 8F03A21F849C for ; Thu, 1 Aug 2013 01:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEIIDzBpp0TM for ; Thu, 1 Aug 2013 01:11:38 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 137B521F880F for ; Thu, 1 Aug 2013 01:11:35 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r718BZRR012130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Aug 2013 17:11:35 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r718BZVm008947 for ; Thu, 1 Aug 2013 17:11:35 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 545 for ; Thu, 1 Aug 2013 17:11:34 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r718BYO7008936 for ; Thu, 1 Aug 2013 17:11:34 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r718BYcA015759 for dhcwg@ietf.org; Thu, 1 Aug 2013 17:11:34 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id TAA15747; Thu, 1 Aug 2013 17:11:34 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r718BYb4026261 for ; Thu, 1 Aug 2013 17:11:34 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r718BX87024719; Thu, 1 Aug 2013 17:11:33 +0900 (JST) Received: from [133.199.146.120] (ivpn-6-120.mobile.toshiba.co.jp [133.199.146.120]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 4892497D65 for ; Thu, 1 Aug 2013 17:11:33 +0900 (JST) Message-ID: <51FA1832.6050004@toshiba.co.jp> Date: Thu, 01 Aug 2013 17:11:30 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dhcwg@ietf.org References: <51F7E77C.5090607@toshiba.co.jp> In-Reply-To: <51F7E77C.5090607@toshiba.co.jp> X-Forwarded-Message-Id: <51F7E77C.5090607@toshiba.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dhcwg] Fwd: [Roll] Request for Review: Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:11:44 -0000 Dear dhc folks, Just FYI, here is a proposed individual I-D proposed to roll WG. I believe it does not make any harm to current DHCP infrastructure because this is another stateless option to distribute data among nodes. It's still in early stage and will be updated to satisfy the option guideline document. Any feedbacks are welcome. Regards, Yusuke -------- Original Message -------- Subject: [Roll] Request for Review: Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt Date: Wed, 31 Jul 2013 01:19:08 +0900 From: Yusuke DOI Reply-To: Routing Over Low power and Lossy networks To: roll@ietf.org Dear roll folks, I (and Matt Gillmore) have a proposal to make MPL configuration over DHCP option. I'm on the IETF meeting so I really appriciate if anyone can take a quick review on it and/or have F2F discussion. We're thinking of thousands of nodes under a LLNs. And we identified configuration of MPL parameters is one of missing pieces for manageable large scale LLN. Regards, Yusuke -------- Original Message -------- Subject: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt Date: Mon, 29 Jul 2013 08:25:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPL Parameter Configuration Option for DHCPv6 Author(s) : Yusuke Doi Matthew Gillmore Filename : draft-doi-roll-mpl-parameter-configuration-02.txt Pages : 8 Date : 2013-07-29 Abstract: This draft is to define a way to configure MPL parameter via DHCPv6 option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-doi-roll-mpl-parameter-configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-doi-roll-mpl-parameter-configuration-02 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Francis.Dupont@fdupont.fr Thu Aug 1 01:11:55 2013 Return-Path: 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 8DD9221F9ADA for ; Thu, 1 Aug 2013 01:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyWoEPkCWJ0a for ; Thu, 1 Aug 2013 01:11:54 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 857BC21F9ABB for ; Thu, 1 Aug 2013 01:11:51 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r718Bo0t042931 for ; Thu, 1 Aug 2013 10:11:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308010811.r718Bo0t042931@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Thu, 01 Aug 2013 10:11:50 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:11:55 -0000 First I am explaining my comment at the dhc/sunset4 meeting yesterday: "DHCPv4 is not really over UDP/IP" What I mean is no genuine IPv4 stack is able to send or receive a DISCOVER message from a booting device: this message has the format of an UDP/IPv4/ethernet-like packet but has only the format. Note this is not true for DHCPv6: constrained DHCPv6 messages are real link-local multicast messages. This can introduce anoying limitations but they can be sent or received by any standard IPv6 stack, when DHCPv4 requires handling of some messages at the ethernet-like link layer (vs IP network layer). To come back to v4configuration candidates: - first I have no concern against DHCPv6 over DHCPv4 other than it is not yet implemented and I am afraid it will not be so easy to implement. But it provides better integration, have to obvious reason to fail to work, etc, so I agree it is the best solution *on the paper*. - to extend DHCPv6 is a sure way to mess it so I agree this solution must be rejected. - DHCPv4 over softwire works well if all nodes already have IPv4 addresses. If they have none one enters in difficulties which are IMHO the direct consequence of the "DHCPv4 is not really over UDP/IP". So if the requirements include to asignment of IPv4 addresses to nodes without one (and they should include this) then the DHCPv4 over softwire is not a good solution. Another point is DHCPv4 over softwire can require a ALG (Application Level Gateway) at the server exit point in order to provide the IPv6 address (or any topological ID) to the DHCPv4 server. - DHCPv4 over IPv6: I know it pretty well as I implemented it (note that I am not particularly in favor of it, I am too old to fall into this, but it is not a reason to not correct some facts about it). DHCPv4 over IPv6 has 2 central ideas: first is to give the possibility to use an *unmodified* DHCPv4 client (to provide this feature is the role of the CRA), second is to give the possibility to use a lightly modified DHCPv4 server (to provide this feature is the role of the TRA and the CRA6ADDR relay option). BTW as the DHCPv4 can't be attached directly to the client link "by definition", a relay option is required to give to the server the topological position of the client, so the CRA6ADDR option can't be avoid and its support is the only required change in the DHCPv4 server in the deployment with a TRA case. Implementing and testing DHCPv4 over IPv6 I found 3 issues: * first without care (i.e., check of the link layer address) a CRA will relay all DISCOVERs from booting nodes, so with N CRA and M booting nodes you get N * M copies. This was fixed in the spec with the HCRA / LCRA notion. A more anoying issue is what happens when a client renews its leased address: it tries first to send a request to the server over IPv4 using the server ID. There are two ways to solve this: * put a 0.0.0.0 in the server ID but this is forbidden by DHCPv4 spec, disable server selection and is refused by some clients. * put a not-routable address in the server ID: it is compliant, still provide server selection and works because clients will fall back to broadcast DISCOVER, i.e., it just de-optimizes the renewal mechanism. Note one must not allow the renew message to reach the DHCPv4 server because the topological info added by a relay is required. The last issue was from the fully incorrect/... support of SO_REUSEADDR by Linux which makes impossible to run some DHCPv4 servers on the same node than a DHCPv4 over IPv6 client and CRA. Note the last 2 points are direct consequences of the idea to reuse DHCPv4 clients, with other words they are drawbacks from the DHCPv4 over IPv6 simplicity. To finish it is not hard to modify a DHCPv4+DHCPv6 server code to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6 or even both over IPv6 and IPv4. The idea is to plug the IPv6 I/O subsystem to the DHCPv6 handler. IMHO it should not be significanly different (i.e., harder / easier) to support DHCPv6 over DHCPv4 (note this is for the server code). Regards Francis.Dupont@fdupont.fr PS for moderator: I tried to submit this first from a wrong address so I canceled it and you should not have to do something. Sorry for my mistake. From swmike@swm.pp.se Thu Aug 1 02:32:49 2013 Return-Path: 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 ED8DF21F8F24 for ; Thu, 1 Aug 2013 02:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSFFyAsJydKD for ; Thu, 1 Aug 2013 02:32:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 246DB21F9D8A for ; Thu, 1 Aug 2013 02:32:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9FBCB9C; Thu, 1 Aug 2013 11:31:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9A9829A for ; Thu, 1 Aug 2013 11:31:50 +0200 (CEST) Date: Thu, 1 Aug 2013 11:31:50 +0200 (CEST) From: Mikael Abrahamsson To: "dhcwg@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:32:50 -0000 On Fri, 7 Jun 2013, Prashanth Patil (praspati) wrote: > Hi all, > This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay > Agent can dynamically influence priority of DNS servers provided to a > host, so that a host can use an optimal DNS server for resolution. I feel this proposal have two problems in my opinion: I don't like "flags" that means the server responds differently with the same field. This means there must be server-side logic to handle the different cases. I believe other solutions which work with a static server-side configuration file without "if/then/else"-statements are preferred. I don't like the chattyness of the proposed solution, where if a client goes between different states of dualstacked-ness, it needs to talk DHCP every time. As I see it, it also doesn't address an additional problem, where if the client has gotten DNS resolvers from both DHCPv4 and DHCPv6, there currently is no sure way to know what the client will use (I know for a fact that different android phones from different vendors behave differently). If we're going to enhance this, it would be beneficial if this case would also be solved. So I propose a change of the solution where the client would initially ask the following: What resolver should I use if I am single stacked IPv6. What resolver should I use if I am dual stacked, and also please tell me if there is a preference if this resolver is better, same or worse than any other resolver I might have gotten provisioned any other dynamic way (DHCPv4 comes off my mind). I am not knowledable about DHCP to know what the best way to actually implement this, but from an operational point of view, I would really like to see the above goals be achieved if we're enhancing the DHCPv6 client and host stack behaviour anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se From mellon@fugue.com Thu Aug 1 02:33:49 2013 Return-Path: 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 E76E221F9F7F for ; Thu, 1 Aug 2013 02:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ypPAbKsqZnd for ; Thu, 1 Aug 2013 02:33:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A253F21F9E95 for ; Thu, 1 Aug 2013 02:33:35 -0700 (PDT) Received: from [IPv6:2001:df8:1:64:d141:a81f:a5a0:819b] (unknown [IPv6:2001:df8:1:64:d141:a81f:a5a0:819b]) by toccata.fugue.com (Postfix) with ESMTPSA id 1CDE223802B7 for ; Thu, 1 Aug 2013 05:33:32 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 1 Aug 2013 11:33:30 +0200 To: " WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dhcwg] On the topic of consensus... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:33:50 -0000 I should say that the consensus that we had wasn't finalized by the = production of a document that passed working group last call. That's = why we're talking about Branimir's document. I think it's important = that the document not create additional confusion, and indeed we could, = as a working group, decide to go with option 5 rather than = DHCPv4overDHCPv6. If there is a sincere desire to reopen that issue, I can't, as an AD, = tell you you are not allowed to do it. When/if the chairs do a WGLC on = Branimir's document, they are opening the floor up to a reconsideration = of the consensus that I claimed had already been determined. If indeed = the consensus comes out differently, it is the consensus from WGLC that = applies, not the consensus that we had in the room in Orlando. The reason I argued so strongly for retaining the consensus we had in = Orlando is purely that I think it was a good consensus, and all the = people (I think) who got up and argued at the microphone today agreed to = it. We all knew about Ole's proposal before we decided that consensus, = although Ole had not yet written it up. This has been a very contentious issue, and I have been involved in it = as an individual contributor, as a working group chair, and as an AD. = I would really appreciate it if we could put it to bed. But if it is = not the consensus of the working group to do so, that is the working = group's choice, not mine. Given the implicit AD hat that I wear, even = when I say I'm not wearing it, I made my point too strongly at the = microphone, and I apologize for that. From Francis.Dupont@fdupont.fr Thu Aug 1 04:30:37 2013 Return-Path: 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 81DB521F8F78 for ; Thu, 1 Aug 2013 04:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcVBRdEY0HDb for ; Thu, 1 Aug 2013 04:30:36 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF2821F9C98 for ; Thu, 1 Aug 2013 04:30:34 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r71BUXm3054957 for ; Thu, 1 Aug 2013 13:30:33 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308011130.r71BUXm3054957@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Thu, 01 Aug 2013 13:30:33 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [dhcwg] about v4configuration and co (2) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:30:37 -0000 Review of draft-ietf-dhc-v4configuration-01.txt IMHO the introduction (section 1) should be clearer about the fact one of the needed function is the ability to assign an IPv4 address to a node without one, the so called 'booting node'. This makes a difference for the applicability of DHCPv4oSW. To be complete all proposed mechanisms have the hidden requirement that this function is available only after IPv6 address (and often other DHCPv6 parameters) assignment (/ provisioning). 1.2. DHCPv4o6 Based Provisioning - Functional Overview The DHCPv4o6 server must either provide an IPv6 interface to the client, or an intermediary 'Transport Relay Agent' device can act as the gateway between the IPv4 and IPv6 domains. => either supposes exclusivity: it is possible to provide both a DHCPv4o6 (aka TSV) and CRA6ADDR capable legacy DHCPv4 server functions in the same process. So s/either// For the dynamic allocation of IPv4 addresses, the DHCPv4o6 server needs to be extended to support the new functionality, such as storing the IPv6 address of DHCPv4o6 clients. The CRA6ADDR option must also be implemented. => the text is unclear: the last statement applies only to DHCPv4o6 capable (so in fact CRA6ADDR capable) legacy DHCPv4 server. I.e., the "also" must be replaced by the same ", or" than in the previous paragraph. This approach currently uses functional elements for ingress and egress of the IPv6-only transport domain--the CRA on the host and the TRA or TSV on the server. As a result, this approach has sometimes been referred to as a tunneling approach. However, relay agent encapsulation is not a tunnel, since it carries only DHCP traffic; it would be more accurate to describe it as an encapsulation. => you can replace tunnel by encapsulation this doesn't change the fact it is a transport mechanism, not a tunnel nor an encapsulation one. It is worth noting that there is no technical reason for using relay encapsulation for DHCPv4o6; this approach was taken because the authors of the draft originally imagined that it might be used to provide configuration information for an unmodified DHCPv4 client. => I deeply disagree: as the DHCPv4 server is not attached directly the client link there must be a relay information added to queries from clients so the server knows where are clients and where to send back responses. This has nothing to do with the analysed problem, in fact it is simply the basis of what is a DHCPv4 relay for after the simple "DHCPv4 packets don't go through routers". Given that this is the case, there is no technical reason why DHCPv4o6 can't simply use the IPv6 transport directly, without any relay encapsulation. This would greatly simplify the specification and the implementation, and would still address the requirements stated in this document. => there is a technical reason which is obvious to anyone who worked with DHCP relays (which I have to confess are incredibly bad documented so I understand well why you missed this point). 1.3. DHCPv6 Based Provisioning - Functional Overview => two comments: first the IPv4 address assignment feature is critical here as it supposes a massive change (aka mess in the case :-) in DHCPv6, second it should make clearer we DO NOT WANT this (with this being DHCPv6 extended to provide all DHCPv4 features including IPv4 address assignment). 1.4. DHCPv4oSW Based Provisioning - Functional Overview Any additional IPv4 configuration parameters which are required are then provisioned using a DHCPv4 messages transported within IPv6 in the configured softwire in the same manner as any other IPv4 based traffic. => as I explained before it doesn't work because DHCPv4 is not really over UDP/IP. With other words without a lot of dedicated hacking there is no chance for a booting node DISCOVER to go through a tunnel... On receipt at the tunnel concentrator (e.g. MAP Border Router or a Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the softwire and forwarded to the DHCPv4 server in the same way as any other IPv4 packet is handled. => in fact this statement is wrong: the DHCPv4 server must get the IPv6 address so it can identify where is the client and know how to send back responses. Note in softwire it is common to have many nodes on the client sides (note the 's') with the same (private) IPv4 address, for instance in DS-Lite all B4 (aka CPE aka HG) have the same IPv4 address... the messages exchanged between the DHCPv4 client and server would be strictly DHCPINFORM/DHCPACK messages, for the configuration of additional IPv4 parameters. => note DHCPv4oSW works perfectly for this but this is only a part of what is needed. And if another message type is handled it likely makes a lot of trouble to another mechanism. Broadcast based DHCPDISCOVER messages can not be transported as they are not compatible with the softwire architecture. => I fully agree but this must be the first statement in the section! From a transport perspective, the key difference between this method and DHCPv4o6 (described above) is that here, the DHCPv4 message is put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead of directly placing the DHCPv4 message into UDPv6 and IPv6. => yes, it is tunnelling/encapsulation and not transport. Currently, this approach is only theoretical and does not have a corresponding Internet Draft providing more detail. => it should stay theorical as it is a partial solution and doesn't provide something not already available from full solutions. 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview These messages types must be implemented in both the DHCPv4oDHCPv6 client and server. => this is IMHO the critical difference between DHCPv4oDHCPv6 and DHCPv4o6: DHCPv4o6 implies one or two very easy to implement relays to switch between IPv4 and IPv6 transports, DHCPv4oDHCPv6 requires a major change in the client. Of course this has many benefits, for instance the DHCPv4oDHCPv6 client should be an integrated DHCPv4 *and* DHCPv6 client. 2. Requirements for the Solution Evaluation 4. Enable the separation of IPv4 and IPv6 host configuration infrastructure, i.e. independent DHCPv4 and DHCPv6 servers. => I can't see how 4 can be made impossible. 3. Comparison of the Four Approaches The table below shows a comparison of how the different approaches meet the solution requirements described above. +----------+----------+--------+-----------+---------------+ | Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 | +----------+----------+--------+-----------+---------------+ | 1 | No | Yes | No | Yes | | 2 | Yes | No | Yes | Yes | | 3 | Yes | No | No | Yes | | 4 | Yes | No | Yes | Yes | | 5 | Yes | No | Yes | Yes | | 6 | No | No | Yes | Yes | +----------+----------+--------+-----------+---------------+ => note the table is not consistent with the given detailed pros/cons in this document (pros/cons I disagree for some too) 3.2. DHCPv4o6 Based Provisioning 3.2.1. Pros 1. Once implemented, all existing DHCPv4 options will be available with no further ongoing development work necessary. => note DHCPv4o6 is already (at least twice) implemented, so future -> present. 3. Easy to implement through minor adaptation of existing DHCPv4 client/server code. => s/client/relay/ 4. Simple, in that no additional functional elements are necessary except the DHCPv4o6 client and server. The Transport Relay Agent is completely optional. => client -> CRA. It is true the TRA is optional but you need at least a TRA or a TSV. 6. Implementations already exist, proving that the approach works. => so why the 1. wording? And BTW it makes late surprises very unlikely. 3.2.2. Cons 1. More complex, in that there are more new functional elements (CRA, DHCPv4o6 server and optionally TRA) within the architecture than are necessary in DHCPv6 based provisioning. => I don't understand this statement, in particular compared to the DHCPv4oDHCPv6 one. 2. A new DHCPv6 option is necessary in order to provision the IPv6 address of the DHCPv4 server to the end device. => s/option/relay sub-option/ and it is needed only with TRA (I have a presentation concern here: you should not write a constraint from an option applies to the whole mechanism: it is more than unfair). 3. For a Host CRA (HCRA), DHCPv4 client host needs to be updated to implement the IPv6 encapsulation and decapsulation function. => I can't parse the wording: what I believe it should mean is with a HCRA the DHCPv4 client host must run a HCRA (which is a tautology). It can be parsed too as the HCRA function must be included in the DHCPv4 client software which is *not* true. Otherwise a physically separate On-Link CRA (LCRA) functional element must be deployed. => "physically separate" is not a requirement. 5. The DHCPv4 server needs to be updated to implement new DHCPv4o6 functionality. => the CRA6ADDR capable code is 20 lines of very straightforward code (just a new relay sub-option in a space which is already well handled in a DHCPv4+DHCPv6 code) so the burden is just "needs to be updated". 3.4. DHCPv4oDHCPv6 Based Provisioning 3.4.2. Cons 1. More complex, in that there are more new functional elements within the architecture than are necessary in DHCPv6 based provisioning. 2. DHCPv6 clients needs to be updated to implement the new DHCPv6 message types (BOOTPREQUESTv6 and BOOTPREPLYv6). 3. The DHCPv6 server needs to be updated to implement new DHCPv4oDHCPv6 message types and functionality. => given these how you can put a No in row 1 of the table??? 5. The approach is currently unproven as no existing implementations exist. => IMHO it is the main drawback of this solution (fortunately it has a known way to solve :-) 4. Conclusion The dynamic leasing of IPv4 addresses is fundamental to the efficient use of remaining IPv4 resources. This will become increasingly important in the future, so a mechanism which supports this is necessary. DHCPv4oSW does not provide this function and so is not recommended. => IMHO this must be in the introduction too! The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 functionality) for all deployment scenarios, even when DHCPv4 specific functionality is not required by the operator. => I don't understand this: if you don't want DHCPv4 you don't need a DHPv4* server? Therefore, this memo recommends DHCPv4oDHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for provisioning IPv4 parameters over an IPv6 only network. => IMHO such a recommendation can be done *only after* two independent (and interworking) implementations of this solution. 6. Security Considerations => I can't accept empty security considerations (and I am far to be alone in this case). And it is not clear proposed solutions are so security neutral. Regards Francis.Dupont@fdupont.fr PS: the softwire part was written before the discussion about O. Troan's proposal. From volz@cisco.com Thu Aug 1 04:34:54 2013 Return-Path: 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 436F521E80BC for ; Thu, 1 Aug 2013 04:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQYUw58j-Z3s for ; Thu, 1 Aug 2013 04:34:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCCA21F97E6 for ; Thu, 1 Aug 2013 04:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2587; q=dns/txt; s=iport; t=1375356889; x=1376566489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XLX7+3ijIp3yPrM5G40knNBwAF5VugMxgnXJrAeZmz4=; b=m3COeP1kWVsOnLpa7WtuusPazikCO9orfbNNseiXgkM4tW7BRu5mEprw jeu6+Ps4zUqO6mAnU0SEuX1RIdPxPdxHlp71YkxMQMhBSixwkOrBguMRv 4qSHCskQEJMT2Ij2aB2ZVGt3PGre6Q2jM0htYV9PCQmxQHnU8WEMuAodX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMZG+lGtJXG//2dsb2JhbABbgwY1vxeBHxZ0giQBAQEDAQEBATc0CQIFCwIBCA4KHhAnCxwJAgQOBRuHbwYMuTQEjj+BFTMHgxlzA5dfkU6BW4E5gXE X-IronPort-AV: E=Sophos;i="4.89,793,1367971200"; d="scan'208";a="242235239" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2013 11:34:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r71BYieF010393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 11:34:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 06:34:44 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson Thread-Topic: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOjppbACGe8kbAvEmDosd7oq1ej5mAOQhC Date: Thu, 1 Aug 2013 11:34:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:34:54 -0000 There were a lot of issues raised at the joint Sunset4/DHC session Wed afte= rnoon. It will be interesting to see what the authors of the draft will do = to address these. (That's not to say the other issues should not be raised.= ) We will wait to see if the authors continue this work (by addressing issues= in a new draft). - Bernie (from iPhone) On Aug 1, 2013, at 11:34 AM, "Mikael Abrahamsson" wrote: > On Fri, 7 Jun 2013, Prashanth Patil (praspati) wrote: >=20 >> Hi all, >> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Rela= y >> Agent can dynamically influence priority of DNS servers provided to a >> host, so that a host can use an optimal DNS server for resolution. >=20 > I feel this proposal have two problems in my opinion: >=20 > I don't like "flags" that means the server responds differently with the = same field. This means there must be server-side logic to handle the differ= ent cases. I believe other solutions which work with a static server-side c= onfiguration file without "if/then/else"-statements are preferred. >=20 > I don't like the chattyness of the proposed solution, where if a client g= oes between different states of dualstacked-ness, it needs to talk DHCP eve= ry time. >=20 > As I see it, it also doesn't address an additional problem, where if the = client has gotten DNS resolvers from both DHCPv4 and DHCPv6, there currentl= y is no sure way to know what the client will use (I know for a fact that d= ifferent android phones from different vendors behave differently). If we'r= e going to enhance this, it would be beneficial if this case would also be = solved. >=20 > So I propose a change of the solution where the client would initially as= k the following: >=20 > What resolver should I use if I am single stacked IPv6. > What resolver should I use if I am dual stacked, and also please tell me = if there is a preference if this resolver is better, same or worse than any= other resolver I might have gotten provisioned any other dynamic way (DHCP= v4 comes off my mind). >=20 > I am not knowledable about DHCP to know what the best way to actually imp= lement this, but from an operational point of view, I would really like to = see the above goals be achieved if we're enhancing the DHCPv6 client and ho= st stack behaviour anyway. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From praspati@cisco.com Thu Aug 1 08:51:27 2013 Return-Path: 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 5B82221E8195 for ; Thu, 1 Aug 2013 08:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS3yf-ojfyu5 for ; Thu, 1 Aug 2013 08:51:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6C21E818D for ; Thu, 1 Aug 2013 08:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2997; q=dns/txt; s=iport; t=1375372281; x=1376581881; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Bz4vEFmx2ZJpQ0IbERlj9IKIIluA75/KfYwSTZedn6U=; b=bGLkSmclDFK3aYYz17Zg0I3zDRnYWEIDtVoQi+DiVs+e5/0SgnLSJiWN s6Z6LzGTaXOHHAvMamSFhweUR1MRmIW8FamdVZI4oo0OwSnaliEW69pWp pQXBLf1pDI+03KYuiA3es097ewh97G0YKTJyAmbnuTSo+rtwe45r3bmx5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEGD+lGtJV2a/2dsb2JhbABbgwY1UL5HgR0WdIIkAQEBBAEBATc0CQISAQgYChQ3CxwJAgQBDQUIE4d1DLoYBI4/gRcxB4MZcwOpLYFbgTmBcTk X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="scan'208";a="242325960" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2013 15:51:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r71FpKjT013192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 15:51:20 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 10:51:20 -0500 From: "Prashanth Patil (praspati)" To: "Bernie Volz (volz)" , Mikael Abrahamsson Thread-Topic: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOjs729UALGIVfFEmPJoU9Kl4stg== Date: Thu, 1 Aug 2013 15:51:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.61.213.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:51:27 -0000 On 01/08/13 5:04 PM, "Bernie Volz (volz)" wrote: >There were a lot of issues raised at the joint Sunset4/DHC session Wed >afternoon. It will be interesting to see what the authors of the draft >will do to address these. (That's not to say the other issues should not >be raised.) > >We will wait to see if the authors continue this work (by addressing >issues in a new draft). Yes, we plan to work on a revision that makes the draft more generic and also possibly address issues raised in sunset4 and on the mailing list. -Prashanth > >- Bernie (from iPhone) > >On Aug 1, 2013, at 11:34 AM, "Mikael Abrahamsson" >wrote: > >> On Fri, 7 Jun 2013, Prashanth Patil (praspati) wrote: >>=20 >>> Hi all, >>> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 >>>Relay >>> Agent can dynamically influence priority of DNS servers provided to a >>> host, so that a host can use an optimal DNS server for resolution. >>=20 >> I feel this proposal have two problems in my opinion: >>=20 >> I don't like "flags" that means the server responds differently with >>the same field. This means there must be server-side logic to handle the >>different cases. I believe other solutions which work with a static >>server-side configuration file without "if/then/else"-statements are >>preferred. >>=20 >> I don't like the chattyness of the proposed solution, where if a client >>goes between different states of dualstacked-ness, it needs to talk DHCP >>every time. >>=20 >> As I see it, it also doesn't address an additional problem, where if >>the client has gotten DNS resolvers from both DHCPv4 and DHCPv6, there >>currently is no sure way to know what the client will use (I know for a >>fact that different android phones from different vendors behave >>differently). If we're going to enhance this, it would be beneficial if >>this case would also be solved. >>=20 >> So I propose a change of the solution where the client would initially >>ask the following: >>=20 >> What resolver should I use if I am single stacked IPv6. >> What resolver should I use if I am dual stacked, and also please tell >>me if there is a preference if this resolver is better, same or worse >>than any other resolver I might have gotten provisioned any other >>dynamic way (DHCPv4 comes off my mind). >>=20 >> I am not knowledable about DHCP to know what the best way to actually >>implement this, but from an operational point of view, I would really >>like to see the above goals be achieved if we're enhancing the DHCPv6 >>client and host stack behaviour anyway. >>=20 >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Aug 1 09:01:11 2013 Return-Path: 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 93CBB21E8124 for ; Thu, 1 Aug 2013 09:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rENFldGX1Qtq for ; Thu, 1 Aug 2013 09:01:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9904921E8153 for ; Thu, 1 Aug 2013 09:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3369; q=dns/txt; s=iport; t=1375372858; x=1376582458; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y9RWn5Ao6vuD9A85I8O9GwddT+WuLHHE6xqkiMWpQuk=; b=AwIXp/6f5DB1dyDHWq7WIquK7aDmLJeA/mtcDQ8wXNRcc9bXhl8EaeBu rbR8YAQMEQYnylFYQHooOp2oEyCaw5NYR0G2/VdRJOUpdXCzu8gKXZUxj rxqG2cw1Rm/R763bqUMuY0Y1cRWlQWBZcv7TIN9IbokRj/33ZuoJAj5xv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFiF+lGtJXG//2dsb2JhbABbgwY1RL5TgR0WdIIkAQEBAwEBAQE3NAkCEAIBCBgeECcLHAkCBA4FG4dvBgy6EgSOP4EVMweDGXMDl1+RToFbgTmBcQ X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="scan'208";a="242319360" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2013 16:00:56 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r71G0uAA009286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 16:00:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 11:00:55 -0500 From: "Bernie Volz (volz)" To: "Prashanth Patil (praspati)" Thread-Topic: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOjppbACGe8kbAvEmDosd7oq1ej5mAOQhCgACbgYD//67e6w== Date: Thu, 1 Aug 2013 16:00:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:01:11 -0000 Sorry that we ran out of time at DHC wg today, but I think you got plenty o= f feedback in Sunset4. - Bernie (from iPad) On Aug 1, 2013, at 11:51 AM, "Prashanth Patil (praspati)" wrote: >=20 > On 01/08/13 5:04 PM, "Bernie Volz (volz)" wrote: >=20 >> There were a lot of issues raised at the joint Sunset4/DHC session Wed >> afternoon. It will be interesting to see what the authors of the draft >> will do to address these. (That's not to say the other issues should not >> be raised.) >>=20 >> We will wait to see if the authors continue this work (by addressing >> issues in a new draft). >=20 > Yes, we plan to work on a revision that makes the draft more generic and > also possibly address issues raised in sunset4 and on the mailing list. >=20 > -Prashanth >=20 >=20 >>=20 >> - Bernie (from iPhone) >>=20 >> On Aug 1, 2013, at 11:34 AM, "Mikael Abrahamsson" >> wrote: >>=20 >>> On Fri, 7 Jun 2013, Prashanth Patil (praspati) wrote: >>>=20 >>>> Hi all, >>>> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 >>>> Relay >>>> Agent can dynamically influence priority of DNS servers provided to a >>>> host, so that a host can use an optimal DNS server for resolution. >>>=20 >>> I feel this proposal have two problems in my opinion: >>>=20 >>> I don't like "flags" that means the server responds differently with >>> the same field. This means there must be server-side logic to handle th= e >>> different cases. I believe other solutions which work with a static >>> server-side configuration file without "if/then/else"-statements are >>> preferred. >>>=20 >>> I don't like the chattyness of the proposed solution, where if a client >>> goes between different states of dualstacked-ness, it needs to talk DHC= P >>> every time. >>>=20 >>> As I see it, it also doesn't address an additional problem, where if >>> the client has gotten DNS resolvers from both DHCPv4 and DHCPv6, there >>> currently is no sure way to know what the client will use (I know for a >>> fact that different android phones from different vendors behave >>> differently). If we're going to enhance this, it would be beneficial if >>> this case would also be solved. >>>=20 >>> So I propose a change of the solution where the client would initially >>> ask the following: >>>=20 >>> What resolver should I use if I am single stacked IPv6. >>> What resolver should I use if I am dual stacked, and also please tell >>> me if there is a preference if this resolver is better, same or worse >>> than any other resolver I might have gotten provisioned any other >>> dynamic way (DHCPv4 comes off my mind). >>>=20 >>> I am not knowledable about DHCP to know what the best way to actually >>> implement this, but from an operational point of view, I would really >>> like to see the above goals be achieved if we're enhancing the DHCPv6 >>> client and host stack behaviour anyway. >>>=20 >>> --=20 >>> Mikael Abrahamsson email: swmike@swm.pp.se >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From mohamed.boucadair@orange.com Mon Aug 5 06:35:02 2013 Return-Path: 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 E969E21F9D71 for ; Mon, 5 Aug 2013 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYN4iFnF4i9P for ; Mon, 5 Aug 2013 06:34:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91421F9DA1 for ; Mon, 5 Aug 2013 06:34:57 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0DA9318CF2C for ; Mon, 5 Aug 2013 15:34:57 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EAF0127C0DF for ; Mon, 5 Aug 2013 15:34:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 5 Aug 2013 15:34:56 +0200 From: To: "dhcwg@ietf.org" Date: Mon, 5 Aug 2013 15:34:55 +0200 Thread-Topic: I-D Action: draft-boucadair-rfc6153-update-00.txt Thread-Index: Ac6PVv7CBXtTbrrPTDOkJXEYF35yLgCiW/8w Message-ID: <94C682931C08B048B7A8645303FDC9F36EE99C8F86@PUEXCB1B.nanterre.francetelecom.fr> References: <20130802080429.18304.3578.idtracker@ietfa.amsl.com> In-Reply-To: <20130802080429.18304.3578.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Subject: [dhcwg] TR: I-D Action: draft-boucadair-rfc6153-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 13:35:02 -0000 FYI. -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: vendredi 2 ao=FBt 2013 10:04 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-rfc6153-update-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Updates to DHCPv4 and DHCPv6 Options for Access Network = Discovery and Selection Function (ANDSF) Discovery Author(s) : Mohamed Boucadair Filename : draft-boucadair-rfc6153-update-00.txt Pages : 4 Date : 2013-08-02 Abstract: This document updates RFC 6153 by correcting IANA allocations made for DHCPv4 and DHCPv6 options for Access Network Discovery and Selection Function (ANDSF) Discovery. This document assigns a code for DHCPv6 option for ANDSF and withdraws an already assigned DHCPv4 option code. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-rfc6153-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-rfc6153-update-00 Please note that it may take a couple of minutes from the time of submissio= n 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 From otroan@employees.org Tue Aug 6 04:22:11 2013 Return-Path: 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 6102921F9D7B for ; Tue, 6 Aug 2013 04:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmNhbIuWBZUn for ; Tue, 6 Aug 2013 04:22:10 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5621F9E26 for ; Tue, 6 Aug 2013 04:21:59 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-74.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id E43BB5EEC; Tue, 6 Aug 2013 04:21:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <201308010811.r718Bo0t042931@givry.fdupont.fr> Date: Tue, 6 Aug 2013 13:21:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34B56CCB-04C1-46E5-9CE2-B588994B9645@employees.org> References: <201308010811.r718Bo0t042931@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:22:11 -0000 Francis, > First I am explaining my comment at the dhc/sunset4 meeting yesterday: > "DHCPv4 is not really over UDP/IP" > What I mean is no genuine IPv4 stack is able to send or receive > a DISCOVER message from a booting device: this message has the > format of an UDP/IPv4/ethernet-like packet but has only the format. can you explain what you mean by "DHCPv4 is not really over UDP/IP"? > Note this is not true for DHCPv6: constrained DHCPv6 messages > are real link-local multicast messages. This can introduce > anoying limitations but they can be sent or received by any > standard IPv6 stack, when DHCPv4 requires handling of some messages > at the ethernet-like link layer (vs IP network layer). >=20 > To come back to v4configuration candidates: >=20 > - first I have no concern against DHCPv6 over DHCPv4 other than it is > not yet implemented and I am afraid it will not be so easy to > implement. But it provides better integration, have to obvious > reason to fail to work, etc, so I agree it is the best solution *on > the paper*. >=20 > - to extend DHCPv6 is a sure way to mess it so I agree this solution > must be rejected. >=20 > - DHCPv4 over softwire works well if all nodes already have IPv4 > addresses. If they have none one enters in difficulties which are > IMHO the direct consequence of the "DHCPv4 is not really over > UDP/IP". So if the requirements include to asignment of IPv4 > addresses to nodes without one (and they should include this) then > the DHCPv4 over softwire is not a good solution. > Another point is DHCPv4 over softwire can require a ALG (Application > Level Gateway) at the server exit point in order to provide the > IPv6 address (or any topological ID) to the DHCPv4 server. I tested DHCPv4 over a softwire with my favourite implementation and = that worked out of the box. DHCPv4 in that it uses broadcast requires a link-layer that supports = broadcast. given that a softwire is a p2p link, it does support broadcast (and = multicast). > - DHCPv4 over IPv6: I know it pretty well as I implemented it > (note that I am not particularly in favor of it, I am too old > to fall into this, but it is not a reason to not correct some > facts about it). > DHCPv4 over IPv6 has 2 central ideas: first is to give the > possibility to use an *unmodified* DHCPv4 client (to provide > this feature is the role of the CRA), second is to give the > possibility to use a lightly modified DHCPv4 server (to provide > this feature is the role of the TRA and the CRA6ADDR relay option). >=20 > BTW as the DHCPv4 can't be attached directly to the client link > "by definition", a relay option is required to give to the server > the topological position of the client, so the CRA6ADDR option > can't be avoid and its support is the only required change in > the DHCPv4 server in the deployment with a TRA case. >=20 > Implementing and testing DHCPv4 over IPv6 I found 3 issues: > * first without care (i.e., check of the link layer address) > a CRA will relay all DISCOVERs from booting nodes, so with N CRA > and M booting nodes you get N * M copies. This was fixed in the > spec with the HCRA / LCRA notion. >=20 > A more anoying issue is what happens when a client renews its > leased address: it tries first to send a request to the server > over IPv4 using the server ID. There are two ways to solve this: > * put a 0.0.0.0 in the server ID but this is forbidden by DHCPv4 > spec, disable server selection and is refused by some clients. > * put a not-routable address in the server ID: it is compliant, > still provide server selection and works because clients will > fall back to broadcast DISCOVER, i.e., it just de-optimizes > the renewal mechanism. > Note one must not allow the renew message to reach the DHCPv4 > server because the topological info added by a relay is required. >=20 > The last issue was from the fully incorrect/... support of > SO_REUSEADDR by Linux which makes impossible to run some > DHCPv4 servers on the same node than a DHCPv4 over IPv6 client > and CRA. >=20 > Note the last 2 points are direct consequences of the idea to > reuse DHCPv4 clients, with other words they are drawbacks from > the DHCPv4 over IPv6 simplicity. >=20 > To finish it is not hard to modify a DHCPv4+DHCPv6 server code > to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6 > or even both over IPv6 and IPv4. The idea is to plug the IPv6 > I/O subsystem to the DHCPv6 handler. IMHO it should not be > significanly different (i.e., harder / easier) to support > DHCPv6 over DHCPv4 (note this is for the server code). just to make my own views clear: - coupling IPv6 and IPv4 provisioning together is a bad idea - I don't think requiring IPv4 specific configuration information on a = softwire is necessary, if you really have to do it I'd prefer for the IPv4 provisioning = protocol to run over the IPv4 data path (aka the softwire). and the same solution = could be used for Public 4over6, LW46, MAP, L2TP... cheers, Ole From ian.farrer@telekom.de Tue Aug 6 06:23:21 2013 Return-Path: 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 4288C21F9EA9 for ; Tue, 6 Aug 2013 06:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+kCLZ0fl0FN for ; Tue, 6 Aug 2013 06:23:17 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 833CD21F9E26 for ; Tue, 6 Aug 2013 06:23:16 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 06 Aug 2013 15:19:31 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 6 Aug 2013 15:19:30 +0200 From: To: , Date: Tue, 6 Aug 2013 15:19:29 +0200 Thread-Topic: [dhcwg] about v4configuration and co (1) Thread-Index: Ac6Sp5S4W1I7DN7YR6WQ1qJBjE1Jvg== Message-ID: In-Reply-To: <34B56CCB-04C1-46E5-9CE2-B588994B9645@employees.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:23:21 -0000 Hi Ole, Comments inline below. Cheers, Ian On 06/08/2013 13:21, "Ole Troan" wrote: >Francis, > >> First I am explaining my comment at the dhc/sunset4 meeting yesterday: >> "DHCPv4 is not really over UDP/IP" >> What I mean is no genuine IPv4 stack is able to send or receive >> a DISCOVER message from a booting device: this message has the >> format of an UDP/IPv4/ethernet-like packet but has only the format. > >can you explain what you mean by "DHCPv4 is not really over UDP/IP"? > >> Note this is not true for DHCPv6: constrained DHCPv6 messages >> are real link-local multicast messages. This can introduce >> anoying limitations but they can be sent or received by any >> standard IPv6 stack, when DHCPv4 requires handling of some messages >> at the ethernet-like link layer (vs IP network layer). >>=20 >> To come back to v4configuration candidates: >>=20 >> - first I have no concern against DHCPv6 over DHCPv4 other than it is >> not yet implemented and I am afraid it will not be so easy to >> implement. But it provides better integration, have to obvious >> reason to fail to work, etc, so I agree it is the best solution *on >> the paper*. >>=20 >> - to extend DHCPv6 is a sure way to mess it so I agree this solution >> must be rejected. >>=20 >> - DHCPv4 over softwire works well if all nodes already have IPv4 >> addresses. If they have none one enters in difficulties which are >> IMHO the direct consequence of the "DHCPv4 is not really over >> UDP/IP". So if the requirements include to asignment of IPv4 >> addresses to nodes without one (and they should include this) then >> the DHCPv4 over softwire is not a good solution. >> Another point is DHCPv4 over softwire can require a ALG (Application >> Level Gateway) at the server exit point in order to provide the >> IPv6 address (or any topological ID) to the DHCPv4 server. > >I tested DHCPv4 over a softwire with my favourite implementation and that >worked out of the box. >DHCPv4 in that it uses broadcast requires a link-layer that supports >broadcast. >given that a softwire is a p2p link, it does support broadcast (and >multicast). > >> - DHCPv4 over IPv6: I know it pretty well as I implemented it >> (note that I am not particularly in favor of it, I am too old >> to fall into this, but it is not a reason to not correct some >> facts about it). >> DHCPv4 over IPv6 has 2 central ideas: first is to give the >> possibility to use an *unmodified* DHCPv4 client (to provide >> this feature is the role of the CRA), second is to give the >> possibility to use a lightly modified DHCPv4 server (to provide >> this feature is the role of the TRA and the CRA6ADDR relay option). >>=20 >> BTW as the DHCPv4 can't be attached directly to the client link >> "by definition", a relay option is required to give to the server >> the topological position of the client, so the CRA6ADDR option >> can't be avoid and its support is the only required change in >> the DHCPv4 server in the deployment with a TRA case. >>=20 >> Implementing and testing DHCPv4 over IPv6 I found 3 issues: >> * first without care (i.e., check of the link layer address) >> a CRA will relay all DISCOVERs from booting nodes, so with N CRA >> and M booting nodes you get N * M copies. This was fixed in the >> spec with the HCRA / LCRA notion. >>=20 >> A more anoying issue is what happens when a client renews its >> leased address: it tries first to send a request to the server >> over IPv4 using the server ID. There are two ways to solve this: >> * put a 0.0.0.0 in the server ID but this is forbidden by DHCPv4 >> spec, disable server selection and is refused by some clients. >> * put a not-routable address in the server ID: it is compliant, >> still provide server selection and works because clients will >> fall back to broadcast DISCOVER, i.e., it just de-optimizes >> the renewal mechanism. >> Note one must not allow the renew message to reach the DHCPv4 >> server because the topological info added by a relay is required. >>=20 >> The last issue was from the fully incorrect/... support of >> SO_REUSEADDR by Linux which makes impossible to run some >> DHCPv4 servers on the same node than a DHCPv4 over IPv6 client >> and CRA. >>=20 >> Note the last 2 points are direct consequences of the idea to >> reuse DHCPv4 clients, with other words they are drawbacks from >> the DHCPv4 over IPv6 simplicity. >>=20 >> To finish it is not hard to modify a DHCPv4+DHCPv6 server code >> to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6 >> or even both over IPv6 and IPv4. The idea is to plug the IPv6 >> I/O subsystem to the DHCPv6 handler. IMHO it should not be >> significanly different (i.e., harder / easier) to support >> DHCPv6 over DHCPv4 (note this is for the server code). > >just to make my own views clear: >- coupling IPv6 and IPv4 provisioning together is a bad idea [ina] Agreed >- I don't think requiring IPv4 specific configuration information on a >softwire is necessary, > if you really have to do it I'd prefer for the IPv4 provisioning >protocol to > run over the IPv4 data path (aka the softwire). and the same solution >could > be used for Public 4over6, LW46, MAP, L2TP... [ian] In the introduction of the v4config draft, it says: "Although softwire mechanisms are currently the only use-case for DHCP based configuration of IPv4 parameters in IPv6 only networks, a suitable approach must not be limited to only supporting softwire configuration." Putting it over the IPv4 data path is going to make this a pretty softwire dependant solution. > >cheers, >Ole > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From otroan@employees.org Tue Aug 6 06:28:30 2013 Return-Path: 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 3297921F9371 for ; Tue, 6 Aug 2013 06:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhKnh7b4Ii6R for ; Tue, 6 Aug 2013 06:28:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBFC21F9346 for ; Tue, 6 Aug 2013 06:28:24 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-74.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BD7915ECC; Tue, 6 Aug 2013 06:28:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Tue, 6 Aug 2013 15:28:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04D56C82-85BC-4021-BEBE-AE24075DD3CF@employees.org> References: To: X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org, Francis.Dupont@fdupont.fr Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:28:30 -0000 Ian, > [ian] In the introduction of the v4config draft, it says: > "Although softwire mechanisms are currently the only use-case for DHCP > based configuration of IPv4 parameters in IPv6 only networks, a = suitable > approach must not be limited to only supporting softwire = configuration." >=20 > Putting it over the IPv4 data path is going to make this a pretty = softwire > dependant solution. it would be dependent on a broadcast capable link-layer supporting IPv4, that isn't softwire specific as such. you aren't suggesting that there is a need to provision IPv4 on a node = that has no way to send IPv4 packets? cheers, Ole= From ianfarrer@gmx.com Tue Aug 6 07:09:08 2013 Return-Path: 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 5D9DD21F9F98 for ; Tue, 6 Aug 2013 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEGgbw9PMmdB for ; Tue, 6 Aug 2013 07:09:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5337D21F9EE9 for ; Tue, 6 Aug 2013 07:09:03 -0700 (PDT) Received: from [192.168.2.224] ([62.225.30.83]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0La3c1-1VruiW0rBl-00lnzm for ; Tue, 06 Aug 2013 16:09:02 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ian Farrer In-Reply-To: <04D56C82-85BC-4021-BEBE-AE24075DD3CF@employees.org> Date: Tue, 6 Aug 2013 16:09:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30C6CF1F-F293-483C-B2E0-5BB18BBBD4C5@gmx.com> References: <04D56C82-85BC-4021-BEBE-AE24075DD3CF@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1508) X-Provags-ID: V03:K0:vxKm+QD5c5h6su9qtkQIXTVJ/Yaw2ZYiF5ARCnbiIcImOOdV6f9 sUpD+vODEEcGv24cmsFCBjgIHbaY6MRpHIKpmf4DKIOzhe4cwgHQCFe84otv9AR9FmSackR tD6BCnwwT4ABuh9I0GZgfjILfGZFtgqzhlnDaJ4D6NAdXMLYqx3clbMKTgU5s3iX0HgZNZ0 19bVuWh+VFD77CuNsrqzw== Cc: dhcwg@ietf.org, Francis.Dupont@fdupont.fr Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:09:08 -0000 Hi Ole, Inline Cheers, Ian On 6 Aug 2013, at 15:28, Ole Troan wrote: > Ian, >=20 >> [ian] In the introduction of the v4config draft, it says: >> "Although softwire mechanisms are currently the only use-case for = DHCP >> based configuration of IPv4 parameters in IPv6 only networks, a = suitable >> approach must not be limited to only supporting softwire = configuration." >>=20 >> Putting it over the IPv4 data path is going to make this a pretty = softwire >> dependant solution. >=20 > it would be dependent on a broadcast capable link-layer supporting = IPv4, > that isn't softwire specific as such. [ian] Couple of points arising from this: 1, This also describes a basic Ethernet interface. The behaviour for an = Ethernet based DHCP client will be different (regular port 68 = communication, can't use shared IPv4 addresses). So, there needs to be = DHCP client logic to work out the right behaviour for the particular = properties of the link it's running on. 2, Are translation (4-6, such as MAP-T) broadcast capable (I don't know = the answer to this one, I've really never considered putting broadcasts = through a NAT)? >=20 > you aren't suggesting that there is a need to provision IPv4 on a node = that has no way to send IPv4 packets? [ian] Not at all. I believe the concept of separating data and = configuration planes is well understood:-) >=20 > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From msiodelski@gmail.com Wed Aug 7 03:17:47 2013 Return-Path: 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 BAE6D21F9A3B for ; Wed, 7 Aug 2013 03:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVwRJk4mJyeC for ; Wed, 7 Aug 2013 03:17:47 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD821E80C2 for ; Wed, 7 Aug 2013 03:17:46 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id u10so1368597lbi.0 for ; Wed, 07 Aug 2013 03:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=czXedxwV/Ot1cMkZeA5DyQxPZF+Z/Y3/fbYiq+KHjIc=; b=meSVQ6ZUSr410MFifVu5o/04VTNes3e6P82kqc/8mxVGr3sCDh8obq7vzG+6DQ8yiG yEwz+jAsPiHuUtJFa+7BRQX35/E80IS4lnFBj2h1sxnskVHoeJO5keYG6AqNogrPjNkV m9jBMzSgSuHSbGTSD1oGxNcnjtgy/bL17sa8m/UjHAox+6f3ITY3d4cqHHWfHeLLtlv0 LPfxCi9Uk5Znu/+WBd3Iv6m6kMhlrRtj1RLyiUrKa653c0wwueThCixaFGBM63S/jIh2 +Oa3XjYAWKFKtXyDo12H/jlA/TBwooyE1mbTDuE4gKPOC8ZrpTTMvU50C9Dop4OMcyWj /stw== MIME-Version: 1.0 X-Received: by 10.152.29.65 with SMTP id i1mr1092154lah.77.1375870664163; Wed, 07 Aug 2013 03:17:44 -0700 (PDT) Received: by 10.112.202.170 with HTTP; Wed, 7 Aug 2013 03:17:44 -0700 (PDT) In-Reply-To: <56D269DB-423A-49C3-83E2-C58FE5FB8DA1@cisco.com> References: <1363117384.2123.64.camel@marcin-lenovo> <56D269DB-423A-49C3-83E2-C58FE5FB8DA1@cisco.com> Date: Wed, 7 Aug 2013 12:17:44 +0200 Message-ID: From: Marcin Siodelski To: Kim Kinnear Content-Type: multipart/alternative; boundary=089e0160b7c031c7bd04e358da6d Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-design-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:17:47 -0000 --089e0160b7c031c7bd04e358da6d Content-Type: text/plain; charset=ISO-8859-1 Kim and Tomek, Thanks for addressing my comments. Below I clarified some of the comments with respect to section 9.11. It may be the case that I misunderstood the part regarding unresponsiveness in the Resolution-Interrupted state. I am hoping that my point will be clearer to you with the additional info below. > 9.11. RESOLUTION-INTERRUPTED > > - In the introduction to this chapter it is pointed out that if the > > server's remained in the POTENTIAL-CONFLICT state and the resolution of > > the conflict was interrupted, they transition to RESOLUTION-INTERRUPTED > > and they are unresponsive to clients > > I don't see the statement about being unresponsive to clients. > Could you point me at it more specifically? > Here is an exact citation from this section: " This state indicates that the two servers were attempting to reintegrate with each other in POTENTIAL-CONFLICT state, but communications failed prior to completion of re-integration. If the servers remained in POTENTIAL-CONFLICT while communications was interrupted, neither server would be responsive to DHCP client requests, and if one server had crashed, then there might be no server able to process DHCP requests." When I said that "they are unresponsive to clients" I was referring to this part of the cited text: "... neither server would be responsive to DHCP client requests..." > > (I presume this is because they > > were unresponsive when being in POTENTIAL-CONFLICT state and the > > conflict is still assumed to be present). > > No, not really. That is the point of RESOLUTION-INTERRUPTED > state -- they can attempt to do *something*, and not just > sit there waiting for the partner. > Ok. So, what they do? They rise an alarm as stated in the last paragraph of 9.11. But still, my understanding is that servers are unresponsive to clients as stated in the "... neither server would be responsive to DHCP client requests...". (see above). > > > If you take a look at the > > 9.11.1. it is said that the server MUST respond to all DHCP client > > requests. That looks contrary to the previous statement. > > Indeed, but I can't find the previous statement... > Cited above. > > My > > understanding is that the server can't respond in the > > RESOLUTION-INTERRUPTED state thus it requires administrative > > intervention. > > I don't know where in the document you got that idea > from, but I'd like to fix it. > See above. Marcin --089e0160b7c031c7bd04e358da6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kim and Tomek,

Thanks for address= ing my comments. Below I clarified some of the comments with respect to sec= tion 9.11. It may be the case that I misunderstood the part regarding unres= ponsiveness in the Resolution-Interrupted state. I am hoping that my point = will be clearer to you with the additional info below.

> 9.11. RESOLUTION-INTERRUPTED=
> - In the introduction to this chapter it is pointed out that if the > server's remained in the POTENTIAL-CONFLICT state and the resoluti= on of
> the conflict was interrupted, they transition to RESOLUTION-INTERRUPTE= D
> and they are unresponsive to clients

=A0 =A0 =A0 =A0 I don't see the statement about being unresponsiv= e to clients.
=A0 =A0 =A0 =A0 Could you point me at it more specifically?

Here is an exact citation from this section:

" This state indicates that the two servers were attempting to
reintegrate with each other in POTENTIAL-CONFLICT state, but
communications failed prior to completion of re-integration.

If the servers remained in POTENTIAL-CONFLICT while communications
was interrupted, neither server would be responsive to DHCP client
requests, and if one server had crashed, then there might be no
server able to process DHCP requests."

<= pre class=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;colo= r:rgb(0,0,0)"> When I said that "they are unresponsive to clients" I was referri= ng to this part of the cited text: "... neither server would be respon= sive to DHCP client requests..."


=A0
> (I presume this is because they
> were unresponsive when being in POTENTIAL-CONFLICT state and the
> conflict is still assumed to be present).

=A0 =A0 =A0 =A0 No, not really. =A0That is the point of RESOLUTION-IN= TERRUPTED
=A0 =A0 =A0 =A0 state -- they can attempt to do *something*, and not just =A0 =A0 =A0 =A0 sit there waiting for the partner.
Ok. So, what they do? They rise an alarm as stated in the= last paragraph of 9.11.
But still, my understanding is tha= t servers are unresponsive to clients as stated in the "... neither server would be responsive to = DHCP client requests...". =A0(see above).
=A0

> If you take a look at the
> 9.11.1. it is said that the server MUST respond to all DHCP client
> requests. That looks contrary to the previous statement.

=A0 =A0 =A0 =A0 Indeed, but I can't find the previous statement..= .

Cited above.
=A0
> My
> understanding is that the server can't respond in the
> RESOLUTION-INTERRUPTED state thus it requires administrative
> intervention.

=A0 =A0 =A0 =A0 I don't know where in the document you got that i= dea
=A0 =A0 =A0 =A0 from, but I'd like to fix it.

=
See above.
=A0
Marcin

<= /div>
--089e0160b7c031c7bd04e358da6d-- From ietf-ipr@ietf.org Wed Aug 7 08:35:53 2013 Return-Path: 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 0C75221E8143; Wed, 7 Aug 2013 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rw4G613Imvk; Wed, 7 Aug 2013 08:35:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7593C21F99BF; Wed, 7 Aug 2013 08:35:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ghalwasi@cisco.com,shwethab@cisco.com,wdec@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130807153550.2863.95943.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2013 08:35:50 -0700 Cc: brian@innovationslab.net, volz@cisco.com, ted.lemon@nominum.com, dhcwg@ietf.org, ipr-announce@ietf.org Subject: [dhcwg] =?utf-8?q?IPR_Disclosure=3A_Cisco=E2=80=99s_Statement_of_?= =?utf-8?q?IPR_Related_to_Request_for_Comments_=28RFC=29_6939?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:35:53 -0000 Dear Gaurav Halwasia, Cisco Systems, Wojciech Dec: An IPR disclosure that pertains to your RFC entitled "Client Link-Layer Ad= dress Option in DHCPv6" (RFC6939) was submitted to the IETF Secretariat on 2013-0= 8-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2168/). The title of the IPR disclosure is "Cisco=E2=80=99s Statement of IPR Related to Request for Comm= ents (RFC) 6939.""); The IETF Secretariat From msiodelski@gmail.com Fri Aug 9 03:40:23 2013 Return-Path: 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 272B221F9FE3 for ; Fri, 9 Aug 2013 03:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6nkHfuU5k5x for ; Fri, 9 Aug 2013 03:40:22 -0700 (PDT) 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 AEA4721F9FCA for ; Fri, 9 Aug 2013 03:40:18 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so291919lab.12 for ; Fri, 09 Aug 2013 03:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kh/0S4Z0aLSYEHHdJWFmcWU5OtCBSFKlS9GYW0oii0Y=; b=OA9MTTExKqAAaDoLi0Zck9qMY1h8CTEDg3v+I3+AqtiOMTKljlJODxzbYLQRJ1HRKv GJM2vLesBJ9tZQUVtSGbGt2TI6orH4SsHJEkXuZtMOpmJ3QcQNgbOWbRQyePR+3voorx ME/0X5Rpc51ndOIJGmNwhWZjiT9tS4ZD5AJG48/G+qclY1PvkFKiIAf/dVGVlRu+Eiz9 mVoFSZXm4uqmJdJqEBw18caQfHbYfMPv2W+r27AD6fLRyY5w7jcTSyBa+5XXrtodE+hT SoKjVUMVf8YPiZcMnqBionM5ILEJc/hUT49QBmkqWMD7eKDVhCkPficbUInlEYxUCeaw ldHQ== MIME-Version: 1.0 X-Received: by 10.152.29.65 with SMTP id i1mr5708575lah.77.1376044815786; Fri, 09 Aug 2013 03:40:15 -0700 (PDT) Received: by 10.112.202.170 with HTTP; Fri, 9 Aug 2013 03:40:15 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> Date: Fri, 9 Aug 2013 12:40:15 +0200 Message-ID: From: Marcin Siodelski To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e0160b7c070a92a04e381663c Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:40:23 -0000 --089e0160b7c070a92a04e381663c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 3:59 PM, Bernie Volz (volz) wrote: > Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 ( > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe > it is ready for working group last call. Please review this draft and > indicate whether or not you feel it is ready to be published. Your input = is > important!**** > > ** ** > > This document is the 2nd series of documents related to DHCPv6 failover = =96 > the first is > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirementswhi= ch is currently being reviewed by the IESG for publication approval. > **** > > ** ** > > At the time of this writing, there is no IPR reported against this draft.= * > *** > > ** ** > > As Tomek is a co-author, I will primarily evaluate consensus after > 2013-08-09 (August 9th). This is a 3 week last call because of the Berlin > IETF meeting and also because of summer-time vacations (at least for thos= e > of us in the northern hemisphere). > I read the document from the top to the bottom and made extensive review. All valid issues I had pointed out were addressed in version -03. Other comments which were identified as non-issues were responded via email. One of the comments which I made was referring to the chapter 9.11. where I was unclear "whether servers are responsive or unresponsive to the clients when they are in the RESOLUTION-INTERRUPTED state" (see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14575.html). In the recent reply to this email thread I clarified the question as it had been unclear for the authors which part of text I had been referring to. This question may still need to be responded. I apologize for the late answer. In general, very good work. I support advancing this document. Marcin --089e0160b7c070a92a04e381663c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 3:59 PM, Bernie Volz (volz) <volz@ci= sco.com> wrote:

Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-desi= gn) believe it is ready for working group last call. Please review this draft and indicate whether or = not you feel it is ready to be published. Your input is important!

=A0

This document is the 2nd series of documents related to DHCPv= 6 failover =96 the first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements = which is currently being reviewed by the IESG for publication approval.<= /u>

=A0

At the time of this writing, there is no IPR reported against this draft= .

=A0

As Tomek is a co-author, I will primarily evaluate consensus after 2013-= 08-09 (August 9th). This is a 3 week last call because of the Be= rlin IETF meeting and also because of summer-time vacations (at least for t= hose of us in the northern hemisphere).


I read the document from the top to the bottom and made extensive = review. All valid issues I had pointed out were addressed in version -03. O= ther comments which were identified as non-issues were responded via email.= One of the comments which I made was referring to the chapter 9.11. where = I was unclear "whether servers are responsive or unresponsive to the c= lients when they are in the RESOLUTION-INTERRUPTED state" (see=A0htt= p://www.ietf.org/mail-archive/web/dhcwg/current/msg14575.html). In the = recent reply to this email thread I clarified the question as it had been u= nclear for the authors which part of text I had been referring to. This que= stion may still need to be responded. I apologize for the late answer.

In general, very good work. I support advan= cing this document.=A0

Marcin

--089e0160b7c070a92a04e381663c-- From damalhot@cisco.com Fri Aug 9 03:52:41 2013 Return-Path: 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 23D6221F9D9A for ; Fri, 9 Aug 2013 03:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slfdAco9R2Sc for ; Fri, 9 Aug 2013 03:52:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DEAB721F9343 for ; Fri, 9 Aug 2013 03:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12221; q=dns/txt; s=iport; t=1376045555; x=1377255155; h=from:to:cc:subject:date:message-id:mime-version; bh=GS8dhKenBCJ2iQT3PuYCMz4WOyI1uWN36vGP4z8NPMg=; b=hcj1ElzfczHd9UO9xQtKAKFp6HZV5I6mqzHJJea4DvamOfyPO5Vyk9zy C0rkj50M0Tkraxg4CtVOR019GARWczmJEcOUOJteHlYQxBPpOBnvD719S HPebd053NpbJE/kFn10lmyMElKna4L8tkhUsm9I29VFFF8BDYaE13qWKI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAO7IBFKtJXHA/2dsb2JhbABbgkJENUQMthOIP4EZFnSCJAEBAQQBAQEqQQsSAQgRAwECCx0uCxQJCQEEDgUIiAgMuSyPaiANBAaDG3QDmQuQJYFfgTmCKg X-IronPort-AV: E=Sophos;i="4.89,845,1367971200"; d="scan'208,217";a="245379982" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2013 10:52:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r79AqTms009356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Aug 2013 10:52:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 05:52:29 -0500 From: "Darpan Malhotra (damalhot)" To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! Thread-Index: Ac6U7qoVow8rAwHVRdSLGYUu0dp98w== Date: Fri, 9 Aug 2013 10:52:29 +0000 Message-ID: <7E887AE87A54714684B968773B57C8A3102576F0@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.50] Content-Type: multipart/alternative; boundary="_000_7E887AE87A54714684B968773B57C8A3102576F0xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:52:41 -0000 --_000_7E887AE87A54714684B968773B57C8A3102576F0xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read the draft. This is very good work. This draft should move furth= er. - Darpan From: "Bernie Volz (volz)" > Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respon= d by August 9, 2013! Date: July 19, 2013 9:59:20 AM EDT To: "dhcwg@ietf.org" > Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tool= s.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe it is ready = for working group last call. Please review this draft and indicate whether = or not you feel it is ready to be published. Your input is important! This document is the 2nd series of documents related to DHCPv6 failover - t= he first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requi= rements which is currently being reviewed by the IESG for publication appro= val. At the time of this writing, there is no IPR reported against this draft. As Tomek is a co-author, I will primarily evaluate consensus after 2013-08-= 09 (August 9th). This is a 3 week last call because of the Berlin IETF meet= ing and also because of summer-time vacations (at least for those of us in = the northern hemisphere). Thanks, - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_7E887AE87A54714684B968773B57C8A3102576F0xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the draft.= This is very good work. This draft should move further.<= /p>

 

-&nb= sp;         Darpan

 

From: "Bernie Volz (volz)" <volz@cisco.com>

Subject: [dhcwg] WGLC for draft-ie= tf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!

Date: July 19, 2013 9:59:20 AM EDT

 

Folks, the authors of draft-ietf-dhc-dh= cpv6-failover-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6= -failover-design) believe it is ready for working group last call. Please review this draft = and indicate whether or not you feel it is ready to be published. Your inpu= t is important!

 

This document is the 2nd series of documents related = to DHCPv6 failover – the first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-fai= lover-requirements wh= ich is currently being reviewed by the IESG for publication approval.

 

At the time of this writing, there is n= o IPR reported against this draft.

 

As Tomek is a co-author, I will primari= ly evaluate consensus after 2013-08-09 (August 9th). This is a 3= week last call because of the Berlin IETF meeting and also because of summer-time vacations (at least for those of us in the northern= hemisphere).

 

Thanks,

 

-       &nb= sp;  Bernie

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.or= g/mailman/listinfo/dhcwg

 

--_000_7E887AE87A54714684B968773B57C8A3102576F0xmbalnx03ciscoc_-- From kkinnear@cisco.com Fri Aug 9 07:58:40 2013 Return-Path: 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 943FB21F9E11 for ; Fri, 9 Aug 2013 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQGLRpKHCv3O for ; Fri, 9 Aug 2013 07:58:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 39A0211E81A2 for ; Fri, 9 Aug 2013 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4229; q=dns/txt; s=iport; t=1376060081; x=1377269681; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TR1/8xYs0hPcogP8mBWKYg4jRvG7NYGoalqjBnQVBIo=; b=GOjWxxEMSWYLszfUQ+SeHUOOx8yQfQdT/fDVBptuvvrM5/x5KxJYI/Lo uHdI36rjMfLWJY/cE5jVN3pSt4PKv8N9w96bh2wAWfbcVyX9AdZ3TSjvr a6o8x1D7L4dJPPgd1Y+TyE7Gs7xcIsD8pmRAfZraFQfguWibVew05//K3 w=; X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245448608" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2013 14:54:41 +0000 Received: from [161.44.65.131] ([161.44.65.131]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r79EseI3021624; Fri, 9 Aug 2013 14:54:40 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Kim Kinnear In-Reply-To: Date: Fri, 9 Aug 2013 10:54:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1363117384.2123.64.camel@marcin-lenovo> <56D269DB-423A-49C3-83E2-C58FE5FB8DA1@cisco.com> To: Marcin Siodelski X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , Kim Kinnear Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-design-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:58:40 -0000 Marcin, *Now* I understand where the confusion is coming from. See below... On Aug 7, 2013, at 6:17 AM, Marcin Siodelski wrote: >=20 > > 9.11. RESOLUTION-INTERRUPTED > > - In the introduction to this chapter it is pointed out that if the > > server's remained in the POTENTIAL-CONFLICT state and the resolution = of > > the conflict was interrupted, they transition to = RESOLUTION-INTERRUPTED > > and they are unresponsive to clients This is simply not true -- the document does not say this. See below... >=20 > I don't see the statement about being unresponsive to clients. > Could you point me at it more specifically? >=20 > Here is an exact citation from this section: >=20 > " This state indicates that the two servers were attempting to > reintegrate with each other in POTENTIAL-CONFLICT state, but > communications failed prior to completion of re-integration. >=20 > If the servers remained in POTENTIAL-CONFLICT while communications > was interrupted, neither server would be responsive to DHCP client > requests, and if one server had crashed, then there might be no > server able to process DHCP requests." > This second paragraph is conditional -- "If" the servers > remained in POTENTIAL-CONFLICT "then" neither server > would be responsive to DHCP client requests. This is the > justification for the RESOLUTION-INTERRUPTED failover > state, this is *not* the description of how the server > operates in the RESOLUTION-INTERRUPTED state. That is > explained in section 9.11.1. >=20 > Since the servers do *not* remain in POTENTIAL-CONFLICT > state, they do not have to be unresponsive to DHCP client > requests. They do not have to be responsive, either. > The statement above says *nothing* about whether or not > they are responsive to client requests in the > RESOLUTION-INTERRUPTED state, it simply motivates *why* > there is a RESOLUTION-INTERRUPTED state. >=20 > See below... >=20 >=20 >=20 > When I said that "they are unresponsive to clients" I was referring to = this part of the cited text: "... neither server would be responsive to = DHCP client requests..." >=20 >=20 > =20 > > (I presume this is because they > > were unresponsive when being in POTENTIAL-CONFLICT state and the > > conflict is still assumed to be present). >=20 > No, not really. That is the point of RESOLUTION-INTERRUPTED > state -- they can attempt to do *something*, and not just > sit there waiting for the partner. >=20 > Ok. So, what they do? They rise an alarm as stated in the last = paragraph of 9.11. > But still, my understanding is that servers are unresponsive to = clients as stated in the "... neither server would be responsive to DHCP = client requests...". (see above). > =20 >=20 > > If you take a look at the > > 9.11.1. it is said that the server MUST respond to all DHCP client > > requests. That looks contrary to the previous statement. Section 9.11.1 is titled "Operation in RESOLUTION-INTERRUPTED State", and is quite explicit that the servers MUST respond to all DHCP client requests. It is not in conflict with any previous statement, because 9.11 says exactly *nothing* with regard to whether or not a server in RESOLUTION-INTERRUPTED state should process DHCP client requests. See below... >=20 > Indeed, but I can't find the previous statement... >=20 > Cited above. > =20 > > My > > understanding is that the server can't respond in the > > RESOLUTION-INTERRUPTED state thus it requires administrative > > intervention. >=20 > I don't know where in the document you got that idea > from, but I'd like to fix it. >=20 So, technically, I think the document is accurate and that there is no conflict in what is described. That said, you obviously found it obscure enough to raise this issue, and when we revise the document the next time, I will add some words to Section 9.11 to try to clarify that we are motivating the existence of the RESOLUTION-INTERRUPTED state, not describing how it operates. I think that would help clarify this situation. Regards -- Kim From kkinnear@cisco.com Fri Aug 9 08:06:41 2013 Return-Path: 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 1388C21E8149 for ; Fri, 9 Aug 2013 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFX6xw-bI03t for ; Fri, 9 Aug 2013 08:06:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0231421E809B for ; Fri, 9 Aug 2013 08:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1376060475; x=1377270075; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8YctV4Fu0pbyvy4iRgfsMHH7VFfF0TrlOuznsa8H98I=; b=PY5P512p04PABO58b8WNu9Rhua2itszBLswehtu0oBGLRkE9JLAVdndY UXmaNp4yz3UIOmyIN787+PUW9mqAWj3D9kGgrg2Yw983K52n/ZHlpjWOV z6AHJ5RIrUOY5TpV0rRe8UDaShf5hMr3BTptzn/1dlTfFRkQCFRmnecA8 0=; X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245495864" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 15:01:14 +0000 Received: from [161.44.65.131] ([161.44.65.131]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r79F1DRv017906; Fri, 9 Aug 2013 15:01:13 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Kim Kinnear In-Reply-To: Date: Fri, 9 Aug 2013 11:01:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <355D8971-CB61-4FAF-8BC7-829BB4759DA3@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> To: Marcin Siodelski X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:06:41 -0000 Marcin, et. al., I have responded to Marcin's comments about sections 9.11 and 9.11.1 in his email of Aug 7, since the details all appeared in that email thread. My bottom line from that response was: >=20 > So, technically, I think the document is accurate and > that there is no conflict in what is described. >=20 > That said, you obviously found it obscure enough to raise > this issue, and when we revise the document the next > time, I will add some words to Section 9.11 to try to > clarify that we are motivating the existence of the > RESOLUTION-INTERRUPTED state, not describing how it > operates. Since this is a relatively minor clarification and not a change to the document, I don't think any such clarification would require a republication of the document and another last call (at least on its own). The changes I have in mind could be done during the RFC editor processing, but I'm sure that won't be necessary. We will certainly have to make multiple revisions to this document to pass through the IESG review process (assuming that we even get that far), and I will make this change when we do those revisions. If, as I said, we even pass through last call. Regards -- Kim On Aug 9, 2013, at 6:40 AM, Marcin Siodelski wrote: > On Fri, Jul 19, 2013 at 3:59 PM, Bernie Volz (volz) = wrote: > Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 = (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) = believe it is ready for working group last call. Please review this = draft and indicate whether or not you feel it is ready to be published. = Your input is important! >=20 > =20 >=20 > This document is the 2nd series of documents related to DHCPv6 = failover =96 the first is = http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements = which is currently being reviewed by the IESG for publication approval. >=20 > =20 >=20 > At the time of this writing, there is no IPR reported against this = draft. >=20 > =20 >=20 > As Tomek is a co-author, I will primarily evaluate consensus after = 2013-08-09 (August 9th). This is a 3 week last call because of the = Berlin IETF meeting and also because of summer-time vacations (at least = for those of us in the northern hemisphere). >=20 >=20 > I read the document from the top to the bottom and made extensive = review. All valid issues I had pointed out were addressed in version = -03. Other comments which were identified as non-issues were responded = via email. One of the comments which I made was referring to the chapter = 9.11. where I was unclear "whether servers are responsive or = unresponsive to the clients when they are in the RESOLUTION-INTERRUPTED = state" (see = http://www.ietf.org/mail-archive/web/dhcwg/current/msg14575.html). In = the recent reply to this email thread I clarified the question as it had = been unclear for the authors which part of text I had been referring to. = This question may still need to be responded. I apologize for the late = answer. >=20 > In general, very good work. I support advancing this document.=20 >=20 > Marcin >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From kkinnear@cisco.com Fri Aug 9 08:13:30 2013 Return-Path: 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 5645A11E81E6 for ; Fri, 9 Aug 2013 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6mk0HeRBido for ; Fri, 9 Aug 2013 08:13:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ED3BA21E8122 for ; Fri, 9 Aug 2013 08:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4472; q=dns/txt; s=iport; t=1376060771; x=1377270371; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lYRaRGND+Qu/5z3rh0EGloz5cmTIzy7+Llvso3A1BHo=; b=DwG1U/yvXJwYbMJIFA/LVHy8QECmxsRhW450oYBN5X6qeLXVCel9qInR G4sc2T5XaUa0BpA55643juVyXPwatT/FXcDzIRcKFH0f3KyQQxowpFvTh n22UINIqQDjgZfUD5gLeFEnSvT5quj4gUMHrXlCiSR/oFRzEf61AB5XU+ A=; X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245453456" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2013 15:06:10 +0000 Received: from [161.44.65.131] ([161.44.65.131]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r79F6Aj9011806; Fri, 9 Aug 2013 15:06:10 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Kim Kinnear In-Reply-To: Date: Fri, 9 Aug 2013 11:06:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CA2A989-8728-4147-9C08-86259BB4C04E@cisco.com> References: <1363117384.2123.64.camel@marcin-lenovo> <56D269DB-423A-49C3-83E2-C58FE5FB8DA1@cisco.com> To: Marcin Siodelski X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" , Kim Kinnear Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-design-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:13:30 -0000 Folks, The quote markers are off in the previous email with=20 similar content -- my apologies. Here is the same email, with corrected quote markers (which should make it more obvious what I was saying vs what Marcin was saying). Regards -- Kim On Aug 9, 2013, at 10:54 AM, Kim Kinnear wrote: Marcin, *Now* I understand where the confusion is coming from. See below... On Aug 7, 2013, at 6:17 AM, Marcin Siodelski wrote: >=20 >> 9.11. RESOLUTION-INTERRUPTED >> - In the introduction to this chapter it is pointed out that if the >> server's remained in the POTENTIAL-CONFLICT state and the resolution = of >> the conflict was interrupted, they transition to = RESOLUTION-INTERRUPTED >> and they are unresponsive to clients This is simply not true -- the document does not say this. See below... >=20 > I don't see the statement about being unresponsive to clients. > Could you point me at it more specifically? >=20 > Here is an exact citation from this section: >=20 > " This state indicates that the two servers were attempting to > reintegrate with each other in POTENTIAL-CONFLICT state, but > communications failed prior to completion of re-integration. >=20 > If the servers remained in POTENTIAL-CONFLICT while communications > was interrupted, neither server would be responsive to DHCP client > requests, and if one server had crashed, then there might be no > server able to process DHCP requests." This second paragraph is conditional -- "If" the servers remained in POTENTIAL-CONFLICT "then" neither server would be responsive to DHCP client requests. This is the justification for the RESOLUTION-INTERRUPTED failover state, this is *not* the description of how the server operates in the RESOLUTION-INTERRUPTED state. That is explained in section 9.11.1. Since the servers do *not* remain in POTENTIAL-CONFLICT state, they do not have to be unresponsive to DHCP client requests. They do not have to be responsive, either. The statement above says *nothing* about whether or not they are responsive to client requests in the RESOLUTION-INTERRUPTED state, it simply motivates *why* there is a RESOLUTION-INTERRUPTED state. See below... >=20 >=20 > When I said that "they are unresponsive to clients" I was referring to = this part of the cited text: "... neither server would be responsive to = DHCP client requests..." >=20 >=20 >=20 >> (I presume this is because they >> were unresponsive when being in POTENTIAL-CONFLICT state and the >> conflict is still assumed to be present). >=20 > No, not really. That is the point of RESOLUTION-INTERRUPTED > state -- they can attempt to do *something*, and not just > sit there waiting for the partner. >=20 > Ok. So, what they do? They rise an alarm as stated in the last = paragraph of 9.11. > But still, my understanding is that servers are unresponsive to = clients as stated in the "... neither server would be responsive to DHCP = client requests...". (see above). >=20 >=20 >> If you take a look at the >> 9.11.1. it is said that the server MUST respond to all DHCP client >> requests. That looks contrary to the previous statement. Section 9.11.1 is titled "Operation in RESOLUTION-INTERRUPTED State", and is quite explicit that the servers MUST respond to all DHCP client requests. It is not in conflict with any previous statement, because 9.11 says exactly *nothing* with regard to whether or not a server in RESOLUTION-INTERRUPTED state should process DHCP client requests. See below... >=20 > Indeed, but I can't find the previous statement... >=20 > Cited above. >=20 >> My >> understanding is that the server can't respond in the >> RESOLUTION-INTERRUPTED state thus it requires administrative >> intervention. >=20 > I don't know where in the document you got that idea > from, but I'd like to fix it. >=20 So, technically, I think the document is accurate and that there is no conflict in what is described. That said, you obviously found it obscure enough to raise this issue, and when we revise the document the next time, I will add some words to Section 9.11 to try to clarify that we are motivating the existence of the RESOLUTION-INTERRUPTED state, not describing how it operates. I think that would help clarify this situation. Regards -- Kim From Ted.Lemon@nominum.com Fri Aug 9 08:28:18 2013 Return-Path: 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 C539C11E8115 for ; Fri, 9 Aug 2013 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO0gkeSBMddA for ; Fri, 9 Aug 2013 08:28:12 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E61E611E8296 for ; Fri, 9 Aug 2013 08:18:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUgUIPcM/vvG+sQAbm/S0HgR9qtqXqpZ/@postini.com; Fri, 09 Aug 2013 08:18:31 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B08681B8291 for ; Fri, 9 Aug 2013 08:18:21 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A2A15190068 for ; Fri, 9 Aug 2013 08:18:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 9 Aug 2013 08:18:21 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: Ted Lemon In-Reply-To: <355D8971-CB61-4FAF-8BC7-829BB4759DA3@cisco.com> Date: Fri, 9 Aug 2013 11:18:19 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <355D8971-CB61-4FAF-8BC7-829BB4759DA3@cisco.com> To: Kim Kinnear X-Mailer: Apple Mail (2.1793.4) X-Originating-IP: [192.168.1.10] X-Mailman-Approved-At: Fri, 09 Aug 2013 08:33:57 -0700 Cc: Bernie Volz , "dhcwg@" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:28:18 -0000 Generally speaking, I strongly encourage you to apply any known updates = to the document before submitting it to the IESG=97we have to review = typically several hundred pages per telechat, so the chances of us = noticing the RFC editor's note at the right time are pretty slim. Of = course, comments that are already addressed by RFC editor's notes are = easily dealt with, but why make us write them? :) That said, you haven't requested publication yet, and I will do an = editorial pass over the document before submitting it to the IESG, so = this update can wait until that editorial pass has happened. Thanks! From msiodelski@gmail.com Fri Aug 9 09:35:55 2013 Return-Path: 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 9765521F9CA8 for ; Fri, 9 Aug 2013 09:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCJrtb0bW0yK for ; Fri, 9 Aug 2013 09:35:55 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 49BFF21F9CAD for ; Fri, 9 Aug 2013 09:29:02 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id fn20so1862842lab.37 for ; Fri, 09 Aug 2013 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dt18B+p02vi1SFQ72Tc0z+gDnio/of2BrVErOHqB3yE=; b=O1OCrBLdwLI5B03Z5i/N1lEEvQNLHm1xOWkE7TfulllqTiBjfkFmTYyWoKTJqbrQEO 7Mg7NDN3rOKHLwgvW64WTnEvDTNVP+rgOq9UxrvORodv0J1q4nAHHddIv9L9IwYE60Im zNS2ViHhHAQWdFqkdBLs1b96UTxOmb9tzDLJgcUocmutrDDQFS3m5HdO/mPQC+AHQwBO 89jPGm8Gul3IOUfRTY9TUrTR8DfTnf8ft06tn/BoCEFn3OBOq5g9xqXAAK1LFogO88hS BXu9ul8Eiqr+2qKPRCQASqLeXw+lCuVxWufWn4Yusp4wMzNPspu7t/AS+QtLC0RSBL35 T74w== MIME-Version: 1.0 X-Received: by 10.152.18.201 with SMTP id y9mr5764589lad.57.1376065741169; Fri, 09 Aug 2013 09:29:01 -0700 (PDT) Received: by 10.112.202.170 with HTTP; Fri, 9 Aug 2013 09:29:00 -0700 (PDT) In-Reply-To: <355D8971-CB61-4FAF-8BC7-829BB4759DA3@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <355D8971-CB61-4FAF-8BC7-829BB4759DA3@cisco.com> Date: Fri, 9 Aug 2013 18:29:00 +0200 Message-ID: From: Marcin Siodelski To: Kim Kinnear Content-Type: multipart/alternative; boundary=089e0141a02cb0a90904e3864581 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:35:55 -0000 --089e0141a02cb0a90904e3864581 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 9, 2013 at 5:01 PM, Kim Kinnear wrote: > > Marcin, et. al., > > I have responded to Marcin's comments about sections 9.11 and 9.11.1 > in his email of Aug 7, since the details all appeared in that email > thread. > > Kim, I read section 9.11. a couple of times when I got your response. Now understand what is said in this section. Having said that, I agree that the document is accurate. It was my misinterpretation. Regards, Marcin --089e0141a02cb0a90904e3864581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 5:01 PM, Kim Kinnear <kkinnear@ci= sco.com> wrote:

Marcin, et. al.,

I have responded to Marcin's comments about sections 9.11 and 9.11.1 in his email of Aug 7, since the details all appeared in that email
thread.


Kim,
I read section 9.11. a = couple of times when I got your response. Now understand what is said in th= is section. Having said that, I agree that the document is accurate. It was= my misinterpretation.

Regards,
Marcin
=
--089e0141a02cb0a90904e3864581-- From Francis.Dupont@fdupont.fr Mon Aug 12 08:45:19 2013 Return-Path: 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 F10ED21F9D28 for ; Mon, 12 Aug 2013 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1mUYzt2zO9x for ; Mon, 12 Aug 2013 08:45:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 8B53621F9D1F for ; Mon, 12 Aug 2013 07:38:04 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r7CEahC4056298; Mon, 12 Aug 2013 16:36:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308121436.r7CEahC4056298@givry.fdupont.fr> From: Francis Dupont To: Ole Troan In-reply-to: Your message of Tue, 06 Aug 2013 13:21:56 +0200. <34B56CCB-04C1-46E5-9CE2-B588994B9645@employees.org> Date: Mon, 12 Aug 2013 16:36:43 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:45:19 -0000 In your previous mail you wrote: > > First I am explaining my comment at the dhc/sunset4 meeting yesterday: > > "DHCPv4 is not really over UDP/IP" > > What I mean is no genuine IPv4 stack is able to send or receive > > a DISCOVER message from a booting device: this message has the > > format of an UDP/IPv4/ethernet-like packet but has only the format. > > can you explain what you mean by "DHCPv4 is not really over UDP/IP"? => I believe I explained what I mean by this statement? > > - DHCPv4 over softwire works well if all nodes already have IPv4 > > addresses. If they have none one enters in difficulties which are > > IMHO the direct consequence of the "DHCPv4 is not really over > > UDP/IP". So if the requirements include to asignment of IPv4 > > addresses to nodes without one (and they should include this) then > > the DHCPv4 over softwire is not a good solution. > > Another point is DHCPv4 over softwire can require a ALG (Application > > Level Gateway) at the server exit point in order to provide the > > IPv6 address (or any topological ID) to the DHCPv4 server. > > I tested DHCPv4 over a softwire with my favourite implementation and > that worked out of the box. => did you check your favourite implementation is really using the IP stack? Usually DHCPv4 uses a link-layer access like BPF so relies on the correct support in the link-layer for this specific usage (so it can work with one implementation but not the other, if you are unlucky the client and the server won't interoperate, and you'll have nobody to blame because the case is not described in the specs...). > DHCPv4 in that it uses broadcast requires a link-layer that supports > broadcast. > given that a softwire is a p2p link, it does support broadcast (and > multicast). => usually the issue with DHCPv4 and encapsulation is not the packet format (there is a straightforward way for it) but the sanity checks at the other (here DHCPv4 server) side: how the set the expected source address without a little idea of what it is? Note this doesn't make impossible to work, just it requires specific support (and specifications if you want interoperability). > > To finish it is not hard to modify a DHCPv4+DHCPv6 server code > > to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6 > > or even both over IPv6 and IPv4. The idea is to plug the IPv6 > > I/O subsystem to the DHCPv6 handler. IMHO it should not be > > significanly different (i.e., harder / easier) to support > > DHCPv6 over DHCPv4 (note this is for the server code). > > just to make my own views clear: > - coupling IPv6 and IPv4 provisioning together is a bad idea => I believe you mean provisioning at the server side (note no supported solution requires such a coupling). > - I don't think requiring IPv4 specific configuration information > on a softwire is necessary, if you really have to do it I'd prefer > for the IPv4 provisioning protocol to run over the IPv4 data path > (aka the softwire). and the same solution could be used for Public > 4over6, LW46, MAP, L2TP... => the problem is sbout the IPv4 provisioning: if it includes IPv4 address provisioning it should not run over the IPv4 data path. BTW the I-D is not enough clear about this point to be a critical requirement or not... (and I raised this concern in my review before the slide about real (vs info only) DHCPv4 over softwire slide). Thanks Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Aug 12 08:47:56 2013 Return-Path: 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 1A15E21E80B5 for ; Mon, 12 Aug 2013 08:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYAnRFTYDrDH for ; Mon, 12 Aug 2013 08:47:55 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 82CBF21E82D2 for ; Mon, 12 Aug 2013 07:43:56 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r7CEgbFS056672; Mon, 12 Aug 2013 16:42:37 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308121442.r7CEgbFS056672@givry.fdupont.fr> From: Francis Dupont To: ian.farrer@telekom.de In-reply-to: Your message of Tue, 06 Aug 2013 15:19:29 +0200. Date: Mon, 12 Aug 2013 16:42:37 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:47:56 -0000 In your previous mail you wrote: > [ian] In the introduction of the v4config draft, it says: > "Although softwire mechanisms are currently the only use-case for DHCP > based configuration of IPv4 parameters in IPv6 only networks, a suitable > approach must not be limited to only supporting softwire configuration." => DHCPv4 (and unfortunately DHCPv6 too) has a lot of strong constraints on its usage environment because it has to work from no knowledge at all (first no IP address...). My concern with the "information mode" of DHCPv4 is these constraints remain. I believe you have the same concern but you use a very different wording for the same result: "a suitable approach must not be limited to only supporting softwire configuration". Thanks Francis.Dupont@fdupont.fr From volz@cisco.com Mon Aug 12 12:22:11 2013 Return-Path: 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 9A0A721F9E1D for ; Mon, 12 Aug 2013 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ6i-PYXHvlG for ; Mon, 12 Aug 2013 12:21:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 762BA21F9E54 for ; Mon, 12 Aug 2013 12:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18949; q=dns/txt; s=iport; t=1376335303; x=1377544903; h=from:to:subject:date:message-id:mime-version; bh=oklqLh/FGggENLBcMX+flCLXClKLvJ2zkSMyevMHh9Y=; b=k35qfTWCAePO4BenLfmyjag6U66mLH7aQ8itZWRQYu1H/nDJw2VEFk9k LnT2fHHdlOqiwose0usP0sTDiizH2X4x5dzCvyqMM2oxv81swhHVt8KQ/ EL/eFKgk2WKUyo3AZdxG2yuZWuzcw8ESDrWW/6ICRw+nqHd0RAudIqp3P E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8GAHU1CVKtJV2Z/2dsb2JhbABBGoJCRDVQthmIPYEbFm0HgiYBBC1eASpWJgEEG4gIDDKVc6A2kAotgyZ2A5kQiwGFJIMbgio X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208,217";a="246412549" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 19:21:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7CJLggh004152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 12 Aug 2013 19:21:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 14:21:42 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Advancing RFC 3315 and RFC 3633 to Internet Standard Thread-Index: Ac6XkNumLI/tVOa0T9WBrxY5XdrPwA== Date: Mon, 12 Aug 2013 19:21:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.173] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18654EE6xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:22:11 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E18654EE6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: During the Berlin IETF-87 DHC WG session, it was suggested that we initiate= a standards action request to move RFC 3315 (and RFC 3633), which are pres= ently Proposed Standards, to Internet Standard. While we plan to work on a = 3315bis which would merge the work, it was pointed out by several people (i= nclude our Area Director) that there is technically no need to wait for tha= t to advance the standards. The requirements for advancement are outlined in RFC 2026 and RFC 6410 (whi= ch removed Draft Standard). Per RFC 6410: The criteria are: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. Please provide input as to whether you support making this request of the I= ETF/IESG (via the Internet Area Directors) or whether you feel there are is= sues (based on the above criteria). If you feel one document is ready but t= he other isn't, please let us know about that too. Assuming we can move forward, proposed request text is below - you can comm= ent on that too. The DHC WG co-chairs, with the support of the DHC Working Group, requests t= hat the following documents be reclassified as Internet Standards instead o= f Proposed Standards as they presently are per RFC 6410: RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3633 - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHC= P) version 6 Both of these Proposed Standards have been widely implemented by multiple v= endors and demonstrated to interoperate. This is most evidenced by the larg= e scale deployment by Comcast Cable (in the v6ops WG meeting at the Berlin = IETF, John Brzozowski indicated that Comcast has about 3 million subscriber= s with native IPv6 access using CableLabs standards, which includes RFC 331= 5 and 3633). Many networking shows and events (including the IETF meetings have provided= IPv6 and DHCPv6 support (sometimes just stateless but also stateful) to pa= rticipants without any issues. The University Of New Hampshire Interoperability Laboratory also has perfor= med interoperability testing as well as conformance testing under the USGv6= testing program. Results are available at https://www.iol.unh.edu/services= /testing/ipv6/usgv6tested.php?company=3D&type=3D&test_dhcpv6_client=3DDHCPv= 6+Client&test_dhcpv6_server=3DDHCPv6+Server#eqplist and (at the time of thi= s writing) had 11 vendors with products on the tested list. Note that CableLabs also has had many interoperability events that tested C= PEs (client implementations), CMTSs (relay agents), and servers. These tests include stateful address assignment as well as pre= fix delegation, and this includes support of the Reconfigure Key Authentica= tion Protocol. There are a wide variety of implementations of DHCPv6 clients by almost all= major operating system vendors (Microsoft, Apple, Red Hat, IBM, just to na= me a few). There are public domain implementations available (for clients, = relays, and servers) such as Dibbler (http://klub.com.pl/dhcpv6/) and from = the Internet Software Consortium (http://www.isc.org). Most routers have im= plementations (client, relay, and server). Many consumer grade home gateway= s also include implementations (client and stateless server). And, there ar= e commercial, high performance, servers available from multiple vendors (Ci= sco, Nomimum, etc.). The two documents do have several errata, but these are mostly minor correc= tions and typographic errors and have not been critical to the successful i= mplementation and interoperability of the standards. In any case, they are = available to implementers of the standards. There are no IPR claims related to the these specifications. Therefore, we believe that these documents have demonstrated a high degree = of interoperability and deployment over the past 10 years and therefore des= erve to be Internet Standards. - DHC WG Co-chairs (Tomek Mrugalski and Bernie Volz) --_000_489D13FBFA9B3E41812EA89F188F018E18654EE6xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

During the Berlin IETF-87 DHC WG session, it was sug= gested that we initiate a standards action request to move RFC 3315 (and RF= C 3633), which are presently Proposed Standards, to Internet Standard. Whil= e we plan to work on a 3315bis which would merge the work, it was pointed out by several people (include our Ar= ea Director) that there is technically no need to wait for that to advance = the standards.

 

The requirements for advancement are outlined in RFC= 2026 and RFC 6410 (which removed Draft Standard).

 

Per RFC 6410:

 

The criteri= a are:

 =

  = ; (1) There are at least two independent interoperating implementations

  = ;     with widespread deployment and successful operati= onal experience.

 =

  = ; (2) There are no errata against the specification that would cause a=

  = ;     new implementation to fail to interoperate with d= eployed ones.

 =

  = ; (3) There are no unused features in the specification that greatly

  = ;     increase implementation complexity.

 =

  = ; (4) If the technology required to implement the specification<= /span>

  = ;     requires patented or otherwise controlled technol= ogy, then the

  = ;     set of implementations must demonstrate at least = two independent,

  = ;     separate and successful uses of the licensing pro= cess.

 

Please provide input as to whether you support makin= g this request of the IETF/IESG (via the Internet Area Directors) or whethe= r you feel there are issues (based on the above criteria). If you feel one = document is ready but the other isn’t, please let us know about that too.

 

Assuming we can move forward, proposed request text = is below – you can comment on that too.

 

 

The DHC WG co-chairs, with the support of the DHC Wo= rking Group, requests that the following documents be reclassified as Inter= net Standards instead of Proposed Standards as they presently are per RFC 6= 410:

 

RFC 3315 - Dynamic Host C= onfiguration Protocol for IPv6 (DHCPv6)

RFC 3633 - IPv6 Prefix Op= tions for Dynamic Host Configuration Protocol (DHCP) version 6

 

Both of these Proposed Standards have been widely im= plemented by multiple vendors and demonstrated to interoperate. This is mos= t evidenced by the large scale deployment by Comcast Cable (in the v6ops WG= meeting at the Berlin IETF, John Brzozowski indicated that Comcast has about 3 million subscribers with nat= ive IPv6 access using CableLabs standards, which includes RFC 3315 and 3633= ).

 

Many networking shows and events (including the IETF= meetings have provided IPv6 and DHCPv6 support (sometimes just stateless b= ut also stateful) to participants without any issues.

 

The University Of New Hampshire Interoperability Lab= oratory also has performed interoperability testing as well as conformance = testing under the USGv6 testing program. Results are available at https://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php?company=3D&am= p;type=3D&test_dhcpv6_client=3DDHCPv6+Client&test_dhcpv6_server= =3DDHCPv6+Server#eqplist and (at the time of this writing) had 11 v= endors with products on the tested list.

 

Note that CableLabs also has had many interoperabili= ty events that tested CPEs (client implementations), CMTSs (relay agents),<= o:p>

and servers. These tests include stateful address as= signment as well as prefix delegation, and this includes support of the Rec= onfigure Key Authentication Protocol.

 

There are a wide variety of implementations of DHCPv= 6 clients by almost all major operating system vendors (Microsoft, Apple, R= ed Hat, IBM, just to name a few). There are public domain implementations a= vailable (for clients, relays, and servers) such as Dibbler (http://kl= ub.com.pl/dhcpv6/) and from the Internet Software Consortium (http://www.isc.org). Most routers have implemen= tations (client, relay, and server). Many consumer grade home gateways also include implementations (client and stat= eless server). And, there are commercial, high performance, servers availab= le from multiple vendors (Cisco, Nomimum, etc.).

 

The two documents do have several errata, but these = are mostly minor corrections and typographic errors and have not been criti= cal to the successful implementation and interoperability of the standards.= In any case, they are available to implementers of the standards.

 

There are no IPR claims related to the these specifi= cations.

 

Therefore, we believe that these documents have demo= nstrated a high degree of interoperability and deployment over the past 10 = years and therefore deserve to be Internet Standards.

 

-     &= nbsp;    DHC WG Co-chairs (Tomek Mrugalski and Bernie Volz)<= o:p>

 

--_000_489D13FBFA9B3E41812EA89F188F018E18654EE6xmbrcdx04ciscoc_-- From volz@cisco.com Mon Aug 12 14:29:31 2013 Return-Path: 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 68D4F21F995E for ; Mon, 12 Aug 2013 14:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyKGMDM2r3xr for ; Mon, 12 Aug 2013 14:29:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0260921F9FD6 for ; Mon, 12 Aug 2013 14:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4932; q=dns/txt; s=iport; t=1376342943; x=1377552543; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tHvLgqrCSJ/SYhibyiCSr5KjOE7J7DVvkmDPs8rjNkg=; b=HGIrFqmdknjek67og1JZmkxiuvY+kK3vTP6wfz6gtw5q9hltxnT8yhkb CwsExQrA98tEEC6HGa0ZCFZF9DpXdppHSFFzoeHwnJwL9Cxehzw4Bi/tT 43JXO/rvQekfEl+moOlggKeBqJOPs5w+qPW8yeEYmT8+0HljbE/duwrqh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOxSCVKtJV2Y/2dsb2JhbABbgwY1Sga+V4EcFnSCJAEBAQQBAQE3MQMGEQQCAQgRAwEBAQsUBQQHJwsUCQgCBAESCAGIBwcFtnCPBoEEBi0FBoMVdgOUDYUDiwGFJIFhgTqCKg X-IronPort-AV: E=Sophos;i="4.89,864,1367971200"; d="scan'208";a="246476446" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Aug 2013 21:29:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7CLT1Kd031679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 21:29:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 16:29:01 -0500 From: "Bernie Volz (volz)" To: Yusuke DOI , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Fwd: [Roll] Request for Review: Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt Thread-Index: AQHOjo7Vq7kXwbde7UCMVu7yhcark5mSJSlg Date: Mon, 12 Aug 2013 21:29:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186553C6@xmb-rcd-x04.cisco.com> References: <51F7E77C.5090607@toshiba.co.jp> <51FA1832.6050004@toshiba.co.jp> In-Reply-To: <51FA1832.6050004@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Fwd: [Roll] Request for Review: Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:29:31 -0000 A few comments regarding this draft: 1. Please make sure to look at http://tools.ietf.org/html/draft-ietf-dhc-op= tion-guidelines. This document is being adopted by the DHC WG and is critic= al to follow. 2. While it may cost a few octets, I would strongly encourage you to use se= parate fields for some items (such as C_K and DM_K). This will cost you one= octet but keeps the encoding simpler (flags, C_K, and DM_K octets). 3. The new data type (Unsigned Short Floating Point) will likely delay impl= ementation in some servers (or require 'manual' encoding). If it is critica= l that this be used (instead of a more traditional data type), so be it. 4. As stated in draft-ietf-dhc-option-guidelines, this document does specif= y that multiple instances are allowed (see draft-ietf-dhc-option-guidelines= -13, section 16). However, it makes no statement as to whether the order is= significant and that is covered in draft-ietf-dhc-option-guidelines-13, se= ction 17 (there should be no IMPLICIT or EXPLICIT ordering with multiple op= tions). 5. You might document the possible length of the options as there seems to = be only two choices - X and X+16 (if C=3D1). Is C even necessary? Could the= option length (i.e., if MPL domain address is present) be used to determin= e this? (It avoids having to test the length if C=3D1 to make sure it is co= rrect.) 6. I can say nothing about the utility of this option and whether the data = contained therein is appropriate as I am not an MPL expert - we would defer= to the ROLL WG in these regards. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Y= usuke DOI Sent: Thursday, August 01, 2013 4:12 AM To: dhcwg@ietf.org Subject: [dhcwg] Fwd: [Roll] Request for Review: Fwd: I-D Action: draft-doi= -roll-mpl-parameter-configuration-02.txt Dear dhc folks, Just FYI, here is a proposed individual I-D proposed to roll WG. I believe = it does not make any harm to current DHCP infrastructure because this is an= other stateless option to distribute data among nodes. It's still in early = stage and will be updated to satisfy the option guideline document. Any feedbacks are welcome. Regards, Yusuke -------- Original Message -------- Subject: [Roll] Request for Review: Fwd: I-D Action:=20 draft-doi-roll-mpl-parameter-configuration-02.txt Date: Wed, 31 Jul 2013 01:19:08 +0900 From: Yusuke DOI Reply-To: Routing Over Low power and Lossy networks To: roll@ietf.org Dear roll folks, I (and Matt Gillmore) have a proposal to make MPL configuration over DHCP o= ption. I'm on the IETF meeting so I really appriciate if anyone can take a = quick review on it and/or have F2F discussion. We're thinking of thousands of nodes under a LLNs. And we identified config= uration of MPL parameters is one of missing pieces for manageable large sca= le LLN. Regards, Yusuke -------- Original Message -------- Subject: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt Date: Mon, 29 Jul 2013 08:25:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : MPL Parameter Configuration Option for DHCPv6 Author(s) : Yusuke Doi Matthew Gillmore Filename : draft-doi-roll-mpl-parameter-configuration-02.txt Pages : 8 Date : 2013-07-29 Abstract: This draft is to define a way to configure MPL parameter via DHCPv6 option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-doi-roll-mpl-parameter-configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-doi-roll-mpl-parameter-configurati= on-02 Please note that it may take a couple of minutes from the time of submissio= n 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.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From yusuke.doi@toshiba.co.jp Mon Aug 12 19:19:17 2013 Return-Path: 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 3E9E211E8104 for ; Mon, 12 Aug 2013 19:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.49 X-Spam-Level: X-Spam-Status: No, score=-5.49 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihc6wt2xCTnH for ; Mon, 12 Aug 2013 19:19:10 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id D425611E80FE for ; Mon, 12 Aug 2013 19:19:06 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r7D2J5MY004310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Aug 2013 11:19:05 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r7D2J4LG003448 for ; Tue, 13 Aug 2013 11:19:04 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 933 for ; Tue, 13 Aug 2013 11:19:04 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r7D2J4eJ003439 for ; Tue, 13 Aug 2013 11:19:04 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r7D2J464008236 for dhcwg@ietf.org; Tue, 13 Aug 2013 11:19:04 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id MAA08233; Tue, 13 Aug 2013 11:19:04 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r7D2J4eb011845 for ; Tue, 13 Aug 2013 11:19:04 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r7D2J4Bc018257; Tue, 13 Aug 2013 11:19:04 +0900 (JST) Received: from [133.196.16.100] (ncg-dhcp100.isl.rdc.toshiba.co.jp [133.196.16.100]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 29DFA97D57; Tue, 13 Aug 2013 11:19:04 +0900 (JST) Message-ID: <52099798.9030101@toshiba.co.jp> Date: Tue, 13 Aug 2013 11:19:04 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <51F7E77C.5090607@toshiba.co.jp> <51FA1832.6050004@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E186553C6@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186553C6@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Fwd: [Roll] Request for Review: Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 02:19:17 -0000 Dear Bernie, Thank you very much for the review. (2013-08-13 06:29), Bernie Volz (volz) wrote: > 1. Please make sure to look at > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines. This > document is being adopted by the DHC WG and is critical to follow. Thanks, next revision will be with the guideline. > 2. While it may cost a few octets, I would strongly encourage you to > use separate fields for some items (such as C_K and DM_K). This will > cost you one octet but keeps the encoding simpler (flags, C_K, and > DM_K octets). Ok, two more octets will make no problem. Though, K>16 seems to be uncommon. > 3. The new data type (Unsigned Short Floating Point) will likely > delay implementation in some servers (or require 'manual' encoding). > If it is critical that this be used (instead of a more traditional > data type), so be it. This option is expected to be used in 6lowpan environment and message size matters. Not all DHCP servers are required to implement the options. Manual encoding (over hex) is also not too difficult. I'll add some implementation details on the next revision. > 4. As stated in draft-ietf-dhc-option-guidelines, this document does > specify that multiple instances are allowed (see > draft-ietf-dhc-option-guidelines-13, section 16). However, it makes > no statement as to whether the order is significant and that is > covered in draft-ietf-dhc-option-guidelines-13, section 17 (there > should be no IMPLICIT or EXPLICIT ordering with multiple options). Thanks, I'll clarify this. In short, there should be no effect on option order. I think I should explicitly say only one option is allowed for a MPL domain. > 5. You might document the possible length of the options as there > seems to be only two choices - X and X+16 (if C=1). Is C even > necessary? Could the option length (i.e., if MPL domain address is > present) be used to determine this? (It avoids having to test the > length if C=1 to make sure it is correct.) Right. I'll remove the C flag. > 6. I can say nothing about the utility of this option and whether the > data contained therein is appropriate as I am not an MPL expert - we > would defer to the ROLL WG in these regards. > > > > - Bernie Thank you very much and I'll soon submit updated revision. Yusuke From otroan@employees.org Tue Aug 13 01:20:09 2013 Return-Path: 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 3944321F9ADF for ; Tue, 13 Aug 2013 01:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqq+u0bgL-wC for ; Tue, 13 Aug 2013 01:20:03 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBDB21F999E for ; Tue, 13 Aug 2013 01:19:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAMTqCVKQ/khM/2dsb2JhbABbgwa/XIEcFnSCJAEBBAE6PxALRlcGLodvBrdKkA8zB4MbdgOUDZUogx06gSwH X-IronPort-AV: E=Sophos;i="4.89,867,1367971200"; d="scan'208";a="16610664" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 13 Aug 2013 08:19:40 +0000 Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (dhcp-lys01-vla250-10-147-112-207.cisco.com [10.147.112.207]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7D8Jcrx030614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 08:19:39 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <201308121436.r7CEahC4056298@givry.fdupont.fr> Date: Tue, 13 Aug 2013 10:19:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72F27EC4-B96B-46B1-9321-FF1DE439E841@employees.org> References: <201308121436.r7CEahC4056298@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:20:09 -0000 Francis, >>> First I am explaining my comment at the dhc/sunset4 meeting = yesterday: >>> "DHCPv4 is not really over UDP/IP" >>> What I mean is no genuine IPv4 stack is able to send or receive >>> a DISCOVER message from a booting device: this message has the >>> format of an UDP/IPv4/ethernet-like packet but has only the format. >>=20 >> can you explain what you mean by "DHCPv4 is not really over UDP/IP"? >=20 > =3D> I believe I explained what I mean by this statement? >=20 >>> - DHCPv4 over softwire works well if all nodes already have IPv4 >>> addresses. If they have none one enters in difficulties which are >>> IMHO the direct consequence of the "DHCPv4 is not really over >>> UDP/IP". So if the requirements include to asignment of IPv4 >>> addresses to nodes without one (and they should include this) then >>> the DHCPv4 over softwire is not a good solution. >>> Another point is DHCPv4 over softwire can require a ALG (Application >>> Level Gateway) at the server exit point in order to provide the >>> IPv6 address (or any topological ID) to the DHCPv4 server. >>=20 >> I tested DHCPv4 over a softwire with my favourite implementation and >> that worked out of the box. >=20 > =3D> did you check your favourite implementation is really using the > IP stack? Usually DHCPv4 uses a link-layer access like BPF so relies > on the correct support in the link-layer for this specific usage > (so it can work with one implementation but not the other, if > you are unlucky the client and the server won't interoperate, and > you'll have nobody to blame because the case is not described in > the specs...). my favourite implementation does indeed use the IP stack. that IP stack supports sending packets to the broadcast address from the = unspecified address. no magic with regards to that. my favourite implementation also give = direct access from applications to the link-layer for that matter. ;-) I don't understand what you mean by "not described in the specs".=20 >> DHCPv4 in that it uses broadcast requires a link-layer that supports >> broadcast. >> given that a softwire is a p2p link, it does support broadcast (and >> multicast). >=20 > =3D> usually the issue with DHCPv4 and encapsulation is not the packet > format (there is a straightforward way for it) but the sanity checks > at the other (here DHCPv4 server) side: how the set the expected = source > address without a little idea of what it is? > Note this doesn't make impossible to work, just it requires specific > support (and specifications if you want interoperability). sounds to me like you are describing problems that certain = implementations would have with implementing this. I gave existence proof of an implementation that = doesn't. >>> To finish it is not hard to modify a DHCPv4+DHCPv6 server code >>> to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6 >>> or even both over IPv6 and IPv4. The idea is to plug the IPv6 >>> I/O subsystem to the DHCPv6 handler. IMHO it should not be >>> significanly different (i.e., harder / easier) to support >>> DHCPv6 over DHCPv4 (note this is for the server code). >>=20 >> just to make my own views clear: >> - coupling IPv6 and IPv4 provisioning together is a bad idea >=20 > =3D> I believe you mean provisioning at the server side (note no > supported solution requires such a coupling). >=20 >> - I don't think requiring IPv4 specific configuration information >> on a softwire is necessary, if you really have to do it I'd prefer >> for the IPv4 provisioning protocol to run over the IPv4 data path >> (aka the softwire). and the same solution could be used for Public >> 4over6, LW46, MAP, L2TP... >=20 > =3D> the problem is sbout the IPv4 provisioning: if it includes IPv4 > address provisioning it should not run over the IPv4 data path. > BTW the I-D is not enough clear about this point to be a critical > requirement or not... (and I raised this concern in my review before > the slide about real (vs info only) DHCPv4 over softwire slide). you state that "IPv4 address provisioning should not run over the IPv4 = data path". what makes a softwire different from an Ethernet? it supports broadcast, and the restriction that the first-hop router = must be a DHCP relay or server applies, but what makes this link-type so different that we need to = invent new provisioning mechanics for it? when we designed e.g. 6rd and MAP that was certainly not the intention. cheers, Ole= From mohamed.boucadair@orange.com Tue Aug 13 08:05:51 2013 Return-Path: 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 1151721E813B; Tue, 13 Aug 2013 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDWEsoSp8hyU; Tue, 13 Aug 2013 08:05:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2B521E8167; Tue, 13 Aug 2013 08:05:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B94A9325BD6; Tue, 13 Aug 2013 17:05:44 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7D3BA4C060; Tue, 13 Aug 2013 17:05:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 13 Aug 2013 17:05:44 +0200 From: To: Ted Lemon Date: Tue, 13 Aug 2013 17:05:42 +0200 Thread-Topic: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: Ac6YMkNrU0f2lDfGQdWaco5tLR+YAQAAK6tg Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E99DA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEC7E99A8@PUEXCB1B.nanterre.francetelecom.fr> <5C06CABF-5797-484F-A8F9-ED2795CE0EE6@nominum.com> In-Reply-To: <5C06CABF-5797-484F-A8F9-ED2795CE0EE6@nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [dhcwg] [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:05:51 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: mardi 13 ao=FBt 2013 16:35 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers > >On Aug 13, 2013, at 9:11 AM, mohamed.boucadair@orange.com wrote: > >> * The design does not extend RFC3315 which does not exclude an option to >appear several times. > >Yes, it does. This is why work of this sort needs to be done in the DHC >working group, not in the PCP working group: that is where the expertise o= n >DHCP is. [Med] Fully agree. Apologies for not ccing dhcwg earlier (now cced). The in= itial message can be found here: http://www.ietf.org/mail-archive/web/pcp/c= urrent/msg03327.html=20 You think that because it is possible to represent this data in >a DHCP packet, that no changes are required in the protocol. But in fact >in order to implement what you have documented in the current draft, all >DHCP servers and DHCP clients will have to be modified. That is what it >means to update the DHCP protocol. Show me where in RFC 3315 there is >text describing how DHCP servers can indicate multiple servers by sending >multiple options, and can indicate multiple IP addresses on the same serve= r >by including them in the same option. [Med] RFC3315 says the following: "Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. If an option does appear multiple times, each instance is considered separate and the data areas of the options MUST NOT be concatenated or otherwise combined." RFC 3315 does not need to describe what is conveyed inside each instance of= the option and how that information is configured to the server. IMHO, thi= s is the responsibility of the option specification documents.=20 I agree there are some aspects which need to be discussed in a more generic= dhcp document such as the name resolution behavior at the dhcp server side= . What to do if both an IPv4 address and IPv6 addresses are returned, and s= o on. I'm referring to this text from the draft: The DHCP server may be configured with one or multiple FQDNs of the PCP server(s). In such case, the DHCP server must resolve these FQDNs into one or a list of IP addresses from pre-configured DNS server(s). If multiple FQDNs are configured to the DHCP server, the DHCP server must include multiple OPTION_PCP_SERVER instances; each of them carries one or a list of IP addresses that resulted from the FQDN resolution. DHCPv4 servers supporting PCP server option must resolve any configured FQDN into an IPv4 address while DHCPv6 servers may resolve any configured FQDN into an IPv6 and/or IPv4 address. If an IPv4 address is retrieved by the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is included in the OPTION_PCP_SERVER DHPCv6 option. If both IPv4 and IPv6 addresses are retrieved by the DHCPv6 server, these addresses are included in the same OPTION_PCP_SERVER DHPCv6 option (IPv4 addresses are represented as IPv4-mapped IPv6 addresses). Discussion: The motivation for this design is to accommodate deployment cases where an IPv4 connectivity service is provided while only DHPCv6 is in use (e.g., an IPv4-only PCP server in a DS-Lite context [RFC6333]).=20 If this discussion is included in [I-D.lemon-dhc-topo-conf], this would be = great and will let me remove that text from this one. > >> * As you can notice, no normative language is used in the server >guideline section. This is to accommodate existing implementations. > >An extension is required to get the behavior this document requires. Tha= t >is all that is needed for the document to be a protocol extension. If yo= u >fail to specify the details of how that extension works, that doesn't mean >you haven't extended the protocol: it just means you've done an incomplete >job of it. [Med] That section is only about configuration not about protocol extension= . I see you call this protocol extension.=20 > >> * There are already existing DHCP option specification documents which >allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.= ) > >Yes, that's true. See above. > >> * What is important IMHO is to make sure the client is expecting to >receive multiple options. > >That's certainly the most important part of this protocol extension, yes. >To be clear, it isn't enough that the client be prepared to accept multipl= e >options; clients can already do that. What is needed is for the client t= o >accept multiple options _and do the right thing_ with them. [Med] Agree, this is why a normative reference to draft-ietf-pcp-server-sel= ection is cited. The WG decided to remove that part from this draft and spe= cify it in the generic pcp server selection I-D (which is not specific to d= hcp).=20 From volz@cisco.com Wed Aug 14 20:41:38 2013 Return-Path: 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 4034421E808F for ; Wed, 14 Aug 2013 20:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lSSzGKxMXZP for ; Wed, 14 Aug 2013 20:41:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4F82211E810E for ; Wed, 14 Aug 2013 20:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29080; q=dns/txt; s=iport; t=1376538092; x=1377747692; h=from:to:subject:date:message-id:mime-version; bh=pxKSGFxks3zBZwKboKN4ChyEGJM9lBKauRew3vlaAaY=; b=CGZCmBlJFRQYXQ2OrPfpwgpgAMlqkSRPXYmvJrjCMm3RpT1ZF4P47OVS sWZwNnm48kzpu2j2sEupf4Ya3RzQYS4R13rxIIJ9Gg/gMG97wY291MkIK VvL1AUYSXmswejjbiuR6HQbYAuL5KfWw/lFD6CjROCyDcLO2HSIBHyvQb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAKtMDFKtJXG8/2dsb2JhbABbgkJENVC/IYEhFm0HgiQBAQEBAy1eAQgRBAEBCxYBBjkUCQkBBBMIDId8mRmgRZAfN4McdwOpNoMbgio X-IronPort-AV: E=Sophos;i="4.89,881,1367971200"; d="scan'208,217";a="247526617" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2013 03:41:31 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7F3fVsk017973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 Aug 2013 03:41:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.180]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 22:41:31 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: DHC WG Recharter - Updated Thread-Index: Ac6ZaJuDVz02hzpTQ9iqDr1GOrXX0g== Date: Thu, 15 Aug 2013 03:41:30 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1866D456@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.34] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1866D456xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] DHC WG Recharter - Updated X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 03:41:38 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1866D456xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the discussion at the DHC WG in Berlin (IETF-87), the revised char= ter was updated as below. Please comment as to whether you are happy with t= his version or if you have issues as I will ask Ted to send it to the IESG = on August 26th! --- Begin Proposed New Charter (DRAFT) The Dynamic Host Configuration working group (DHC WG) has developed DHCP fo= r automated allocation, configuration and management of IP addresses and TC= P/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is= documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standa= rd and is documented in RFC 3315. Subsequent RFCs document additional optio= ns and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definition= s of new DHCP options that are delivered using standard mechanisms with doc= umented semantics are not considered a protocol extension and thus are outs= ide of scope for the DHC WG. Such options should be defined within their re= spective WGs and reviewed by the DHCP Directorate. However, if such options= require protocol extensions or new semantics, the protocol extension work = must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new = applications and deployments of DHCP. The topics currently in development a= re: - DHCPv6 Failover, High Availability and Load Balancing - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Access Network Identifier - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) - DNS registration for SLAAC Additional topics may only be added with approval from the responsible Area= Director or by re-chartering. 2. Specify guidelines for creating new DHCPv6 options. 3. Develop documents that help explain operational considerations for the w= ider community. 4. Advance DHCPv6 (RFC 3315 and RFC 3633) along the IETF Standards Track. 5. Write analyses, corrections, and clarifications of the DHCPv6 specificat= ions, including RFC 3315, RFC 3633, RFC 3736 and other RFCs defining additi= onal options, which identifies and resolves ambiguities, contradictory spec= ifications and other obstacles to development of interoperable implementati= ons. --- End Proposed New Charter (DRAFT) - Tomek & Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, July 31, 2013 5:22 AM To: dhcwg@ietf.org Subject: [dhcwg] DHC WG Recharter - Thu 9:00-11:30 At Thursday's DHC WG session, please be prepared to discuss the re-charter.= The text is below. Proposed DHC WG Charter: The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: * Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Failover, High Availability and Load Balancing - DNS Update strategies for delegated prefixes (draft-ietf-dhc-dns-pd) - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Access Network Identifier (draft-ietf-dhc-access-network-identifier) - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) - Prefix coloring (draft-bhandari-dhc-class-based-prefix) Additional topics may only be added with approval from the responsible Area Director or by re-chartering. * Specify guidelines for creating new DHCPv6 options. * Develop documents that help explain operational considerations for the wider community. * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This will include writing analyses, corrections, and clarifications of the DHCPv6 specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs defining additional options, which identifies and resolves ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. END --_000_489D13FBFA9B3E41812EA89F188F018E1866D456xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the discussio= n at the DHC WG in Berlin (IETF-87), the revised charter was updated as bel= ow. Please comment as to whether you are happy with this version or if you = have issues as I will ask Ted to send it to the IESG on August 26th!

 

--- Begin Proposed New= Charter (DRAFT)

 

The Dynamic Host Configuration working group= (DHC WG) has developed DHCP for automated allocation, configuration and ma= nagement of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC = 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documente= d in RFC 3315. Subsequent RFCs document additional options and other enhanc= ements to the specifications.

 

The DHC WG is responsible for defining DHCP = protocol extensions. Definitions of new DHCP options that are delivered usi= ng standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for = the DHC WG. Such options should be defined within their respective WGs and = reviewed by the DHCP Directorate. However, if such options require protocol= extensions or new semantics, the protocol extension work must be done in the DHC WG.

 

The DHC WG has the following main objectives= :

 

1. Develop extensions to the DHCPv6 infrastr= ucture as required to meet new applications and deployments of DHCP. The to= pics currently in development are:

-          DHCPv6 Failover, High Availability a= nd Load Balancing

-          Extend DHCPv6 to work with multiple = provisioning domains

-          DHCP provisioning of IPv4 clients ov= er IPv6 networks

-          SOLMAXRT counter update

-          Container option

-          Access Network Identifier=

-          New NTP option to replace OPTION_NTP= _SERVER (RFC 5908)

-          DNS registration for SLAAC

 

Additional topics may only be added with app= roval from the responsible Area Director or by re-chartering.

 

2. Specify guidelines for creating new DHCPv= 6 options.

 

3. Develop documents that help explain opera= tional considerations for the wider community.

 

4. Advance DHCPv6 (RFC 3315 and RFC 3633) al= ong the IETF Standards Track.

 

5. Write analyses, corrections, and clarific= ations of the DHCPv6 specifications, including RFC 3315, RFC 3633, RFC 3736= and other RFCs defining additional options, which identifies and resolves ambiguities, contradictory specifications and othe= r obstacles to development of interoperable implementations.

 

--- End Proposed New C= harter (DRAFT)

 

-  = ;        Tomek & Be= rnie

 

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 31, 2013 5:22 AM
To: dhcwg@ietf.org
Subject: [dhcwg] DHC WG Recharter - Thu 9:00-11:30=

 

At Thursday’s DHC WG session, please be prepar= ed to discuss the re-charter. The text is below.

 

Proposed DHC WG Charter:

 

  The Dynamic Host Configuration working group (DHC W= G) has developed

  DHCP for automated allocation, configuration and ma= nagement of IP

  addresses and TCP/IP protocol stack parameters. DHC= Pv4 is currently

  a Draft Standard and is documented in RFC 2131 and = RFC 2132. DHCPv6

  is currently a Proposed Standard and is documented = in RFC 3315.

  Subsequent RFCs document additional options and oth= er enhancements to

  the specifications.

 

  The DHC WG is responsible for defining DHCP protoco= l extensions.

  Definitions of new DHCP options that are delivered = using standard

  mechanisms with documented semantics are not consid= ered a protocol

  extension and thus are outside of scope for DHC WG.= Such options should

  be defined within their respective WGs and reviewed= by the DHCP

  Directorate. However, if such options require proto= col extensions or new

  semantics, the protocol extension work must be done= in the DHC WG.

 

  The DHC WG has the following main objectives:<= /o:p>

 

  * Develop extensions to the DHCPv6 infrastruct= ure as required to meet

  new applications and deployments of DHCP. The topic= s currently

  in development are:

 

  - DHCPv6 Failover, High Availability and Load = Balancing

  - DNS Update strategies for delegated prefixes (dra= ft-ietf-dhc-dns-pd)

  - Extend DHCPv6 to work with multiple provisioning = domains

  - DHCP provisioning of IPv4 clients over IPv6 netwo= rks

  - SOLMAXRT counter update

  - Container option

  - Access Network Identifier (draft-ietf-dhc-ac= cess-network-identifier)

  - New NTP option to replace OPTION_NTP_SERVER (RFC = 5908)

  - Prefix coloring (draft-bhandari-dhc-class-based-p= refix)

 

    Additional topics may only be added wit= h approval from the responsible

    Area Director or by re-chartering.=

 

  * Specify guidelines for creating new DHCPv6 option= s.

 

  * Develop documents that help explain operational c= onsiderations for

    the wider community.<= /p>

 

  * Advance DHCPv6 (RFC 3315) along the IETF Standard= s Track. This will

  include writing analyses, corrections, and clarific= ations of the DHCPv6

  specifications, including RFC 3315, RFC3633, RFC373= 6 and other RFCs

  defining additional options, which identifies and r= esolves ambiguities,

  contradictory specifications and other obstacles to= development of

  interoperable implementations.

 

END

 

 

--_000_489D13FBFA9B3E41812EA89F188F018E1866D456xmbrcdx04ciscoc_-- From volz@cisco.com Wed Aug 14 20:49:20 2013 Return-Path: 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 0AA7C21E8113 for ; Wed, 14 Aug 2013 20:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syFJRkfjOTnX for ; Wed, 14 Aug 2013 20:49:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CB60511E81CC for ; Wed, 14 Aug 2013 20:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54912; q=dns/txt; s=iport; t=1376538553; x=1377748153; h=from:to:subject:date:message-id:mime-version; bh=8rT/cw2Hj3YhPplGDR7B58TX7gNJW0CBjaOYH5lklJE=; b=Zo+M0xXW5rM83/F6TN2p2pNRmxxFB6Q/XtHdT2Q1V9zBgTA1/aj4gwRD Ie+2KclDnLidYa062fr5OkH2woHfGQgugTd2eDfcbSSahE8Wh/voKacMA tkGLoxAgaAP3Pj0NIOOLcXEVChR1hk6lMXGVPDHXHfg/E/f8g9kMbACLs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcGAIBPDFKtJV2c/2dsb2JhbABbgkJENVC/IYEhFm0HgiQBAQEBAxoTPgIBHQEIEQQBAQsWAQY5FAkJAQQTCAELh3wMmRSgRI8DCgGBEQ0qgxx3A5QNlSmDG4FoAQgXIg X-IronPort-AV: E=Sophos;i="4.89,882,1367971200"; d="scan'208,217";a="247539051" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 15 Aug 2013 03:49:02 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7F3n2X1014230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 Aug 2013 03:49:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.180]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 22:49:02 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: DHC WG DHCP Directorate - Updated Thread-Index: Ac6ZaXpJvdqiKiX3QbO6YikAxKBMAA== Date: Thu, 15 Aug 2013 03:49:01 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1866D494@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.34] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1866D494xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 14 Aug 2013 20:50:12 -0700 Subject: Re: [dhcwg] DHC WG DHCP Directorate - Updated X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 03:49:20 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1866D494xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the discussion at the DHC WG in Berlin (IETF-87), the DHCP Directo= rate was updated as below. Please comment as to whether you are happy with = this version or if you have issues as I will ask Ted to do what is needed t= o initiate this directorate on August 26! The changes were in the "What Does the Directorate Do?" and "How is Documen= t Review Organized?" (4-7). DHCP Directorate The DHCP Directorate is an advisory group of DHCP experts selected by the I= nternet Area Directors. What Does the Directorate Do? The main purpose of the DHCP Directorate is to review all documents submitt= ed to the IESG for publication that define new DHCP (DHCPv6 or DHCPv4) opti= ons, DHCP messages, or DHCP client, relay agent or server processing to ens= ure that they are consistent with the DHCP specifications and other option = formats, that they do not duplicate existing mechanisms, etc. The Director= ate will not be responsible for evaluating the semantic content of proposed= options. Generally speaking, documents advanced by the DHC WG will have already rece= ived review from members of the DHCP Directorate and thus may not require s= uch review. The DHCP Directorate does not have a formal role in the standards approval = process. It is simply providing input for the Internet ADs who are deciding= how to ballot the document. The tasks performed by the Directorate are: 1. Review all documents submitted to the IESG for publication that have DHC= P options, messages, or processing requirements. A review is triggered: - By request for early review (by any AD or by any WG chair) - By a document moving to 'publication requested' state - By entry on the IESG agenda (for other documents) 2. Assist ADs with judgment issues when requested - The ADs may send email = to the directorate list when they have issues that they want help with. Exa= mples for judgment issues are: - New option formats - New client, relay, server agent processing 3. Try to follow IETF documents related to DHCP as early as possible and pr= ovide guidance to authors as early as possible. How is Document Review Organized? 1. The DHCP Directorate Coordinator assigns each document that is triggered= for review to at least two (2) reviewers and issues a Review Request. Auth= ors and contributors to a document must not be assigned. The Review Request= will include the document and review deadline. 2. The assigned reviewers must acknowledge and agree to review the document= within 72 hours and respond with a "can review by deadline" or "can't revi= ew". No reply is interpreted as "can't review". 3. If the Coordinator does not receive "can review by deadline" within 72 h= ours, the Coordinator selects at least one or two additional reviewers. Thi= s process is repeated until at least two reviewers are found. 4. The reviewers provide comments as appropriate (IETF Last Call, Area Dire= ctor, document authors). Comments must be provided in a transparent and tim= ely manner. 5. The Coordinator may decide to call upon additional reviewers, such as if= the expected review is overdue, or the topic under review is a complex one= , at the request of the Area Director, or there is conflict or contention i= n the reviews. 6. The reviews are sent to the DHCP Directorate mailing list and Internet A= Ds. Ordinarily, copies are sent to the authors/editors, the shepherding AD(= s), the relevant document shepherd(s) and working group chairs. The archiv= es are publicly viewable, at . 7. Reviews must include the following boilerplate text: I am an assigned DHCP directorate reviewer for . These comme= nts were written primarily for the benefit of the Internet Area Directors. = Document editors and shepherd(s) should treat these comments just like they= would treat comments from any other IETF contributors and resolve them alo= ng with any other Last Call comments that have been received. For more deta= ils on the DHCP Directorate, see http://www.ietf.org/iesg/directorate.html. How is the Directorate Formed? 1. Directorate members are assigned to the Directorate by the Internet Area= Directors. 2. There is an expectation that Directorate membership will not be limited = to 'old-time DHCP gods from years past'. It is assumed that the Directorate= will include younger and newer participants who are interested in 'learnin= g while doing work'. 3. Each assignment is for a three year term, unless the member or Internet = Area Director requests a shorter term. 4. The terms are staggered so that approximately 1/3 of the directorate mem= bers have their term end each year. 5. When the Directorate is first established members of the Directorate wil= l be assigned either one year, two years, or three years in their first ter= m. 6. When a member's term expires, the Internet ADs may replace the person wh= ose term expires, may reappoint the same person, or may reduce the size of = the Directorate. There is no expectation that the same person will either w= ant to be returned, or will be returned. 7. The three year term serves as the limit of the commitment of a Directora= te member, but also serves as a way to return Directorate members to the co= mmunity. 8. In deciding whether to reappoint a member whose term has expired, the In= ternet ADs may consider the quantity of work that they have done, the ADs' = impression of the quality of the work, and the comments from the authors an= d other Directorate members regarding the reviews. 9. If a member resigns before the member's term expires, the Internet Area = Directors may appoint a replacement. 10. The Internet Area Directors may remove a member before the member's ter= m expires, and may appoint a replacement. 11. Internet ADs can assign additional members to the Directorate whenever = they want to, subject to willingness of people to serve. 12. Both ADs need to agree in order to assign a member to the Directorate. 13. Both ADs select one of the Directorate members as the DHCP Directorate = Coordinator on a yearly basis. - Tomek & Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, July 31, 2013 5:25 AM To: dhcwg@ietf.org Subject: [dhcwg] DHC WG DHCP Directorate - Thu 9:00-11:30 At Thursday's DHC WG meeting please be prepared to discuss the DHCP Directo= rate. The proposed text is below: DHCP Directorate The DHCP Directorate is an advisory group of DHCP experts selected by the Internet Area Directors. The notion of a directorate is defined in RFC 2418 as follows: In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area. What Does the Directorate Do? The main purpose of the DHCP Directorate is to review all documents submitted to the IESG for publication that define new DHCP (DHCPv6 or DHCPv4) options, DHCP messages, or DHCP client, relay agent or server processing. Generally speaking, documents advanced by the DHC WG will have already received review from members of the DHCP Directorate and thus may not require such review. While the DHC WG is active, the DHCP Directorate is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The Directorate is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the Directorate will not be responsible for evaluating the semantic content of proposed options. The tasks performed by the Directorate are: 1. Review all documents submitted to the IESG for publication that have DHCP options, messages, or processing requirements. A review is triggered: - By request for early review (by any AD or by any WG chair) - By a document moving to 'publication requested' state - By entry on the IESG agenda (for other documents) 2. Assist ADs with judgment issues when requested - The ADs may send email to the directorate list when they have issues that they want help with. Examples for judgment issues are: - New option formats. - New client, relay, server agent processing. 3. Try to follow IETF documents related to DHCP as early as possible and provide guidance to authors as early as possible. How is Document Review Organized? 1. The DHCP Directorate Coordinator assigns each document that is triggered for review to at least two (2) reviewers and issues a Review Request. Authors and contributors to a document must not be assigned. The Review Request will include the document and review deadline. 2. The assigned reviewers must acknowledge and agree to review the document within 72 hours and respond with a "can review by deadline" or "can't review". No reply is interpreted as "can't review". 3. If the Coordinator does not receive "can review by deadline" within 72 hours, the Coordinator selects at least one or two additional reviewers. This process is repeated until at least two reviewers are found. 4. The reviewers provide comments as appropriate (IETF Last Call, Area Director, document authors). 5. The Coordinator may decide to call upon additional reviewers if expected review is overdue or the topic under review is a complex one. How is the Directorate Formed? 1. Directorate members are assigned to the Directorate by the Internet Area Directors. 2. There is an expectation that Directorate membership will not be limited to 'old-time DHCP gods from years past'. It is assumed that the Directorate will include younger and newer participants who are interested in 'learning while doing work'. 3. Each assignment is for a three year term, unless the member or Internet Area Director requests a shorter term. 4. The terms are staggered so that approximately 1/3 of the directorate members have their term end each year. 5. When the Directorate is first established members of the Directorate will be assigned either one year, two years, or three years in their first term. 6. When a member's term expires, the Internet ADs may replace the person whose term expires, may reappoint the same person, or may reduce the size of the Directorate. There is no expectation that the same person will either want to be returned, or will be returned. 7. The three year term serves as the limit of the commitment of a Directorate member, but also serves as a way to return Directorate members to the community. 8. In deciding whether to reappoint a member whose term has expired, the Internet ADs may consider the quantity of work that they have done, the ADs' impression of the quality of the work, and the comments from the authors and other Directorate members regarding the reviews. 9. If a member resigns before the member's term expires, the Internet Area Directors may appoint a replacement. 10. The Internet Area Directors may remove a member before the member's term expires, and may appoint a replacement. 11. Internet ADs can assign additional members to the Directorate whenever they want to, subject to willingness of people to serve. 12. Both ADs need to agree in order to assign a member to the Directorate. 13. Both ADs select one of the Directorate members as the DHCP Directorate Coordinator on a yearly basis. END --_000_489D13FBFA9B3E41812EA89F188F018E1866D494xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the discussio= n at the DHC WG in Berlin (IETF-87), the DHCP Directorate was updated as be= low. Please comment as to whether you are happy with this version or if you= have issues as I will ask Ted to do what is needed to initiate this directorate on August 26!

 

The changes were in th= e “What Does the Directorate Do?” and “How is Document Re= view Organized?” (4-7).

 

DHCP Directorate

 

The DHCP Directorate is an advisory group of= DHCP experts selected by the Internet Area Directors.

 

What Does the Directorate Do?<= /span>

 

The main purpose of the DHCP Directorate is = to review all documents submitted to the IESG for publication that define n= ew DHCP (DHCPv6 or DHCPv4) options, DHCP messages, or DHCP client, relay agent or server processing to ensure that they are c= onsistent with the DHCP specifications and other option formats, that they = do not duplicate existing mechanisms, etc.  The Directorate will not b= e responsible for evaluating the semantic content of proposed options.

 

Generally speaking, documents advanced by th= e DHC WG will have already received review from members of the DHCP Directo= rate and thus may not require such review.

 

The DHCP Directorate does not have a formal = role in the standards approval process. It is simply providing input for th= e Internet ADs who are deciding how to ballot the document.

 

The tasks performed by the Directorate are:<= o:p>

 

1. Review all documents submitted to the IES= G for publication that have DHCP options, messages, or processing requireme= nts. A review is triggered:

– &nbs= p;       By request for ear= ly review (by any AD or by any WG chair)

– &nbs= p;       By a document movi= ng to 'publication requested' state

– &nbs= p;       By entry on the IE= SG agenda (for other documents)

2. Assist ADs with judgment issues when requ= ested - The ADs may send email to the directorate list when they have issue= s that they want help with. Examples for judgment issues are:

– &nbs= p;       New option formats=

– &nbs= p;       New client, relay,= server agent processing

3. Try to follow IETF documents related to D= HCP as early as possible and provide guidance to authors as early as possib= le.

 

How is Document Review Organized?<= /b>

1. The DHCP Directorate Coordinator assigns = each document that is triggered for review to at least two (2) reviewers an= d issues a Review Request. Authors and contributors to a document must not be assigned. The Review Request will include the do= cument and review deadline.

2. The assigned reviewers must acknowledge a= nd agree to review the document within 72 hours and respond with a "ca= n review by deadline" or "can't review". No reply is interpreted as "can't review".

3. If the Coordinator does not receive "= ;can review by deadline" within 72 hours, the Coordinator selects at l= east one or two additional reviewers. This process is repeated until at least two reviewers are found.

4. The reviewers provide comments as appropr= iate (IETF Last Call, Area Director, document authors). Comments must be pr= ovided in a transparent and timely manner.

5. The Coordinator may decide to call upon a= dditional reviewers, such as if the expected review is overdue, or the topi= c under review is a complex one, at the request of the Area Director, or there is conflict or contention in the reviews.

6. The reviews are sent to the DHCP Director= ate mailing list and Internet ADs. Ordinarily, copies are sent to the autho= rs/editors, the shepherding AD(s), the relevant document shepherd(s) and working group chairs.  The archives are publ= icly viewable, at <TBD - insert URL here>.

7. Reviews must include the following boiler= plate text:

I am an assigned = DHCP directorate reviewer for <draft-foo.txt>. These comments were wr= itten primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like the= y would treat comments from any other IETF contributors and resolve them al= ong with any other Last Call comments that have been received. For more det= ails on the DHCP Directorate, see http://www.ietf.org/i= esg/directorate.html.

 

How is the Directorate Formed?=

1. Directorate members are assigned to the D= irectorate by the Internet Area Directors.

2. There is an expectation that Directorate = membership will not be limited to 'old-time DHCP gods from years past'. It = is assumed that the Directorate will include younger and newer participants who are interested in 'learning while doing work'.<= o:p>

3. Each assignment is for a three year term,= unless the member or Internet Area Director requests a shorter term.<= /o:p>

4. The terms are staggered so that approxima= tely 1/3 of the directorate members have their term end each year.

5. When the Directorate is first established= members of the Directorate will be assigned either one year, two years, or= three years in their first term.

6. When a member's term expires, the Interne= t ADs may replace the person whose term expires, may reappoint the same per= son, or may reduce the size of the Directorate. There is no expectation that the same person will either want to be return= ed, or will be returned.

7. The three year term serves as the limit o= f the commitment of a Directorate member, but also serves as a way to retur= n Directorate members to the community.

8. In deciding whether to reappoint a member= whose term has expired, the Internet ADs may consider the quantity of work= that they have done, the ADs' impression of the quality of the work, and the comments from the authors and other Directora= te members regarding the reviews.

9. If a member resigns before the member's t= erm expires, the Internet Area Directors may appoint a replacement.

10. The Internet Area Directors may remove a= member before the member's term expires, and may appoint a replacement.

11. Internet ADs can assign additional membe= rs to the Directorate whenever they want to, subject to willingness of peop= le to serve.

12. Both ADs need to agree in order to assig= n a member to the Directorate.

13. Both ADs select one of the Directorate m= embers as the DHCP Directorate Coordinator on a yearly basis.

 

–= ;   &= nbsp;  Tomek & Be= rnie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 31, 2013 5:25 AM
To: dhcwg@ietf.org
Subject: [dhcwg] DHC WG DHCP Directorate - Thu 9:00-11:30=

 

At Thursday’s DHC WG meeting please be prepare= d to discuss the DHCP Directorate. The proposed text is below:

 

DHCP Directorate

 

The DHCP Directorate is an advisory group of DHCP experts = selected by the

Internet Area Directors.

 

The notion of a directorate is defined in RFC 2418 as foll= ows:

 

  In many areas, the Area Directors have formed an ad= visory group or

  directorate. These comprise experienced members of = the IETF and the

  technical community represented by the area. The sp= ecific name and the

  details of the role for each group differ from area= to area, but the

  primary intent is that these groups assist the Area= Director(s), e.g.,

  with the review of specifications produced in the a= rea.

 

 

What Does the Directorate Do?

 

The main purpose of the DHCP Directorate is to review all = documents

submitted to the IESG for publication that define new DHCP= (DHCPv6 or

DHCPv4) options, DHCP messages, or DHCP client, relay agen= t or server

processing. Generally speaking, documents advanced by the = DHC WG will

have already received review from members of the DHCP Dire= ctorate and

thus may not require such review.

 

While the DHC WG is active, the DHCP Directorate is respon= sible for

reviewing DHCP options or other extensions (for both IPv4 = and IPv6). The

Directorate is expected to review all proposed extensions = to DHCP to

ensure that they are consistent with the DHCP specificatio= n and other

option formats, that they do not duplicate existing mechan= isms, etc.

Generally speaking, the Directorate will not be responsibl= e for evaluating

the semantic content of proposed options.

 

The tasks performed by the Directorate are:

 

1. Review all documents submitted to the IESG for publicat= ion that have

   DHCP options, messages, or processing require= ments. A review is

   triggered:

 

   - By request for early review (by any AD or b= y any WG chair)

   - By a document moving to 'publication reques= ted' state

   - By entry on the IESG agenda (for other docu= ments)

 

2. Assist ADs with judgment issues when requested - The AD= s may send email

   to the directorate list when they have issues= that they want help with.

   Examples for judgment issues are:<= /span>

 

   - New option formats.

   - New client, relay, server agent processing.=

 

3. Try to follow IETF documents related to DHCP as early a= s possible and

   provide guidance to authors as early as possi= ble.

 

 

How is Document Review Organized?

 

1. The DHCP Directorate Coordinator assigns each document = that is

   triggered for review to at least two (2) revi= ewers and issues a Review

   Request. Authors and contributors to a docume= nt must not be assigned.

   The Review Request will include the document = and review deadline.

2. The assigned reviewers must acknowledge and agree to re= view the

   document within 72 hours and respond with a &= quot;can review by deadline" or

   "can't review". No reply is interpr= eted as "can't review".

3. If the Coordinator does not receive "can review by= deadline" within 72

   hours, the Coordinator selects at least one o= r two additional reviewers.

   This process is repeated until at least two r= eviewers are found.

4. The reviewers provide comments as appropriate (IETF Las= t Call, Area

   Director, document authors).

5. The Coordinator may decide to call upon additional revi= ewers if

   expected review is overdue or the topic under= review is a complex one.

 

 

How is the Directorate Formed?

 

1.  Directorate members are assigned to the Directora= te by the Internet

    Area Directors.

2.  There is an expectation that Directorate membersh= ip will not be

    limited to 'old-time DHCP gods from yea= rs past'. It is assumed that

    the Directorate will include younger an= d newer participants who are

    interested in 'learning while doing wor= k'.

3.  Each assignment is for a three year term, unless = the member or Internet

    Area Director requests a shorter term.<= o:p>

4.  The terms are staggered so that approximately 1/3= of the directorate

    members have their term end each year.<= o:p>

5.  When the Directorate is first established members= of the Directorate

    will be assigned either one year, two y= ears, or three years in their

    first term.

6.  When a member's term expires, the Internet ADs ma= y replace the person

    whose term expires, may reappoint the s= ame person, or may reduce the

    size of the Directorate. There is no ex= pectation that the same person

    will either want to be returned, or wil= l be returned.

7.  The three year term serves as the limit of the co= mmitment of a

    Directorate member, but also serves as = a way to return Directorate

    members to the community.

8.  In deciding whether to reappoint a member whose t= erm has expired, the

    Internet ADs may consider the quantity = of work that they have done,

    the ADs' impression of the quality of t= he work, and the comments from

    the authors and other Directorate membe= rs regarding the reviews.

9.  If a member resigns before the member's term expi= res, the Internet

    Area Directors may appoint a replacemen= t.

10. The Internet Area Directors may remove a member before= the member's

    term expires, and may appoint a replace= ment.

11. Internet ADs can assign additional members to the Dire= ctorate whenever

    they want to, subject to willingness of= people to serve.

12. Both ADs need to agree in order to assign a member to = the Directorate.

13. Both ADs select one of the Directorate members as the = DHCP Directorate

    Coordinator on a yearly basis.

 

END

 

 

--_000_489D13FBFA9B3E41812EA89F188F018E1866D494xmbrcdx04ciscoc_-- From Francis.Dupont@fdupont.fr Thu Aug 15 06:55:53 2013 Return-Path: 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 F3BAC21F9E34 for ; Thu, 15 Aug 2013 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBOW4GKRsViA for ; Thu, 15 Aug 2013 06:55:52 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E624521E8139 for ; Thu, 15 Aug 2013 06:55:47 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r7FDsM6R009294; Thu, 15 Aug 2013 15:54:22 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308151354.r7FDsM6R009294@givry.fdupont.fr> From: Francis Dupont To: Ole Troan In-reply-to: Your message of Tue, 13 Aug 2013 10:19:38 +0200. <72F27EC4-B96B-46B1-9321-FF1DE439E841@employees.org> Date: Thu, 15 Aug 2013 15:54:22 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dhcwg@ietf.org Subject: Re: [dhcwg] about v4configuration and co (1) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 13:55:53 -0000 In your previous mail you wrote: > my favourite implementation does indeed use the IP stack. that IP > stack supports sending packets to the broadcast address from the > unspecified address. => this is really not standard: usually when the source address is left unspecified the kernel replaces it by one of the addresses of the host... > no magic with regards to that. my favourite implementation also give > direct access from applications to the link-layer for that matter. ;-) => this is common to all OSs, unfortunately without a standardized way. > I don't understand what you mean by "not described in the specs". => there is no "DHCP over foo" for a generic foo, even for a generic tunnel. In fact DHCP (and BOOTP) has to be specialized for each link (hardware in specs) layer, so have to be described in some specs. > you state that "IPv4 address provisioning should not run over the IPv4 > data path". => yes, it is my opinion and it seems this opinion is shared by many other persons in the list. > what makes a softwire different from an Ethernet? => Ethernet is a hardware link layer > what makes this link-type so different that we need to > invent new provisioning mechanics for it? => separation of control and data planes, or with other words simpler bootstrap/setup without a critical element (the source IPv4 address) unknown a priori. > when we designed e.g. 6rd and MAP that was certainly not the intention. => if we have today this discussion it is because the problem was not addressed from the beginning in the design. Regards Francis.Dupont@fdupont.fr From volz@cisco.com Fri Aug 16 19:31:56 2013 Return-Path: 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 A50D511E81FF for ; Fri, 16 Aug 2013 19:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE2EUccXCj39 for ; Fri, 16 Aug 2013 19:31:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48B11E81F2 for ; Fri, 16 Aug 2013 19:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15421; q=dns/txt; s=iport; t=1376706711; x=1377916311; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rP7zKLSfcaXXuXq6n2OApnlUJOHdPe5amNTcYmvbGPI=; b=nLG/0GEdBtsOTLZ74I+BKF8TStV+SiEZ0PeLORBuaPM4xzx2vE1XEM+1 fJsBqY3NEBpGW8jVH/jtwMR3lze2PkVl5eYs8gcMyjnwP0SC0mW/EW7BC UwiZigEsRqgkOr5YIvWep32TpZzsSWerQp/7+OEiFaOozTegOpbU0FgBB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGAIjfDlKtJXG9/2dsb2JhbABbgkJENVG2XohGgSkWbQeCJAEBAQQtRBgCAQgRBAEBCx0HMhQJCAEBBBMIiAgMuTSPA4EcNwGDG3cDmRGQKIFhgTuBaAcCFyI X-IronPort-AV: E=Sophos;i="4.89,899,1367971200"; d="scan'208,217";a="248470302" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 17 Aug 2013 02:31:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7H2VoqV025333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 17 Aug 2013 02:31:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.180]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 21:31:49 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! Thread-Index: Ac6Eh+GxcVMnIa4YTCqgEkgg655xbgWZzzNQ Date: Sat, 17 Aug 2013 02:31:49 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1867159F@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.99] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1867159Fxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 02:31:56 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1867159Fxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I finally had some time to carefully review this document (though it is lat= e). But it turned out that Kim (co-author) was away this past week and so l= ikely not much would have happened with the document anyway (see below). An= d, a few indicated they would prefer to have a bit more time (given the IET= F meeting and vacations). I do support this document moving forward. However, the 03 version does have a bunch of mostly nits. And, I have a mar= ked up paper version which I will review with Kim (hopefully over the next = few days, but he may be busy catching up after having been away). I'd rathe= r not have to list all of these nits in an email (spelling corrections, wor= ding changes, minor errors). There are several TODOs in the document and a = reference (TODO) to a non-existent section (on automatic transition of a se= rver to partner-down after a configured time interval). I'd also suggest dr= opping some text, such as 8.2 Time Expression, as that belongs in a protoco= l document, not the design (there's no other text dependent on it). These m= ust be cleaned up before sending the document on. Reviewing my marked up document with Kim and having him update the document= will likely be the best way to go (though of course there is no list to se= nd out). But again, there's no significant flaws or issue that I found. Jus= t a lot of fairly minor cleanup to do. I hope to discuss the WGLC status with Tomek early next week (8/19) and the= n we will communicate the results. If anyone else has any comments in support (or not) of the WGLC on this doc= ument, please let us know (by 8/19). - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Friday, July 19, 2013 9:59 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respon= d by August 9, 2013! Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tool= s.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe it is ready = for working group last call. Please review this draft and indicate whether = or not you feel it is ready to be published. Your input is important! This document is the 2nd series of documents related to DHCPv6 failover - t= he first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requi= rements which is currently being reviewed by the IESG for publication appro= val. At the time of this writing, there is no IPR reported against this draft. As Tomek is a co-author, I will primarily evaluate consensus after 2013-08-= 09 (August 9th). This is a 3 week last call because of the Berlin IETF meet= ing and also because of summer-time vacations (at least for those of us in = the northern hemisphere). Thanks, - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1867159Fxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I finally had some tim= e to carefully review this document (though it is late). But it turned out = that Kim (co-author) was away this past week and so likely not much would h= ave happened with the document anyway (see below). And, a few indicated they would prefer to have a bit more tim= e (given the IETF meeting and vacations).

 

I do support this docu= ment moving forward.

 

However, the 03 versio= n does have a bunch of mostly nits. And, I have a marked up paper version w= hich I will review with Kim (hopefully over the next few days, but he may b= e busy catching up after having been away). I’d rather not have to list all of these nits in an email (sp= elling corrections, wording changes, minor errors). There are several TODOs= in the document and a reference (TODO) to a non-existent section (on autom= atic transition of a server to partner-down after a configured time interval). I’d also suggest dropping some te= xt, such as 8.2 Time Expression, as that belongs in a protocol document, no= t the design (there’s no other text dependent on it). These must be c= leaned up before sending the document on.

 

Reviewing my marked up= document with Kim and having him update the document will likely be the be= st way to go (though of course there is no list to send out). But again, th= ere’s no significant flaws or issue that I found. Just a lot of fairly minor cleanup to do.<= /p>

 

I hope to discuss the = WGLC status with Tomek early next week (8/19) and then we will communicate = the results.

 

If anyone else has any= comments in support (or not) of the WGLC on this document, please let us k= now (by 8/19).

 

-&nb= sp;         Bernie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Friday, July 19, 2013 9:59 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 -= Respond by August 9, 2013!

 

Folks, the authors of draft-ietf-dhc-dhcpv6-failo= ver-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-= design) believe it is ready for working group last call. Please review this draft and indicate whether or = not you feel it is ready to be published. Your input is important!

 

This document is the 2nd series of doc= uments related to DHCPv6 failover – the first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements = which is currently being reviewed by the IESG for publication approval.

 

At the time of this writing, there is no IPR repo= rted against this draft.

 

As Tomek is a co-author, I will primarily evaluat= e consensus after 2013-08-09 (August 9th). This is a 3 week last= call because of the Berlin IETF meeting and also because of summer-time va= cations (at least for those of us in the northern hemisphere).

 

Thanks,

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1867159Fxmbrcdx04ciscoc_-- From tomasz.mrugalski@gmail.com Mon Aug 19 07:52:20 2013 Return-Path: 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 3B74621F92B7 for ; Mon, 19 Aug 2013 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyF1T5sq86s2 for ; Mon, 19 Aug 2013 07:52:19 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 15FCD11E8113 for ; Mon, 19 Aug 2013 07:52:11 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so1025471eek.29 for ; Mon, 19 Aug 2013 07:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=yAQNlOa6NKg0pel5dCmEEdR8NYNUCpgPLcwh7i7q54o=; b=07K5egKbhWjrmcbWqFoe9V0ZEcG+spVyJ7fLAJs0XN+Oe+uJhP3w2nwTQ6PoAa5YpJ 9uZMcIJ5ktETct+OfzbZmAYIg+G7dq2IIlcAvqMmT9k45ZmMun8w/V6oHAHOfumdrwFD ybDhxRrlHJHO7TCDFZ9Q41w5jV7gCdwAaMhXLsous5Sv57AlnHLWOdroQ5Z/iBbOrWDz +r/8ESlxfx+s3dVvWkyQLMUUt+rk5rZdVZiIyF43MsMKD77Ysee1Znt24RjXtnDtYYrU +aNgl2fNknNup4D6CYXUc/7eWqaTXWQvD6OlxX0Z62PzU9QXXR2NMVb8GElLQ6PFl2xl 2uhg== X-Received: by 10.14.88.65 with SMTP id z41mr23103287eee.38.1376923931206; Mon, 19 Aug 2013 07:52:11 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id r48sm17949289eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 07:52:09 -0700 (PDT) Message-ID: <52123110.10205@gmail.com> Date: Mon, 19 Aug 2013 16:52:00 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:52:20 -0000 During Berlin meeting chairs asked if there is still interest in the prefix-pool-option. There was nobody interested in the work in the room. The unanimous consensus in the room was to drop it. I just wanted to confirm that on the list. If you are interested in this work, want to support it and participate in it, please let us know by replying to the mailing list. Otherwise we'll drop this work and mark that draft as a dead WG document. Please respond within 2 weeks (until Sep. 2nd). Bernie & Tomek From tomasz.mrugalski@gmail.com Mon Aug 19 11:52:07 2013 Return-Path: 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 6C8EF11E815A for ; Mon, 19 Aug 2013 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-m4FIqXtJi for ; Mon, 19 Aug 2013 11:52:06 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 365CF21F9D07 for ; Mon, 19 Aug 2013 11:52:06 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so2306788eek.5 for ; Mon, 19 Aug 2013 11:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mt9hDblIJ853Wy//htia4YXbfinpEk8bJl3e54DuXRM=; b=wDlBEf8EhIRJs/HSav7SsxsyavDiwJGjuWIexlwqbdD/U1aPrihuEgxaW1vBFBnig0 rDaw/2LSFJYo6YaGu/dXWnlGfPKegA9ndTcrc+Tucn3FpgZgm6/UB7knEppSiVQ7V2fK AryTRrF3ylo5MGKIij/RIVuy5liFnAjySGOiRTYaCZLDBYsUgHmuzGfgaKwI4QtsuOCX iZsTmbZbygU6O6dKAedYGy+90LYKk3L28d4hSs0pFNkdhO+QiRr9uNDHu81Rp9UkBoad ymjGn6gM72Us6e3im6HHo208kJ52SFy95EJfkRzps0x5bwcgNEk80I9CNqbZS8bY4lan FNmA== X-Received: by 10.15.43.13 with SMTP id w13mr24723529eev.37.1376938325063; Mon, 19 Aug 2013 11:52:05 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id l47sm19206634eex.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 11:52:03 -0700 (PDT) Message-ID: <5212694A.6000807@gmail.com> Date: Mon, 19 Aug 2013 20:51:54 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130819205154302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:52:08 -0000 On 12.08.2013 21:21, Bernie Volz (volz) wrote: > During the Berlin IETF-87 DHC WG session, it was suggested that we > initiate a standards action request to move RFC 3315 (and RFC 3633), > which are presently Proposed Standards, to Internet Standard. While we > plan to work on a 3315bis which would merge the work, it was pointed out > by several people (include our Area Director) that there is technically > no need to wait for that to advance the standards. > > The requirements for advancement are outlined in RFC 2026 and RFC 6410 > (which removed Draft Standard). > > Per RFC 6410: > > The criteria are: > > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. There are many more than just two. > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. There are known issues, e.g. those described in draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of annoyance, rather than interoperability breaking problems. New implementations are interoperating with existing ones without problems. > (3) There are no unused features in the specification that greatly > increase implementation complexity. That's an interesting question. Are there any implementations that implement the whole RFC3315? I mean really everything: reconfiguration, reconfigure-key, delayed auth, replay detection, sending CONFIRM when link state changes, sending DECLINE if DAD fails, rapid-commit, supporting 32 relays, all 3 duid types etc.? That's a trick question. I have my own answer for it, but I'd like to hear WG opinion on that matter. > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. There are no IPRs claimed against RFC3315 and RFC3633. Ok, so in my opinion all criteria are met. > Please provide input as to whether you support making this request of > the IETF/IESG (via the Internet Area Directors) or whether you feel > there are issues (based on the above criteria). If you feel one document > is ready but the other isn’t, please let us know about that too. I feel that we should move forward with this for both 3315 and 3633. There's almost 7000 RFCs published, but there are only 96 that have Internet Standard status. I strongly believe that DHCPv6 is one of core Internet protocols. This status change would reflect that. With my chair on, I'm disappointed that nobody responded to this mail so far. Chairs got couple comments off the list, but nobody said anything on the list. I don't know, perhaps people are not that much interested, because this move does not have any immediate practical repercussions. Or perhaps it is a middle of vacation time... Come on, guys. Saying +1 doesn't take much time. ;-) Tomek From iesg-secretary@ietf.org Mon Aug 19 15:06:51 2013 Return-Path: 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 8536F21F9C2C; Mon, 19 Aug 2013 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DE7eU5fPQkj; Mon, 19 Aug 2013 15:06:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F8621F8895; Mon, 19 Aug 2013 15:06:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819220633.6777.1508.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 15:06:33 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'RADIUS Option for DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 22:06:51 -0000 The IESG has approved the following document: - 'RADIUS Option for DHCPv6 Relay Agent' (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ Technical Summary: This document defines RADIUS DHCPv6 option that is similar to its DHCPv4 counter-part that was defined in RFC4014. The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. Working Group Summary: This document was called draft-yeh-dhc-dhcpv6-authorization-opt prior to its adoption. There was unanimous support for it (9 people in favor of adoption and none against), so this document was adopted in May 2012. There was quite high interest in this work - 55 posts since its adoption. There was never any opposition for this work. Document Quality: I'm not aware of any existing implementations, but the level of support from both DHCP vendors (Nominum, Weird Solutions, Cisco, ISC), hardware vendors (Huawei, Cisco) and operators (Orange, Telecom Italia) suggests that this will be implemented and deployed shortly after option code is assigned by IANA. There was no single lead reviewer and many people contributed to the draft (55 posts about it to DHC list, 41 posts to RADEXT during its WG life). This document went through rapid updates (10 revisions 10 months), because its lead author - Leaf Yeh - was eager to address any comments as soon as they appeared. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tomek Mrugalski is the document shepherd. Ted Lemon is the responsible AD. From iesg-secretary@ietf.org Mon Aug 19 15:10:10 2013 Return-Path: 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 EF8E511E8306; Mon, 19 Aug 2013 15:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMk4NCniyPBp; Mon, 19 Aug 2013 15:10:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EED9E11E831F; Mon, 19 Aug 2013 15:10:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819221003.10906.59949.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 15:10:03 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Document Action: 'DHCPv6 Failover Requirements' to Informational RFC (draft-ietf-dhc-dhcpv6-failover-requirements-07.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 22:10:10 -0000 The IESG has approved the following document: - 'DHCPv6 Failover Requirements' (draft-ietf-dhc-dhcpv6-failover-requirements-07.txt) as Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ Technical Summary This document outlines the requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. Working Group Summary The need for a DHCPv6 failover protocol had been discussed by the WG ever since RFC 3315 was published. After some discussion on how to approach this work given the lack of progress for the DHCPv4 draft (draft-ietf-dhc-failover), work was begun in June 2011 on the first of a possible series of documents. And adopted by the WG in October 2011. The document has good support from key individuals (those that worked on or implemented the DHCPv4 failover draft), but does lack broad support - though no one raised any objection to the work. Document Quality The document builds on earlier DHCPv4 work (draft-ietf-dhc-failover). The document has had a thorough review by a small number of very interested and knowledgable folks (mentioned in the acknowledgements section). There were no significant points of difficulty or controversy, primarily as this work builds on earlier DHCPv4 work. Personnel Bernie Volz is the document shepherd. Ted Lemon is the responsible AD. From leaf.yeh.sdo@gmail.com Tue Aug 20 09:36:59 2013 Return-Path: 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 9B0BD21F90DC for ; Tue, 20 Aug 2013 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQFTHi10CpXj for ; Tue, 20 Aug 2013 09:36:59 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6C85321F8267 for ; Tue, 20 Aug 2013 09:36:52 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so605589pde.37 for ; Tue, 20 Aug 2013 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=2DPDcNtbKYvZi/x/EzgoS3a50pA3XWvgtomvKo1sxfA=; b=ye/JufS3r9wSMKp3GtOkqmzOhnnFu5db/+l1tyMHgzNd4C/wSA+PUW4t1eP575JKxA tiZ0sDpFCBfIkicWFx7Tjax65R+NA335cD2gsCrUBG8Fswy4jW6wih1td8hxi8NDnF25 JsbwDNDDKpFgTck2qiPMrqJFBeGXxuOS+ww79kEfjgGT7q4YU8PUwN7lh5W1yejmBr+l JVUsbtZdKiiRlmStmd3wF8glz3NqQUx1kAXVx+FJtEQzeojavIC+AWi1jKdtjvlk6Otf +k88GIBElYoOzUxzHp2G+PHoRgxG5Usxlcg3g54xawzkIzqLBrK24PhxvUeXaB9ZjFdX xIQg== X-Received: by 10.67.1.228 with SMTP id bj4mr4705924pad.157.1377016612112; Tue, 20 Aug 2013 09:36:52 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id fk4sm4746392pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 20 Aug 2013 09:36:51 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" , "'dhcwg'" References: <52123110.10205@gmail.com> In-Reply-To: <52123110.10205@gmail.com> Date: Wed, 21 Aug 2013 00:36:44 +0800 Message-ID: <52139b23.0466420a.469b.fffff843@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6c67gVmsgM331GR+GWebfMyapCyAAZ7JzA Content-Language: zh-cn Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:36:59 -0000 I believe the WG-draft (OPTION_PREFIX_POOL) does put forward a problem that occurs in IPv6 deployment, which need route aggregation at the PE router. The question about working interest here might include 3 parts of meaning: 1. Do we need a dynamic configuration mechanism for the route aggregation here? I guess some guys could live with the manual configuration for the route aggregation here. In the ipv4 deployment, we always need configure IPv4 address for the associated interface on the router, which is in the same subnet of the addresses assigned the CE or subscribers' hosts. The point of this draft is that we need automatic configuration mechanism for the aggregated route on IPv6 router, while we are not necessary to configure ipv6 address for the associated interface. 2. Do we need a mechanism tightly coupled with DHCPv6-PD (RFC3633) mechanism? The alternative solution might be that the relay could communicate with the server independently with DHCPv6-PD, which sounds more general for each kind of possible parameter on the router. The point of this draft is that router aggregation sounds only associated with the DHCPv6-PD and its prefix pool. The newly defined option and its associated mechanism could solve the problem in the easiest way, and not introduced new DHCPv6 message; but the option will always be included in the DHCPv6-PD message by the relay and the server. 3. Do we need a mechanism patented by Huawei? It depends on what you read from the IPR disclosure (https://datatracker.ietf.org/ipr/2051/ ) of Huawei. Per the message on the web, my reading is that their terms are defensive and harmless if you don't assert patent against Huawei, though the IPR disclosure looks too late. Best Regards, Leaf (one of the authors) -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Monday, August 19, 2013 10:52 PM To: dhcwg Subject: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? During Berlin meeting chairs asked if there is still interest in the prefix-pool-option. There was nobody interested in the work in the room. The unanimous consensus in the room was to drop it. I just wanted to confirm that on the list. If you are interested in this work, want to support it and participate in it, please let us know by replying to the mailing list. Otherwise we'll drop this work and mark that draft as a dead WG document. Please respond within 2 weeks (until Sep. 2nd). Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Tue Aug 20 12:35:38 2013 Return-Path: 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 EE8B911E8171; Tue, 20 Aug 2013 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMqb-dx-zXUN; Tue, 20 Aug 2013 12:35:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC48311E827B; Tue, 20 Aug 2013 12:35:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130820193536.20768.97826.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2013 12:35:36 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 19:35:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Modification to Default Values of SOL_MAX_RT and INF_MAX= _RT Author(s) : Ralph Droms Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-03.txt Pages : 7 Date : 2013-08-20 Abstract: This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT, and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with a new value. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-solmaxrt-update-03 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/ From iesg-secretary@ietf.org Tue Aug 20 15:23:15 2013 Return-Path: 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 9CC5A11E8301; Tue, 20 Aug 2013 15:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2wNZrGk28oC; Tue, 20 Aug 2013 15:23:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C711E82FA; Tue, 20 Aug 2013 15:20:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130820222025.447.11518.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2013 15:20:25 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Modification to Default Values of SOL_MAX_RT and INF_MAX_RT) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:23:16 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Modification to Default Values of SOL_MAX_RT and INF_MAX_RT' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT, and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with a new value. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update/ballot/ No IPR declarations have been submitted directly on this I-D. From mohamed.boucadair@orange.com Wed Aug 21 05:41:46 2013 Return-Path: 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 001E611E820F for ; Wed, 21 Aug 2013 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk5nofos89xL for ; Wed, 21 Aug 2013 05:41:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A5DA111E8212 for ; Wed, 21 Aug 2013 05:41:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BAA2A22C76F; Wed, 21 Aug 2013 14:41:40 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A17114C015; Wed, 21 Aug 2013 14:41:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 21 Aug 2013 14:41:40 +0200 From: To: Tomek Mrugalski , dhcwg Date: Wed, 21 Aug 2013 14:41:39 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6c67dLSMBnbyViSiqTBWpeKhKKzgBfrVKg Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> In-Reply-To: <52123110.10205@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 12:41:46 -0000 Hi Tomek, I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a useful f= eature in order to have more automation and also control routes aggregation= instead of relying on proprietary behaviors of each implementation. Of cou= rse, part of these objectives can be achieved if routes are installed manua= lly or use an out of band mechanism to enforce routing aggregation policies= . Still, the proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior = because the DHCP server has the knowledge of the prefix assignments; and th= erefore routes can be triggered with dhcpv6 . A way to progress with this document is to target the Experimental track. B= ased on the experience that will be gained in real deployments, the status = can be revisited if required. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Tomek Mrugalski >Envoy=E9=A0: lundi 19 ao=FBt 2013 16:52 >=C0=A0: dhcwg >Objet=A0: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > >During Berlin meeting chairs asked if there is still interest in the >prefix-pool-option. There was nobody interested in the work in the room. >The unanimous consensus in the room was to drop it. I just wanted to >confirm that on the list. > >If you are interested in this work, want to support it and participate >in it, please let us know by replying to the mailing list. Otherwise >we'll drop this work and mark that draft as a dead WG document. > >Please respond within 2 weeks (until Sep. 2nd). > >Bernie & Tomek >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Wed Aug 21 06:24:33 2013 Return-Path: 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 E761D11E8216 for ; Wed, 21 Aug 2013 06:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sE2Fx4OyLHN for ; Wed, 21 Aug 2013 06:24:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9156511E83A6 for ; Wed, 21 Aug 2013 06:24:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7LDOPtB015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Aug 2013 15:24:25 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7LDOPnl024519 for ; Wed, 21 Aug 2013 15:24:25 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7LDOKVZ007356 for ; Wed, 21 Aug 2013 15:24:25 +0200 Message-ID: <5214BF85.8020509@gmail.com> Date: Wed, 21 Aug 2013 15:24:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 13:24:34 -0000 Hi, One point I think is essential is the installment of routes in the DHCP Relay upon Prefix Assignment. The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must install a route in the DHCP Relay upon delegation. This draft seems to at least assume it, and to describe much more about it: how various parts of assigned prefixes are aggregated and communicated. I support it. Alex Le 21/08/2013 14:41, mohamed.boucadair@orange.com a écrit : > Hi Tomek, > > I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a > useful feature in order to have more automation and also control > routes aggregation instead of relying on proprietary behaviors of > each implementation. Of course, part of these objectives can be > achieved if routes are installed manually or use an out of band > mechanism to enforce routing aggregation policies. Still, the > proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior > because the DHCP server has the knowledge of the prefix assignments; > and therefore routes can be triggered with dhcpv6 . > > A way to progress with this document is to target the Experimental > track. Based on the experience that will be gained in real > deployments, the status can be revisited if required. > > Cheers, Med > >> -----Message d'origine----- De : dhcwg-bounces@ietf.org >> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >> Envoyé : lundi 19 août 2013 16:52 À : dhcwg Objet : [dhcwg] Anyone >> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >> >> During Berlin meeting chairs asked if there is still interest in >> the prefix-pool-option. There was nobody interested in the work in >> the room. The unanimous consensus in the room was to drop it. I >> just wanted to confirm that on the list. >> >> If you are interested in this work, want to support it and >> participate in it, please let us know by replying to the mailing >> list. Otherwise we'll drop this work and mark that draft as a dead >> WG document. >> >> Please respond within 2 weeks (until Sep. 2nd). >> >> Bernie & Tomek _______________________________________________ >> dhcwg mailing list dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > From tomasz.mrugalski@gmail.com Wed Aug 21 07:21:30 2013 Return-Path: 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 3D8F611E80F1 for ; Wed, 21 Aug 2013 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGlF4+chZer8 for ; Wed, 21 Aug 2013 07:21:29 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26111E8105 for ; Wed, 21 Aug 2013 07:21:23 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so267083ead.31 for ; Wed, 21 Aug 2013 07:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oVVWr+1Bi/uq69CwH0ebqdiq/7t8NJrRlhV+nD127jU=; b=BkqyL1bKICf1vFAsNLKIfmfKFk35G7kqqYk9o6vawgNRLgFNRKH213I0KqZDyRogPo mUPIh472aPlizVwlchjQKpn8HGEKmFqOv/U1KfPU6Yl3MI6kI1YTcZtPcMQsDpGJvkRU MzREvZlXcrHYhLnn2mM6deS9n1y3j3xrNyRLvw0uZFtvH0w3gan132uGBIR3FDQMYBjY XX0WBRuCb1png2NEj7dI/9ocX7+j2N9VkAD0FMSk/1q5v6cq5XrKpkzJzrT6XzlGA8KI Vrhk9OMy+d6vCz9z41MFwPBh/nUMXYQ2NdM1GnQ7QAqR3WPQ1JvSlJjnhr6UCTUprEZ7 6Qsg== X-Received: by 10.15.48.67 with SMTP id g43mr10945390eew.17.1377094881557; Wed, 21 Aug 2013 07:21:21 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id x47sm10131434eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 07:21:20 -0700 (PDT) Message-ID: <5214CCDC.3090308@gmail.com> Date: Wed, 21 Aug 2013 16:21:16 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130821162116244 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:21:30 -0000 On 21.08.2013 14:41, mohamed.boucadair@orange.com wrote: > Hi Tomek, > > I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a > useful feature in order to have more automation and also control > routes aggregation instead of relying on proprietary behaviors of > each implementation. Of course, part of these objectives can be > achieved if routes are installed manually or use an out of band > mechanism to enforce routing aggregation policies. Still, the > proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because > the DHCP server has the knowledge of the prefix assignments; and > therefore routes can be triggered with dhcpv6 . > > A way to progress with this document is to target the Experimental > track. Based on the experience that will be gained in real > deployments, the status can be revisited if required. No, sorry. That won't work. At least not as you'd like it to. Take a look at IANA registry for DHCPv6 options: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml. It clearly states that assigning option codes require experts review *and* standards action. Experimental drafts are not standards. You are certainly welcome to proceed with this as experimental, but my understanding of the process is that it would be published without options assigned. And the draft (or experimental RFC) without option code is really useless, because it is unlikely that any verndor would implement it. As a side comment, currently assigning the option code for DHCPv6 requires experts review. Let me cite the complete list: Ted Lemon. While Ted Lemon is certainly a DHCPv6 expert, the standardization process should not rely on a single person. If Ted becomes unavailable for whatever reason (e.g. wins a lottery and decides to retire tomorrow on his private island), we wouldn't get new DHCPv6 options any more. I suppose that is something that should be corrected one day, probably together with the registry name. Tomek From mohamed.boucadair@orange.com Wed Aug 21 07:41:54 2013 Return-Path: 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 A1EA121F9BEF for ; Wed, 21 Aug 2013 07:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BRjL3hm762V for ; Wed, 21 Aug 2013 07:41:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F021F9BBF for ; Wed, 21 Aug 2013 07:41:42 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 23C473B4489; Wed, 21 Aug 2013 16:41:41 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id F202A15805B; Wed, 21 Aug 2013 16:41:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 21 Aug 2013 16:41:40 +0200 From: To: Tomek Mrugalski Date: Wed, 21 Aug 2013 16:41:39 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6eebcGVQi3urIrRBu+CosjAtFFEQAAThgA Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8B472@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214CCDC.3090308@gmail.com> In-Reply-To: <5214CCDC.3090308@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.21.133617 Cc: dhcwg Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:41:54 -0000 Hi Tomek, Yes, you are right. Forget about my proposal to change the intended status. Cheers, Med >-----Message d'origine----- >De=A0: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >Envoy=E9=A0: mercredi 21 ao=FBt 2013 16:21 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: dhcwg >Objet=A0: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6- >prefix-pool-opt? > >On 21.08.2013 14:41, mohamed.boucadair@orange.com wrote: >> Hi Tomek, >> >> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >> useful feature in order to have more automation and also control >> routes aggregation instead of relying on proprietary behaviors of >> each implementation. Of course, part of these objectives can be >> achieved if routes are installed manually or use an out of band >> mechanism to enforce routing aggregation policies. Still, the >> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because >> the DHCP server has the knowledge of the prefix assignments; and >> therefore routes can be triggered with dhcpv6 . >> >> A way to progress with this document is to target the Experimental >> track. Based on the experience that will be gained in real >> deployments, the status can be revisited if required. >No, sorry. That won't work. At least not as you'd like it to. Take a >look at IANA registry for DHCPv6 options: >http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml. >It clearly states that assigning option codes require experts review >*and* standards action. Experimental drafts are not standards. You are >certainly welcome to proceed with this as experimental, but my >understanding of the process is that it would be published without >options assigned. And the draft (or experimental RFC) without option >code is really useless, because it is unlikely that any verndor would >implement it. > >As a side comment, currently assigning the option code for DHCPv6 >requires experts review. Let me cite the complete list: Ted Lemon. While >Ted Lemon is certainly a DHCPv6 expert, the standardization process >should not rely on a single person. If Ted becomes unavailable for >whatever reason (e.g. wins a lottery and decides to retire tomorrow on >his private island), we wouldn't get new DHCPv6 options any more. > >I suppose that is something that should be corrected one day, probably >together with the registry name. > >Tomek From Ted.Lemon@nominum.com Wed Aug 21 08:15:26 2013 Return-Path: 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 43BBF11E8233 for ; Wed, 21 Aug 2013 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VeUa3NfpjDz for ; Wed, 21 Aug 2013 08:15:19 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 925FE11E8112 for ; Wed, 21 Aug 2013 08:15:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUhTZh9kx+FRLA8Jn5FXWoDFk+QA1NLwU@postini.com; Wed, 21 Aug 2013 08:15:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3EFA41B82AA for ; Wed, 21 Aug 2013 08:15:19 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3821019006E; Wed, 21 Aug 2013 08:15:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 08:15:19 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnmvOZd/9qOMClEKacKJnLzUg1JmgOwAA Date: Wed, 21 Aug 2013 15:15:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525F905@mbx-01.win.nominum.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <27014E171AA7B64F8E3FFD953ED54A25@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:15:26 -0000 On Aug 21, 2013, at 5:41 AM, mohamed.boucadair@orange.com wrote: > A way to progress with this document is to target the Experimental track.= Based on the experience that will be gained in real deployments, the statu= s can be revisited if required. Only standards-track documents can get DHCP options codes. From Ted.Lemon@nominum.com Wed Aug 21 08:51:45 2013 Return-Path: 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 C438F11E8268 for ; Wed, 21 Aug 2013 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqWgU3E74y09 for ; Wed, 21 Aug 2013 08:51:39 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3B11E8255 for ; Wed, 21 Aug 2013 08:51:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUhTiCtwxANi9st5oVsqLUwjP4HMnIPXu@postini.com; Wed, 21 Aug 2013 08:51:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 671C51B827E for ; Wed, 21 Aug 2013 08:51:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4D06719006E; Wed, 21 Aug 2013 08:51:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 08:51:38 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnmvOZd/9qOMClEKacKJnLzUg1JmgG/6AgAApJwA= Date: Wed, 21 Aug 2013 15:51:38 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> In-Reply-To: <5214BF85.8020509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8408F4DD60ADE9449C0EEB26BDD4CACC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:51:45 -0000 On Aug 21, 2013, at 6:24 AM, Alexandru Petrescu wrote: > One point I think is essential is the installment of routes in the DHCP > Relay upon Prefix Assignment. >=20 > The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must > install a route in the DHCP Relay upon delegation. >=20 > This draft seems to at least assume it, and to describe much more about > it: how various parts of assigned prefixes are aggregated and communicate= d. I think that it might be helpful to have a document that simply describes t= he problem, and talks about what is currently being done to solve it, and t= hen suggests Leaf's solution as another possibility. This might actually = be more helpful than the solution document, because it would allow us to ta= lk about the problem without first agreeing on a solution. Would you be willing to work with Leaf on such a document? (I'm not promising that the working group will adopt it, of course=97just s= aying that I think it might be interesting.) From sarikaya2012@gmail.com Wed Aug 21 09:00:19 2013 Return-Path: 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 6345311E8223 for ; Wed, 21 Aug 2013 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AObbgoYQ-AAV for ; Wed, 21 Aug 2013 09:00:18 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD911E811A for ; Wed, 21 Aug 2013 09:00:17 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ec20so509898lab.28 for ; Wed, 21 Aug 2013 09:00:16 -0700 (PDT) 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=o2DkwIgSAQwtDyxDmMLKzY59XGqP3uRlus7ZjU7wTXc=; b=HMMo1FUrjGjaLE9C2mhGMqf7s8D39C+NXUNMcDvhWbmxg0cF1SPfePcxoHfh8M9253 WraMdrPVl4sbbQLdr48j+40YXS2bTTw28Oj+Wg41+geAoxs3DLcjoexgAZBkjPd95kNS ozl/HxL55KXfJ9M8apj6swTbkf1eoKM82SFJyIvWIYilD+cDHvkxjxUnS4bokyY/5NP/ do6PWK6q8iaXqSKpli/DkgyCgpGdP/vfut+ZO9rM415gJBOjvGA7gghIz3CCBiHtLigd ySNWwrfla9muPh9gFIgc7pi+rfnK0XzMSbDwR5Nm8MoXg+Wp0ymj+5WLIQV4IZ5k+ls9 j+lw== MIME-Version: 1.0 X-Received: by 10.152.37.103 with SMTP id x7mr6529398laj.28.1377100816716; Wed, 21 Aug 2013 09:00:16 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Wed, 21 Aug 2013 09:00:16 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> Date: Wed, 21 Aug 2013 11:00:16 -0500 Message-ID: From: Behcet Sarikaya To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0160b5e400192004e47745b3 Cc: "" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:00:19 -0000 --089e0160b5e400192004e47745b3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ted, Isn't it not good to use DHCP options to establish routes? Remember what happened to draft-ietf-mif-dhcpv6-route-option-05 in mif? I don't know if Leaf's document does it though. Regards, Behcet On Wed, Aug 21, 2013 at 10:51 AM, Ted Lemon wrote: > On Aug 21, 2013, at 6:24 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > > One point I think is essential is the installment of routes in the DHCP > > Relay upon Prefix Assignment. > > > > The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must > > install a route in the DHCP Relay upon delegation. > > > > This draft seems to at least assume it, and to describe much more about > > it: how various parts of assigned prefixes are aggregated and > communicated. > > I think that it might be helpful to have a document that simply describes > the problem, and talks about what is currently being done to solve it, an= d > then suggests Leaf's solution as another possibility. This might actual= ly > be more helpful than the solution document, because it would allow us to > talk about the problem without first agreeing on a solution. > > Would you be willing to work with Leaf on such a document? > > (I'm not promising that the working group will adopt it, of course=97just > saying that I think it might be interesting.) > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --089e0160b5e400192004e47745b3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ted,

Isn't it not = good to use DHCP options to establish routes? Remember what happened to
=
draft-ietf-mif-dhcpv6-route-option-05 in mif?
I don't know if Leaf's document does it though.

Regards,

Behcet

On Wed, Aug 21, 2013 at 10:51 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Aug 21, 2013, at 6:24 A= M, Alexandru Petrescu <a= lexandru.petrescu@gmail.com> wrote:
> One point I think is essential is the installment of routes in the DHC= P
> Relay upon Prefix Assignment.
>
> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP mus= t
> install a route in the DHCP Relay upon delegation.
>
> This draft seems to at least assume it, and to describe much more abou= t
> it: how various parts of assigned prefixes are aggregated and communic= ated.

I think that it might be helpful to have a document that simply descr= ibes the problem, and talks about what is currently being done to solve it,= and then suggests Leaf's solution as another possibility. =A0 This mig= ht actually be more helpful than the solution document, because it would al= low us to talk about the problem without first agreeing on a solution.

Would you be willing to work with Leaf on such a document?

(I'm not promising that the working group will adopt it, of course=97ju= st saying that I think it might be interesting.)

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--089e0160b5e400192004e47745b3-- From Ted.Lemon@nominum.com Wed Aug 21 09:28:54 2013 Return-Path: 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 0EB6511E8229 for ; Wed, 21 Aug 2013 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l23o-SqqdOjf for ; Wed, 21 Aug 2013 09:28:47 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0511E8110 for ; Wed, 21 Aug 2013 09:28:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUhTqvw15vHw2nUCU8lzEynqg+LPfzvP+@postini.com; Wed, 21 Aug 2013 09:28:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0862C1B82AB for ; Wed, 21 Aug 2013 09:28:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 022F819006E; Wed, 21 Aug 2013 09:28:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 09:28:47 -0700 From: Ted Lemon To: "" , Behcet Sarikaya Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnoeIs46aVPQ+eUigVLVDcoXDS5mgT00A Date: Wed, 21 Aug 2013 16:28:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:28:54 -0000 On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote= : > Isn't it not good to use DHCP options to establish routes? Remember what = happened to It's not possible to get IETF consensus on a DHCP option to deliver routes = to clients. I never said it was an inherently bad idea. The reason I as= ked MIF to stop working on it was that the endless floggings were getting i= n the way of doing real work. Really, preventing us from doing real work = at all. This is a completely different situation=97DHCP relay agents _already_ snoo= p DHCP messages to set up routing between PE and CPE devices. From alexandru.petrescu@gmail.com Thu Aug 22 01:18:06 2013 Return-Path: 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 BB2BB21F94FA for ; Thu, 22 Aug 2013 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.389 X-Spam-Level: X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By9FjvUtC5TJ for ; Thu, 22 Aug 2013 01:17:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C921F9473 for ; Thu, 22 Aug 2013 01:17:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7M8HcDB013756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Aug 2013 10:17:38 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7M8HbQ7029063 for ; Thu, 22 Aug 2013 10:17:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7M8HLoY009104 for ; Thu, 22 Aug 2013 10:17:37 +0200 Message-ID: <5215C910.1040600@gmail.com> Date: Thu, 22 Aug 2013 10:17:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 08:18:06 -0000 Le 21/08/2013 18:28, Ted Lemon a écrit : > On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya > wrote: >> Isn't it not good to use DHCP options to establish routes? >> Remember what happened to > > It's not possible to get IETF consensus on a DHCP option to deliver > routes to clients. I never said it was an inherently bad idea. The > reason I asked MIF to stop working on it was that the endless > floggings were getting in the way of doing real work. Really, > preventing us from doing real work at all. > > This is a completely different situation—DHCP relay agents _already_ > snoop DHCP messages to set up routing between PE and CPE devices. It is this kind of snooping I refer to, and maybe less the explicit indication from a server to install a particular route (which was controversial in MIF). This is a distinction which could be part of an document. Alex From leaf.yeh.sdo@gmail.com Thu Aug 22 03:55:31 2013 Return-Path: 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 DAD0F11E8101 for ; Thu, 22 Aug 2013 03:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IdRgFr6rV3A for ; Thu, 22 Aug 2013 03:55:29 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 616F811E80F4 for ; Thu, 22 Aug 2013 03:55:28 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so1364409pab.24 for ; Thu, 22 Aug 2013 03:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=GC8880tHWS8PUDXMXWD3OIzXVA1Dwa0krWJJnhpZL6c=; b=Gp5/8EFhcUpSxo4AJsA7Fe8+bGjcKiLq8FtruFmFxFT+V87yg/rpgxI8EkKb+P9lY1 7VHbLsInrkSmPoWw6EYyB8KPoYhqYEs8RrGyvDPdjXzjDOrGQZNNWMA2HkdeVLW2HuZZ ZRKuWrPiN4Iu7t0wt3U780YcKeMFoXd7ipAH6dMACyJp/TUh8V/XIJqWsRkzk0x7gFKu pjwb927v40uzkpTj8CDeegV1mNFfDTF65McL4voqGwhJ+KCdtqPLxAN8M7XSAfb/k8gT +3bezfoeV+w+YjQHkJCpXf4xP+ODF6nP8qFjPfYij93rk8Vk5oSpQdj6u16zjEnLAves t6oQ== X-Received: by 10.68.176.132 with SMTP id ci4mr12810456pbc.7.1377168928039; Thu, 22 Aug 2013 03:55:28 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id in2sm14123075pbc.37.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 03:55:27 -0700 (PDT) From: "Leaf Yeh" To: "'Ted Lemon'" , , "'Behcet Sarikaya'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> Date: Thu, 22 Aug 2013 18:55:21 +0800 Message-ID: <5215ee1f.a2c4440a.63af.10d6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOnoeIs46aVPQ+eUigVLVDcoXDS5mgT00A//+YC/A= Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 10:55:32 -0000 Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, August 22, 2013 12:29 AM To: ; Behcet Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: > Isn't it not good to use DHCP options to establish routes? Remember what happened to It's not possible to get IETF consensus on a DHCP option to deliver routes to clients. I never said it was an inherently bad idea. The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work. Really, preventing us from doing real work at all. This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From stenc@s-carlsen.dk Thu Aug 22 04:50:24 2013 Return-Path: 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 C69A021F9DF6 for ; Thu, 22 Aug 2013 04:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbruQW-dYUzA for ; Thu, 22 Aug 2013 04:50:24 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2AC21F9DFB for ; Thu, 22 Aug 2013 04:50:17 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 37B3B275B for ; Thu, 22 Aug 2013 13:50:14 +0200 (CEST) Message-ID: <5215FAF6.6060405@s-carlsen.dk> Date: Thu, 22 Aug 2013 13:50:14 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> In-Reply-To: <5215ee1f.a2c4440a.63af.10d6@mx.google.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------040907020604030109020209" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 11:50:24 -0000 This is a multi-part message in MIME format. --------------040907020604030109020209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available? Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network. On 22/08/13 12:55, Leaf Yeh wrote: > Ted - This is a completely different situation-DHCP relay agents _already_ > snoop DHCP messages to set up routing between PE and CPE devices. > > I remember Ted has a discussion with WG-RTGWG on this topic in its session > of IETF84, and we had an additional discussion on the ML of > Routing-Discussion. Per these discussion records before and the personal > feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that > 'use DHCPv6 to add & withdraw route on the PE router' will get rough > consensus (or will not irritate big controversy) in IETF. > > > Best Regards, > Leaf > > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Thursday, August 22, 2013 12:29 AM > To: ; Behcet Sarikaya > Cc: > Subject: Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: >> Isn't it not good to use DHCP options to establish routes? Remember what > happened to > > It's not possible to get IETF consensus on a DHCP option to deliver routes > to clients. I never said it was an inherently bad idea. The reason I > asked MIF to stop working on it was that the endless floggings were getting > in the way of doing real work. Really, preventing us from doing real work > at all. > > This is a completely different situation-DHCP relay agents _already_ snoop > DHCP messages to set up routing between PE and CPE devices. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------040907020604030109020209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available?

Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network.


On 22/08/13 12:55, Leaf Yeh wrote:
Ted - This is a completely different situation-DHCP relay agents _already_
snoop DHCP messages to set up routing between PE and CPE devices.

I remember Ted has a discussion with WG-RTGWG on this topic in its session
of IETF84, and we had an additional discussion on the ML of
Routing-Discussion. Per these discussion records before and the personal
feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that
'use DHCPv6 to add & withdraw route on the PE router' will get rough
consensus (or will not irritate big controversy) in IETF.


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Ted Lemon
Sent: Thursday, August 22, 2013 12:29 AM
To: <sarikaya@ieee.org>; Behcet Sarikaya
Cc: <dhcwg@ietf.org>
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

Isn't it not good to use DHCP options to establish routes? Remember what

happened to

It's not possible to get IETF consensus on a DHCP option to deliver routes
to clients.   I never said it was an inherently bad idea.   The reason I
asked MIF to stop working on it was that the endless floggings were getting
in the way of doing real work.   Really, preventing us from doing real work
at all.

This is a completely different situation-DHCP relay agents _already_ snoop
DHCP messages to set up routing between PE and CPE devices.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------040907020604030109020209-- From alexandru.petrescu@gmail.com Thu Aug 22 04:58:56 2013 Return-Path: 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 B663311E8161 for ; Thu, 22 Aug 2013 04:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZLAKgqGvXup for ; Thu, 22 Aug 2013 04:58:51 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5E29A11E8101 for ; Thu, 22 Aug 2013 04:58:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7MBwm6Q022515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Aug 2013 13:58:48 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7MBwmjg010491 for ; Thu, 22 Aug 2013 13:58:48 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7MBwVKq010579 for ; Thu, 22 Aug 2013 13:58:48 +0200 Message-ID: <5215FCE6.1000203@gmail.com> Date: Thu, 22 Aug 2013 13:58:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> In-Reply-To: <5215ee1f.a2c4440a.63af.10d6@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 11:58:56 -0000 Le 22/08/2013 12:55, Leaf Yeh a écrit : > Ted - This is a completely different situation-DHCP relay agents > _already_ snoop DHCP messages to set up routing between PE and CPE > devices. > > I remember Ted has a discussion with WG-RTGWG on this topic in its > session of IETF84, and we had an additional discussion on the ML of > Routing-Discussion. Per these discussion records before and the > personal feedback from Adrian (RTG-AD), my conclusion (or impression) > sounds that 'use DHCPv6 to add & withdraw route on the PE router' Well yes and no, depends how it is expressed. On one hand, the DHCP software on the Relay should insert a route whenever a Prefix is allocated by PD - otherwise later application-layer packets are not forwarded from that prefix through that Relay. Maybe the route entry should expire when the prefix lifetime expires. PD through a Relayed topology is useless otherwise. It would be as if an address were allocated with DHCP but the firewall blocked that address. On another hand, an explicit DHCP message to add routes (as seems to imply the wording 'use DHCPv6 to add route on the PE router') approaches more the meaning that may be controversial. Because that is the typical what routing protocols do, and in the particular case of default routes, it is the typical action of ND. Alex > will get rough consensus (or will not irritate big controversy) in > IETF. > > > Best Regards, Leaf > > > > -----Original Message----- From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: > Thursday, August 22, 2013 12:29 AM To: ; Behcet > Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested > in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya > wrote: >> Isn't it not good to use DHCP options to establish routes? Remember >> what > happened to > > It's not possible to get IETF consensus on a DHCP option to deliver > routes to clients. I never said it was an inherently bad idea. The > reason I asked MIF to stop working on it was that the endless > floggings were getting in the way of doing real work. Really, > preventing us from doing real work at all. > > This is a completely different situation-DHCP relay agents _already_ > snoop DHCP messages to set up routing between PE and CPE devices. > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > From alexandru.petrescu@gmail.com Thu Aug 22 05:00:40 2013 Return-Path: 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 7BECA11E8161 for ; Thu, 22 Aug 2013 05:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-8gvlz5cr9K for ; Thu, 22 Aug 2013 05:00:35 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3F49611E81A4 for ; Thu, 22 Aug 2013 05:00:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7MC0TYY011413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Aug 2013 14:00:29 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7MC0TEY011139 for ; Thu, 22 Aug 2013 14:00:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7MC0S4v011519 for ; Thu, 22 Aug 2013 14:00:29 +0200 Message-ID: <5215FD5C.1050102@gmail.com> Date: Thu, 22 Aug 2013 14:00:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> In-Reply-To: <5215FAF6.6060405@s-carlsen.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:00:40 -0000 Le 22/08/2013 13:50, Sten Carlsen a écrit : > I may easily be wrong here but snooping sounds to me like a stop gap > solution i.e. what you do when no better method is available? > > Seen from outside (my chair) it looks like there might be a need for a > protocol to talk directly with the switch/router, possibly first passing > a control/admin system that controls what may be set up in various > places in the network. Sounds as if a combination of DHCP and another protocol be needed whenever DHCP PD is deployed in a DHCP Relay topology. But something that describes the problem could indeed be written. Alex > > > On 22/08/13 12:55, Leaf Yeh wrote: >> Ted - This is a completely different situation-DHCP relay agents _already_ >> snoop DHCP messages to set up routing between PE and CPE devices. >> >> I remember Ted has a discussion with WG-RTGWG on this topic in its session >> of IETF84, and we had an additional discussion on the ML of >> Routing-Discussion. Per these discussion records before and the personal >> feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that >> 'use DHCPv6 to add & withdraw route on the PE router' will get rough >> consensus (or will not irritate big controversy) in IETF. >> >> >> Best Regards, >> Leaf >> >> >> >> -----Original Message----- >> From:dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: Thursday, August 22, 2013 12:29 AM >> To:; Behcet Sarikaya >> Cc: >> Subject: Re: [dhcwg] Anyone interested in continuing >> draft-ietf-dhc-dhcpv6-prefix-pool-opt? >> >> On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: >>> Isn't it not good to use DHCP options to establish routes? Remember what >> happened to >> >> It's not possible to get IETF consensus on a DHCP option to deliver routes >> to clients. I never said it was an inherently bad idea. The reason I >> asked MIF to stop working on it was that the endless floggings were getting >> in the way of doing real work. Really, preventing us from doing real work >> at all. >> >> This is a completely different situation-DHCP relay agents _already_ snoop >> DHCP messages to set up routing between PE and CPE devices. >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > > "MALE BOVINE MANURE!!!" > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From otroan@employees.org Thu Aug 22 05:14:47 2013 Return-Path: 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 D950411E8101 for ; Thu, 22 Aug 2013 05:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY-et3lFbIrJ for ; Thu, 22 Aug 2013 05:14:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 199D721F9EBE for ; Thu, 22 Aug 2013 05:14:41 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMFANv/FVKQ/khR/2dsb2JhbABagwU1gyW9M4EdFnSCJAEBBAF5EAtGVwYuh28GDK5ukGYHgxt7A5AWiH2QLYFkgT06 X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="asc'?scan'208";a="86048688" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 22 Aug 2013 12:14:40 +0000 Received: from dhcp-10-61-97-67.cisco.com (dhcp-10-61-97-67.cisco.com [10.61.97.67]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7MCEcav008702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 12:14:38 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_A41EEDF5-E2F7-4353-88C4-F81333929ED0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <5215FD5C.1050102@gmail.com> Date: Thu, 22 Aug 2013 14:14:37 +0200 Message-Id: References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <5215FD5C.1050102@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1508) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:14:48 -0000 --Apple-Mail=_A41EEDF5-E2F7-4353-88C4-F81333929ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 >> I may easily be wrong here but snooping sounds to me like a stop gap >> solution i.e. what you do when no better method is available? >>=20 >> Seen from outside (my chair) it looks like there might be a need for = a >> protocol to talk directly with the switch/router, possibly first = passing >> a control/admin system that controls what may be set up in various >> places in the network. >=20 > Sounds as if a combination of DHCP and another protocol be needed = whenever DHCP PD is deployed in a DHCP Relay topology. >=20 > But something that describes the problem could indeed be written. like: http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 ? cheers, Ole --Apple-Mail=_A41EEDF5-E2F7-4353-88C4-F81333929ED0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSFgCtAAoJEFuJXizso86g/7IIAKxexoulQ0ad9VBVJD33eVbf rV31t1VZJQHKXfTkczFe358yT1BiTr1NG1walaoOJNAjkHwbcO5qjKbCXudwCbnJ Og0t1nLJzQC+KxR4n3uc31sSt0TaNgQvcTolKfAyGq7wmQIBtobrxHopwiff9nMp fgp7S7bGh7AvE9gAW+KTrvDL41VXye/p2oenBW8kdnWYqS1UCoE33mgpEeG7Z4cx VGFG3fPkDt4I+wFFPke+1UyBuNcyYYerjTVRzI80rZslriQ62CMwbhw72YE4bTcT wERqbIHOEgFT2AI5Q81pc8bINbQgVUpOJuA9B7x2eXz3gd/6Y8GgWWEL4qPM9vU= =Edh3 -----END PGP SIGNATURE----- --Apple-Mail=_A41EEDF5-E2F7-4353-88C4-F81333929ED0-- From Jean-Francois.TremblayING@videotron.com Thu Aug 22 05:21:52 2013 Return-Path: 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 8EAB211E81B7 for ; Thu, 22 Aug 2013 05:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5mbtdihCtAH for ; Thu, 22 Aug 2013 05:21:43 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3211E81B2 for ; Thu, 22 Aug 2013 05:21:43 -0700 (PDT) In-Reply-To: <5215FAF6.6060405@s-carlsen.dk> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> To: dhcwg@ietf.org MIME-Version: 1.0 X-KeepSent: B53BECCC:BD12DB73-85257BCF:0042AABF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 March 08, 2012 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 22 Aug 2013 08:21:50 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP3|November 15, 2012) at 08/22/2013 08:21:42, Serialize complete at 08/22/2013 08:21:42 Content-Type: text/plain; charset="US-ASCII" Received-SPF: none Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:21:52 -0000 > De : Sten Carlsen > Seen from outside (my chair) it looks like there might be a need for > a protocol to talk directly with the switch/router, possibly first > passing a control/admin system that controls what may be set up in > various places in the network. Hum... a protocol that exchanges routes directly with a router? Over a TCP connection maybe? We could even group the route information in Updates and per Address Family? Add a few Capabilities over the top and call it Novative Excellent Way for Border Gateway Programming? Excuse the naive question, but isn't this BGP? I always get weird looks when I suggest we run BGP on DHCP servers, but it would actually fit the job description pretty well (at least for the purpose of route injection). /JF From stenc@s-carlsen.dk Thu Aug 22 05:33:09 2013 Return-Path: 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 351A421F8C20 for ; Thu, 22 Aug 2013 05:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwcyomRBc-f8 for ; Thu, 22 Aug 2013 05:33:08 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id F20BE21F9A50 for ; Thu, 22 Aug 2013 05:33:04 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 2B2DD2F6B for ; Thu, 22 Aug 2013 14:33:03 +0200 (CEST) Message-ID: <521604FF.5020409@s-carlsen.dk> Date: Thu, 22 Aug 2013 14:33:03 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <5215FD5C.1050102@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------010808070200010901060508" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:33:09 -0000 This is a multi-part message in MIME format. --------------010808070200010901060508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/08/13 14:14, Ole Troan wrote: >>> I may easily be wrong here but snooping sounds to me like a stop gap >>> solution i.e. what you do when no better method is available? >>> >>> Seen from outside (my chair) it looks like there might be a need for a >>> protocol to talk directly with the switch/router, possibly first passing >>> a control/admin system that controls what may be set up in various >>> places in the network. >> Sounds as if a combination of DHCP and another protocol be needed whenever DHCP PD is deployed in a DHCP Relay topology. >> >> But something that describes the problem could indeed be written. > like: > > http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 Something like this, though I may not agree to all the conclusions, maybe because I don't run a large network. One thing you do not mention here is the situation where one unit fails (maybe because of an axe from an angry user) and must be replaced. Mostly automatic reconfiguration seems a good thing in that situation. > > ? > > cheers, > Ole > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010808070200010901060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/08/13 14:14, Ole Troan wrote:
I may easily be wrong here but snooping sounds to me like a stop gap
solution i.e. what you do when no better method is available?

Seen from outside (my chair) it looks like there might be a need for a
protocol to talk directly with the switch/router, possibly first passing
a control/admin system that controls what may be set up in various
places in the network.

Sounds as if a combination of DHCP and another protocol be needed whenever DHCP PD is deployed in a DHCP Relay topology.

But something that describes the problem could indeed be written.

like:

http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
Something like this, though I may not agree to all the conclusions, maybe because I don't run a large network.

One thing you do not mention here is the situation where one unit fails (maybe because of an axe from an angry user) and must be replaced. Mostly automatic reconfiguration seems a good thing in that situation.

?

cheers,
Ole




_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------010808070200010901060508-- From stenc@s-carlsen.dk Thu Aug 22 05:35:16 2013 Return-Path: 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 4324A21F8BFD for ; Thu, 22 Aug 2013 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnS1dC5DaAVA for ; Thu, 22 Aug 2013 05:35:15 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4E021F9A50 for ; Thu, 22 Aug 2013 05:35:15 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 8EDE8224 for ; Thu, 22 Aug 2013 14:35:14 +0200 (CEST) Message-ID: <52160582.10303@s-carlsen.dk> Date: Thu, 22 Aug 2013 14:35:14 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060208070109090900000105" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:35:16 -0000 This is a multi-part message in MIME format. --------------060208070109090900000105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/08/13 14:21, Jean-Francois.TremblayING@videotron.com wrote: >> De : Sten Carlsen >> Seen from outside (my chair) it looks like there might be a need for >> a protocol to talk directly with the switch/router, possibly first >> passing a control/admin system that controls what may be set up in >> various places in the network. > Hum... a protocol that exchanges routes directly with a router? Over > a TCP connection maybe? We could even group the route information > in Updates and per Address Family? Add a few Capabilities over the > top and call it Novative Excellent Way for Border Gateway Programming? > > Excuse the naive question, but isn't this BGP? I always get weird > looks when I suggest we run BGP on DHCP servers, but it would > actually fit the job description pretty well (at least for the > purpose of route injection). I am not familiar enough with BGP to answer that question. The thought has occurred to me. > > /JF > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060208070109090900000105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/08/13 14:21, Jean-Francois.TremblayING@videotron.com wrote:
De : Sten Carlsen <stenc@s-carlsen.dk>
Seen from outside (my chair) it looks like there might be a need for
a protocol to talk directly with the switch/router, possibly first 
passing a control/admin system that controls what may be set up in 
various places in the network.

Hum... a protocol that exchanges routes directly with a router? Over
a TCP connection maybe? We could even group the route information 
in Updates and per Address Family?  Add a few Capabilities over the
top and call it Novative Excellent Way for Border Gateway Programming?

Excuse the naive question, but isn't this BGP? I always get weird 
looks when I suggest we run BGP on DHCP servers, but it would 
actually fit the job description pretty well (at least for the 
purpose of route injection).
I am not familiar enough with BGP to answer that question. The thought has occurred to me.

/JF


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------060208070109090900000105-- From rdroms.ietf@gmail.com Thu Aug 22 05:48:29 2013 Return-Path: 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 90F9F11E81BA for ; Thu, 22 Aug 2013 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcaAlHhpCmAt for ; Thu, 22 Aug 2013 05:48:27 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7CE11E81B2 for ; Thu, 22 Aug 2013 05:48:27 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id o19so274548qap.6 for ; Thu, 22 Aug 2013 05:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=754RmTJ2OjJ6M6gwxyxtbnzUOWOf29nJU7vYJT/KwpQ=; b=M23In7fFjWktzqowjA0GsZSG0IzZJTibAL7Zdfhvw3cx1KORZbYqumtabHatTtkBb2 K8XH+JpaaYsct92zbgZ85mEncUrmnPjJXx89eXU0uoghkqEShdwOnx13uQE5Dg5s/A4Q NA5Wdqyv6jEN+3kOxQLns6k5X/Xs6g45k9Ans/f4X6kbksw1/NkfP9HA3JqpcPfa6qAX QQmruut6uSbDeYGuBbB3DXIY9EdI6/Hc8rlk/Hry3csctdGGK9HO+9qkZdpLveKBHCpM 6gocHt/Ry/QeTLwjon8Covn5WkvKGS34nxHdJLnTteAO/GizrUn3+/hO8UMpxbWatjZm es2g== X-Received: by 10.49.121.37 with SMTP id lh5mr15118496qeb.40.1377175701288; Thu, 22 Aug 2013 05:48:21 -0700 (PDT) Received: from [10.86.253.72] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id q4sm17956042qah.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 05:48:19 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <5214BF85.8020509@gmail.com> Date: Thu, 22 Aug 2013 08:48:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:48:30 -0000 On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu = wrote: > Hi, >=20 > One point I think is essential is the installment of routes in the = DHCP > Relay upon Prefix Assignment. >=20 > The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP = must > install a route in the DHCP Relay upon delegation. >=20 > This draft seems to at least assume it, and to describe much more = about > it: how various parts of assigned prefixes are aggregated and = communicated. >=20 > I support it. After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have been aimed at the same problem. If I have that right, it might be = instructive to review the dhc WG mailing list discussion that lead to = the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. - Ralph >=20 > Alex >=20 > Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >> Hi Tomek, >>=20 >> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >> useful feature in order to have more automation and also control >> routes aggregation instead of relying on proprietary behaviors of >> each implementation. Of course, part of these objectives can be >> achieved if routes are installed manually or use an out of band >> mechanism to enforce routing aggregation policies. Still, the >> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >> because the DHCP server has the knowledge of the prefix assignments; >> and therefore routes can be triggered with dhcpv6 . >>=20 >> A way to progress with this document is to target the Experimental >> track. Based on the experience that will be gained in real >> deployments, the status can be revisited if required. >>=20 >> Cheers, Med >>=20 >>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] = Anyone >>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>=20 >>> During Berlin meeting chairs asked if there is still interest in >>> the prefix-pool-option. There was nobody interested in the work in >>> the room. The unanimous consensus in the room was to drop it. I >>> just wanted to confirm that on the list. >>>=20 >>> If you are interested in this work, want to support it and >>> participate in it, please let us know by replying to the mailing >>> list. Otherwise we'll drop this work and mark that draft as a dead >>> WG document. >>>=20 >>> Please respond within 2 weeks (until Sep. 2nd). >>>=20 >>> Bernie & Tomek _______________________________________________ >>> dhcwg mailing list dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Aug 22 06:12:32 2013 Return-Path: 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 766C211E81BD for ; Thu, 22 Aug 2013 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi7BkHuYZPTc for ; Thu, 22 Aug 2013 06:12:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 81BFC11E81BB for ; Thu, 22 Aug 2013 06:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4951; q=dns/txt; s=iport; t=1377177147; x=1378386747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bHVjCUU1VSTjD45lMc847QxPkBbXZoec69s7ly270cM=; b=Vx85bjJ5RxWqnHwXyLp9AdrKkNyJfUtcTGZENJQVGu96ta3du0W1UCWE hrvCDsJpeLYpD5i5H5Po6IYoNRdcOctuCiNx6Nto3GFr6dhwsKaV+Ml/N 3Es5EnW0KUIpGVA1Be34/Cz+ACORDHAgeFgLkPLkm1QFpPkMWL0H1eijY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAwNFlKtJXHB/2dsb2JhbABagwU1UcAHgR0WdIIkAQEBAwEBAQFpAgsFBwQCAQgOAwQBAQsdByEGCxQJCAIEAQ0FCId2AwkGDKxyDYF8BI1tgkgxBwaDFXsDiHaLF4FwjhqFKYFkgTuCKw X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250440515" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 22 Aug 2013 13:12:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7MDCPTP018282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 13:12:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 08:12:25 -0500 From: "Bernie Volz (volz)" To: Ralph Droms , Alexandru Petrescu Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnzXvaLHmSLwSfkSFfLi6OLbc0pmhMawA Date: Thu, 22 Aug 2013 13:12:24 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> In-Reply-To: <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:12:32 -0000 Ralph: Thanks for bringing up that old draft! There were issues here that caused t= his work to be abandoned. And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I think = one difference in the prefix-pool is that this is more to handle the case w= here the relay (router) is told to inject X/48 into the routing instead of = Y/64 or Y/60 that might be going to the client. (This it to avoid having to= inject lots of /64 or /60 routes when many clients are 'connected via the = router'.) Agentop could have been used to do that, but I'm not sure that was explicit= ly discussed or covered (and I didn't check the draft). I did like agentop better than this proposal in one respect - and that is i= ts use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible= idea (IMHO) since there is nothing to guarantee communication on which to = piggyback the request to remove the pool. A lifetime covers that as it caus= es the entry to expire on its own. And, 0 lifetimes can be used to remove '= now'. But that's more of a minor issue as to whether the entire work is app= ropriate. Cable CMTS devices have been snooping address and PD assignments for a long= time now and rather successfully. I suspect that the 'prefix pool' issue t= here is handled by static configuration on the CMTS. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= alph Droms Sent: Thursday, August 22, 2013 8:48 AM To: Alexandru Petrescu Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-= prefix-pool-opt? On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu wrote: > Hi, >=20 > One point I think is essential is the installment of routes in the=20 > DHCP Relay upon Prefix Assignment. >=20 > The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 > must install a route in the DHCP Relay upon delegation. >=20 > This draft seems to at least assume it, and to describe much more=20 > about > it: how various parts of assigned prefixes are aggregated and communicate= d. >=20 > I support it. After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have b= een aimed at the same problem. If I have that right, it might be instructi= ve to review the dhc WG mailing list discussion that lead to the abandonmen= t of draft-ietf-dhc-dhcpv6-agentopt-delegate. - Ralph >=20 > Alex >=20 > Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >> Hi Tomek, >>=20 >> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20 >> useful feature in order to have more automation and also control=20 >> routes aggregation instead of relying on proprietary behaviors of=20 >> each implementation. Of course, part of these objectives can be=20 >> achieved if routes are installed manually or use an out of band=20 >> mechanism to enforce routing aggregation policies. Still, the=20 >> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because=20 >> the DHCP server has the knowledge of the prefix assignments; and=20 >> therefore routes can be triggered with dhcpv6 . >>=20 >> A way to progress with this document is to target the Experimental=20 >> track. Based on the experience that will be gained in real=20 >> deployments, the status can be revisited if required. >>=20 >> Cheers, Med >>=20 >>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski Envoy=E9= =20 >>> : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone=20 >>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>=20 >>> During Berlin meeting chairs asked if there is still interest in the=20 >>> prefix-pool-option. There was nobody interested in the work in the=20 >>> room. The unanimous consensus in the room was to drop it. I just=20 >>> wanted to confirm that on the list. >>>=20 >>> If you are interested in this work, want to support it and=20 >>> participate in it, please let us know by replying to the mailing=20 >>> list. Otherwise we'll drop this work and mark that draft as a dead=20 >>> WG document. >>>=20 >>> Please respond within 2 weeks (until Sep. 2nd). >>>=20 >>> Bernie & Tomek _______________________________________________ >>> dhcwg mailing list dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list=20 >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Aug 22 06:17:16 2013 Return-Path: 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 7E7B611E81C1 for ; Thu, 22 Aug 2013 06:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKnhRREQXZVF for ; Thu, 22 Aug 2013 06:17:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D71A211E81BD for ; Thu, 22 Aug 2013 06:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3817; q=dns/txt; s=iport; t=1377177431; x=1378387031; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=P9iiy3HRJ+XRO6pMtln2IutMyDYkNVMxKiBrk82LmNM=; b=Z3GvcgK6HcDTkybODmGQvRsNF5QCM/hwQTnJYHPgpO7EiqyPTdNXqKEZ QNEXSw5hqhKw34TPWmYrtpGifMqwjjET+zUjZONkPLUgX4STPLET+ZkZH QbBjiZZoSfvPz5YVOwv9tK4v3c8/PK5lPBaecrXakUKLZlajC0u38z5uK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAPUNFlKtJXG8/2dsb2JhbABagwWBBsAHgR0WbQeCJAEBAQMBOkQHBgEIEQQBAQEKFAkoERQJCQEEEwiHdgMJBpU3l00NggCNbYFAgQg+gxV7A5V9jhqFKYFkgTuBcjk X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250530003" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 22 Aug 2013 13:17:09 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7MDH9gU016032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Aug 2013 13:17:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 08:17:09 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? Thread-Index: Ac6fOXCEVUTW9wmZRxmt5QC2WzMJUg== Date: Thu, 22 Aug 2013 13:17:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186A6664@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:17:16 -0000 Unless we receive some additional comments from the WG, we will be forced t= o conclude that there is NO support for advancing these documents to Intern= et Standard. Because of the time of year (perhaps the last of summer vacations), we will= wait until September 9th to make a final decision. But at the current rate= of response, it does not look favorable. - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 Sent: Monday, August 19, 2013 2:52 PM To: dhcwg@ietf.org Cc: Bernie Volz (volz) Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard On 12.08.2013 21:21, Bernie Volz (volz) wrote: > During the Berlin IETF-87 DHC WG session, it was suggested that we=20 > initiate a standards action request to move RFC 3315 (and RFC 3633),=20 > which are presently Proposed Standards, to Internet Standard. While we=20 > plan to work on a 3315bis which would merge the work, it was pointed=20 > out by several people (include our Area Director) that there is=20 > technically no need to wait for that to advance the standards. >=20 > The requirements for advancement are outlined in RFC 2026 and RFC 6410=20 > (which removed Draft Standard). >=20 > Per RFC 6410: >=20 > The criteria are: >=20 > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. There are many more than just two. > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. There are known issues, e.g. those described in draft-ietf-dhc-dhcpv6-state= ful-issues, but these are more of annoyance, rather than interoperability b= reaking problems. New implementations are interoperating with existing ones= without problems. > (3) There are no unused features in the specification that greatly > increase implementation complexity. That's an interesting question. Are there any implementations that implemen= t the whole RFC3315? I mean really everything: reconfiguration, reconfigure= -key, delayed auth, replay detection, sending CONFIRM when link state chang= es, sending DECLINE if DAD fails, rapid-commit, supporting 32 relays, all 3= duid types etc.? That's a trick question. I have my own answer for it, but I'd like to hear = WG opinion on that matter. > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. There are no IPRs claimed against RFC3315 and RFC3633. Ok, so in my opinion all criteria are met. > Please provide input as to whether you support making this request of=20 > the IETF/IESG (via the Internet Area Directors) or whether you feel=20 > there are issues (based on the above criteria). If you feel one=20 > document is ready but the other isn't, please let us know about that too. I feel that we should move forward with this for both 3315 and 3633. There's almost 7000 RFCs published, but there are only 96 that have Interne= t Standard status. I strongly believe that DHCPv6 is one of core Internet p= rotocols. This status change would reflect that. With my chair on, I'm disappointed that nobody responded to this mail so fa= r. Chairs got couple comments off the list, but nobody said anything on the= list. I don't know, perhaps people are not that much interested, because t= his move does not have any immediate practical repercussions. Or perhaps it is a middle of vacation time... Come on, guys. Saying +1 doesn't take much time. ;-) Tomek From leaf.yeh.sdo@gmail.com Thu Aug 22 06:22:51 2013 Return-Path: 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 592F021F9B97 for ; Thu, 22 Aug 2013 06:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLtidDhXZyA7 for ; Thu, 22 Aug 2013 06:22:45 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A103021F9017 for ; Thu, 22 Aug 2013 06:22:45 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so1895304pdj.1 for ; Thu, 22 Aug 2013 06:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=U1t2b4H7i4uFhgJR8zM78UQ2PYjaZseb8cWqgW3AaWQ=; b=C3AmjHBDQoxE43oJh6T/fB2mPs9E5se8tyapTG7VWQ4SIu0p2BFPldB6XSF0OGfC0I b1rHpToTS4S9NhTx4igTBqMgXKqjWh8vurUsFioO/PQqrTdVsVELoOyMtSiSnf8zoqc2 jei6A+0j1AXo+8YA+mFhZyG7Erj+5VnJlqfS1ER2hC2GTMYnjq/W8JSbFLOGDMGtBe8w 3j81ByMRY6YTqX0vHi4czg/TreFOR8r7rydTH6tS+W7Z8SPm7arbOUPCDVrYRVhmHAmu XqqP24Uv/sG6ngWykXfAisl6NgniIDKTgsqXrQ9BwHluLDNO9zLt1zhBEwk/tYZ9wu0S j67g== X-Received: by 10.68.90.3 with SMTP id bs3mr5394636pbb.169.1377177765246; Thu, 22 Aug 2013 06:22:45 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id fk4sm16768611pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 06:22:44 -0700 (PDT) From: "Leaf Yeh" To: "'Sten Carlsen'" , References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> In-Reply-To: <5215FAF6.6060405@s-carlsen.dk> Date: Thu, 22 Aug 2013 21:22:38 +0800 Message-ID: <521610a4.0466420a.469b.ffff9582@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6fLc16ZvW6jHPiTlyPCKt/DeDoegAAeGXg Content-Language: zh-cn Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:22:51 -0000 Sten - ... snooping sounds to me like a stop gap solution . Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact. Best Regards, Leaf ---------------------------------------------------------------------------- ------------------------------------------------------ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen Sent: Thursday, August 22, 2013 7:50 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available? Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network. On 22/08/13 12:55, Leaf Yeh wrote: Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, August 22, 2013 12:29 AM To: ; Behcet Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: Isn't it not good to use DHCP options to establish routes? Remember what happened to It's not possible to get IETF consensus on a DHCP option to deliver routes to clients. I never said it was an inherently bad idea. The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work. Really, preventing us from doing real work at all. This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" From volz@cisco.com Thu Aug 22 06:33:17 2013 Return-Path: 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 C009921F8793 for ; Thu, 22 Aug 2013 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFrxUn2JekPW for ; Thu, 22 Aug 2013 06:33:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1E321F9DD0 for ; Thu, 22 Aug 2013 06:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3856; q=dns/txt; s=iport; t=1377178386; x=1378387986; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WBn2uOndugXMBoNO4c223l6aHWW8NOpUxWu6Gw+XNmA=; b=lN2WJs7e3ognM3bAxYy41UEBagc5/jnfkPNAhQgtdnTysQOgmf6FF7cF Y588bo6GTmA+5+liSDHyrFSOpHJ3ZxqWTsf6goFicVgyNNnsmVsszAndV DudnKGdA4So8vtjcNDVsvbXlwBU3NX3ygxT02sVqyD951KmTKCNbrloU0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FADESFlKtJXG//2dsb2JhbABagwU1UcAIgR0WdIIkAQEBBAEBATc0FwQCAQgRBAEBCxQJByEGCxQJCAEBBAESCBOHYwMPDKx5DYF8BI1tgkg4BoMVewOVfY4ahSmBZIE7gis X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250440053" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 22 Aug 2013 13:33:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7MDX5Et024725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 13:33:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 08:33:05 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh , "'Sten Carlsen'" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fLc16ZvW6jHPiTlyPCKt/DeDoegAAeGXgAAMGN8A= Date: Thu, 22 Aug 2013 13:33:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <521610a4.0466420a.469b.ffff9582@mx.google.com> In-Reply-To: <521610a4.0466420a.469b.ffff9582@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:33:18 -0000 Leaf ... the relay technically isn't snooping. It is relaying (it has to pr= ocess these messages -- they are not just going through the relay). The sno= oping part is that it is looking inside the client part of the message. Thi= s was what agentopt was trying to avoid (and also trying to permit slightly= different information going to the relay -- not just what went to the clie= nt). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Thursday, August 22, 2013 9:23 AM To: 'Sten Carlsen'; dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-= prefix-pool-opt? Sten - ... snooping sounds to me like a stop gap solution . Per my understanding about the implementation (or behavior) of the PE route= r of today, it (or it's CPU) snoops & handles every protocol message in the= control (and management) plane in fact. Best Regards, Leaf ---------------------------------------------------------------------------= - ------------------------------------------------------ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= ten Carlsen Sent: Thursday, August 22, 2013 7:50 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-= prefix-pool-opt? I may easily be wrong here but snooping sounds to me like a stop gap soluti= on i.e. what you do when no better method is available? Seen from outside (my chair) it looks like there might be a need for a prot= ocol to talk directly with the switch/router, possibly first passing a cont= rol/admin system that controls what may be set up in various places in the = network. On 22/08/13 12:55, Leaf Yeh wrote: Ted - This is a completely different situation-DHCP relay agents _already_ = snoop DHCP messages to set up routing between PE and CPE devices. I remember Ted has a discussion with WG-RTGWG on this topic in its session = of IETF84, and we had an additional discussion on the ML of Routing-Discuss= ion. Per these discussion records before and the personal feedback from Adr= ian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add = & withdraw route on the PE router' will get rough consensus (or will not ir= ritate big controversy) in IETF. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 22, 2013 12:29 AM To: ; Behcet Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-= prefix-pool-opt? On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote= : Isn't it not good to use DHCP options to establish routes? Remember what ha= ppened to It's not possible to get IETF consensus on a DHCP option to deliver routes to clients. I never said it was an inherently bad idea. The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work. Really, preventing us from doing real work at all. This is a completely different situation-DHCP relay agents _already_ snoop = DHCP messages to set up routing between PE and CPE devices. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!"=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From otroan@employees.org Thu Aug 22 06:39:36 2013 Return-Path: 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 6934E21F9E9C for ; Thu, 22 Aug 2013 06:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrTRisKdCrRd for ; Thu, 22 Aug 2013 06:39:35 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F78521F9DF6 for ; Thu, 22 Aug 2013 06:39:35 -0700 (PDT) Received: from dhcp-10-61-97-87.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7193B5ED9; Thu, 22 Aug 2013 06:39:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_366B64F0-1389-40E2-BBE6-57E473DF8B58"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6664@xmb-rcd-x04.cisco.com> Date: Thu, 22 Aug 2013 15:39:29 +0200 Message-Id: References: <489D13FBFA9B3E41812EA89F188F018E186A6664@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:39:36 -0000 --Apple-Mail=_366B64F0-1389-40E2-BBE6-57E473DF8B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Unless we receive some additional comments from the WG, we will be = forced to conclude that there is NO support for advancing these = documents to Internet Standard. >=20 > Because of the time of year (perhaps the last of summer vacations), we = will wait until September 9th to make a final decision. But at the = current rate of response, it does not look favorable. I do not support advancing RFC3315/RFC3633 to Internet Standard. reason being that I believe that there are errata that will lead to = interoperability problems. cheers, Ole > -----Original Message----- > From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 > Sent: Monday, August 19, 2013 2:52 PM > To: dhcwg@ietf.org > Cc: Bernie Volz (volz) > Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet = Standard >=20 > On 12.08.2013 21:21, Bernie Volz (volz) wrote: >> During the Berlin IETF-87 DHC WG session, it was suggested that we=20 >> initiate a standards action request to move RFC 3315 (and RFC 3633),=20= >> which are presently Proposed Standards, to Internet Standard. While = we=20 >> plan to work on a 3315bis which would merge the work, it was pointed=20= >> out by several people (include our Area Director) that there is=20 >> technically no need to wait for that to advance the standards. >>=20 >> The requirements for advancement are outlined in RFC 2026 and RFC = 6410=20 >> (which removed Draft Standard). >>=20 >> Per RFC 6410: >>=20 >> The criteria are: >>=20 >> (1) There are at least two independent interoperating = implementations >> with widespread deployment and successful operational = experience. > There are many more than just two. >=20 >> (2) There are no errata against the specification that would cause = a >> new implementation to fail to interoperate with deployed ones. > There are known issues, e.g. those described in = draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of annoyance, = rather than interoperability breaking problems. New implementations are = interoperating with existing ones without problems. >=20 >> (3) There are no unused features in the specification that greatly >> increase implementation complexity. > That's an interesting question. Are there any implementations that = implement the whole RFC3315? I mean really everything: reconfiguration, = reconfigure-key, delayed auth, replay detection, sending CONFIRM when = link state changes, sending DECLINE if DAD fails, rapid-commit, = supporting 32 relays, all 3 duid types etc.? >=20 > That's a trick question. I have my own answer for it, but I'd like to = hear WG opinion on that matter. >=20 >> (4) If the technology required to implement the specification >> requires patented or otherwise controlled technology, then the >> set of implementations must demonstrate at least two = independent, >> separate and successful uses of the licensing process. > There are no IPRs claimed against RFC3315 and RFC3633. >=20 > Ok, so in my opinion all criteria are met. >=20 >> Please provide input as to whether you support making this request of=20= >> the IETF/IESG (via the Internet Area Directors) or whether you feel=20= >> there are issues (based on the above criteria). If you feel one=20 >> document is ready but the other isn't, please let us know about that = too. > I feel that we should move forward with this for both 3315 and 3633. > There's almost 7000 RFCs published, but there are only 96 that have = Internet Standard status. I strongly believe that DHCPv6 is one of core = Internet protocols. This status change would reflect that. >=20 > With my chair on, I'm disappointed that nobody responded to this mail = so far. Chairs got couple comments off the list, but nobody said = anything on the list. I don't know, perhaps people are not that much = interested, because this move does not have any immediate practical = repercussions. > Or perhaps it is a middle of vacation time... >=20 > Come on, guys. Saying +1 doesn't take much time. ;-) >=20 > Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_366B64F0-1389-40E2-BBE6-57E473DF8B58 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSFhSSAAoJEFuJXizso86gsJsIAJ5O35MO6vly2RFCGRyN2NbG XEhvnhecWD3JkFZ4lrbBKh5EQvF+ywW5Nt6Xs5WPZaX+FF3SYfBnE6Wm8jw/CWCD BjbUGCncKmbF/qe5B7514faFC+N8BHCzuMPa2DSiQlA3w5CgV8SjCXq3ztUDTplV CIaJgRUNJRg+FBGHm9+T0WggcOzRoagmfHXOtbg+le7VUNTsel0nLUbNwxPDNBK1 R3IMzdrSKms7ReQvaOmVJX6I0Yat+qZybKpMksV9Sk2yx4Mf/SYZcXh7JGZbc0jw v5NZPbEDbrcpZtzUUBOC16S3jpTQhFhrfayBLSVynjKosui4rmXlAgGhL9E960c= =A9oW -----END PGP SIGNATURE----- --Apple-Mail=_366B64F0-1389-40E2-BBE6-57E473DF8B58-- From mohamed.boucadair@orange.com Thu Aug 22 06:46:04 2013 Return-Path: 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 1AD3411E80E2 for ; Thu, 22 Aug 2013 06:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxj2NjvsegO3 for ; Thu, 22 Aug 2013 06:46:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 86EF011E81C4 for ; Thu, 22 Aug 2013 06:45:52 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CD6C12648BE; Thu, 22 Aug 2013 15:45:50 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8993A35C055; Thu, 22 Aug 2013 15:45:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 22 Aug 2013 15:45:50 +0200 From: To: Ralph Droms , Alexandru Petrescu Date: Thu, 22 Aug 2013 15:45:48 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fNepkjUkQXIB/TcOJh7OHqIFhAwABteGQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> In-Reply-To: <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.63617 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:46:04 -0000 Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.=20 draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Ralph Droms >Envoy=E9=A0: jeudi 22 ao=FBt 2013 14:48 >=C0=A0: Alexandru Petrescu >Cc=A0: dhcwg@ietf.org WG >Objet=A0: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyo= ne >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From stenc@s-carlsen.dk Thu Aug 22 07:12:36 2013 Return-Path: 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 7747C21F8C3E for ; Thu, 22 Aug 2013 07:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU3YBWVEPXsd for ; Thu, 22 Aug 2013 07:12:35 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 221A821F8266 for ; Thu, 22 Aug 2013 07:12:35 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7B5D2275B; Thu, 22 Aug 2013 16:12:32 +0200 (CEST) Message-ID: <52161C50.1010407@s-carlsen.dk> Date: Thu, 22 Aug 2013 16:12:32 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <521610a4.0466420a.469b.ffff9582@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------040908030201090201010504" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:12:36 -0000 This is a multi-part message in MIME format. --------------040908030201090201010504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Also my understanding, "snooping" is normally used to describe that you look into/listen to things that are not really meant for you. My point was that giving information meant for consumption at that point could provide better information than deducting what you need from information that does not really contain what you may need. On 22/08/13 15:33, Bernie Volz (volz) wrote: > Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client). > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh > Sent: Thursday, August 22, 2013 9:23 AM > To: 'Sten Carlsen'; dhcwg@ietf.org > Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Sten - ... snooping sounds to me like a stop gap solution . > > Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact. > > > Best Regards, > Leaf > > > > ---------------------------------------------------------------------------- > ------------------------------------------------------ > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen > Sent: Thursday, August 22, 2013 7:50 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available? > > Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network. > > On 22/08/13 12:55, Leaf Yeh wrote: > Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. > > I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF. > > > Best Regards, > Leaf > > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Thursday, August 22, 2013 12:29 AM > To: ; Behcet Sarikaya > Cc: > Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: > Isn't it not good to use DHCP options to establish routes? Remember what happened to > > It's not possible to get IETF consensus on a DHCP option to deliver routes > to clients. I never said it was an inherently bad idea. The reason I > asked MIF to stop working on it was that the endless floggings were getting > in the way of doing real work. Really, preventing us from doing real work > at all. > > This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > > "MALE BOVINE MANURE!!!" > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------040908030201090201010504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Also my understanding, "snooping" is normally used to describe that you look into/listen to things that are not really meant for you.

My point was that giving information meant for consumption at that point could provide better information than deducting what you need from information that does not really contain what you may need.


On 22/08/13 15:33, Bernie Volz (volz) wrote:
Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client).

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh
Sent: Thursday, August 22, 2013 9:23 AM
To: 'Sten Carlsen'; dhcwg@ietf.org
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Sten - ... snooping sounds to me like a stop gap solution .

Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact.


Best Regards,
Leaf



----------------------------------------------------------------------------
------------------------------------------------------
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen
Sent: Thursday, August 22, 2013 7:50 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available?

Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network.

On 22/08/13 12:55, Leaf Yeh wrote:
Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.

I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF.


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, August 22, 2013 12:29 AM
To: <sarikaya@ieee.org>; Behcet Sarikaya
Cc: <dhcwg@ietf.org>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
Isn't it not good to use DHCP options to establish routes? Remember what happened to

It's not possible to get IETF consensus on a DHCP option to deliver routes
to clients.   I never said it was an inherently bad idea.   The reason I
asked MIF to stop working on it was that the endless floggings were getting
in the way of doing real work.   Really, preventing us from doing real work
at all.

This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


--
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------040908030201090201010504-- From jason.weil@twcable.com Thu Aug 22 07:35:09 2013 Return-Path: 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 12FF411E8170 for ; Thu, 22 Aug 2013 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.537 X-Spam-Level: * X-Spam-Status: No, score=1.537 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoI38Cg9rvND for ; Thu, 22 Aug 2013 07:35:03 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 55A5511E81DC for ; Thu, 22 Aug 2013 07:35:03 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,934,1367985600"; d="scan'208";a="125250412" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Aug 2013 10:34:36 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 22 Aug 2013 10:35:02 -0400 From: "Weil, Jason" To: Ole Troan , Bernie Volz Date: Thu, 22 Aug 2013 10:35:01 -0400 Thread-Topic: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? Thread-Index: Ac6fRMljYlOtFpekQheJzf46n32Qng== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:35:09 -0000 I am also not seeing the benefit of pushing two RFCs that are in the process of being merged to something better than the sum of their parts before that merge is successful. And like Ole mentioned wouldn't it fail on the errata point (2) from Tomek's original email anyway? Jason On 8/22/13 9:39 AM, "Ole Troan" wrote: >> Unless we receive some additional comments from the WG, we will be >>forced to conclude that there is NO support for advancing these >>documents to Internet Standard. >> >> Because of the time of year (perhaps the last of summer vacations), we >>will wait until September 9th to make a final decision. But at the >>current rate of response, it does not look favorable. > >I do not support advancing RFC3315/RFC3633 to Internet Standard. >reason being that I believe that there are errata that will lead to >interoperability problems. > >cheers, >Ole > >> -----Original Message----- >> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >> Sent: Monday, August 19, 2013 2:52 PM >> To: dhcwg@ietf.org >> Cc: Bernie Volz (volz) >> Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet >>Standard >> >> On 12.08.2013 21:21, Bernie Volz (volz) wrote: >>> During the Berlin IETF-87 DHC WG session, it was suggested that we >>> initiate a standards action request to move RFC 3315 (and RFC 3633), >>> which are presently Proposed Standards, to Internet Standard. While we >>> plan to work on a 3315bis which would merge the work, it was pointed >>> out by several people (include our Area Director) that there is >>> technically no need to wait for that to advance the standards. >>> >>> The requirements for advancement are outlined in RFC 2026 and RFC 6410 >>> (which removed Draft Standard). >>> >>> Per RFC 6410: >>> >>> The criteria are: >>> >>> (1) There are at least two independent interoperating implementations >>> with widespread deployment and successful operational experience. >> There are many more than just two. >> >>> (2) There are no errata against the specification that would cause a >>> new implementation to fail to interoperate with deployed ones. >> There are known issues, e.g. those described in >>draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of annoyance, >>rather than interoperability breaking problems. New implementations are >>interoperating with existing ones without problems. >> >>> (3) There are no unused features in the specification that greatly >>> increase implementation complexity. >> That's an interesting question. Are there any implementations that >>implement the whole RFC3315? I mean really everything: reconfiguration, >>reconfigure-key, delayed auth, replay detection, sending CONFIRM when >>link state changes, sending DECLINE if DAD fails, rapid-commit, >>supporting 32 relays, all 3 duid types etc.? >> >> That's a trick question. I have my own answer for it, but I'd like to >>hear WG opinion on that matter. >> >>> (4) If the technology required to implement the specification >>> requires patented or otherwise controlled technology, then the >>> set of implementations must demonstrate at least two independent, >>> separate and successful uses of the licensing process. >> There are no IPRs claimed against RFC3315 and RFC3633. >> >> Ok, so in my opinion all criteria are met. >> >>> Please provide input as to whether you support making this request of >>> the IETF/IESG (via the Internet Area Directors) or whether you feel >>> there are issues (based on the above criteria). If you feel one >>> document is ready but the other isn't, please let us know about that >>>too. >> I feel that we should move forward with this for both 3315 and 3633. >> There's almost 7000 RFCs published, but there are only 96 that have >>Internet Standard status. I strongly believe that DHCPv6 is one of core >>Internet protocols. This status change would reflect that. >> >> With my chair on, I'm disappointed that nobody responded to this mail >>so far. Chairs got couple comments off the list, but nobody said >>anything on the list. I don't know, perhaps people are not that much >>interested, because this move does not have any immediate practical >>repercussions. >> Or perhaps it is a middle of vacation time... >> >> Come on, guys. Saying +1 doesn't take much time. ;-) >> >> Tomek >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From leaf.yeh.sdo@gmail.com Thu Aug 22 08:47:49 2013 Return-Path: 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 3AF5521F95A6 for ; Thu, 22 Aug 2013 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuX2lInh3tOv for ; Thu, 22 Aug 2013 08:47:48 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8E521F9477 for ; Thu, 22 Aug 2013 08:47:48 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so1964804pbb.27 for ; Thu, 22 Aug 2013 08:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=BRpTXAndG+fy2RekNaCE/4H2HEPHKKRin/15F8lNrzo=; b=bUqy2Qw5LD1IhmbI33gpU/WLzKy10aphY3J4pR+kIMMOet+2AzzZZTSdJ0Ky0/gNN6 vE6ieck9C5JAAQvJMm+xx+bhtkhb/qtujT9yD+gc0sp4YkZ7JUd8MGWdsZKVlETKGSxd TM0ZawyVUDOIrEviNiZbaFQCQBoa1djkh2wrm4yvxIB0Fpk582FL8jx1KKZVta0bFuI9 hN3URY0GAPv8ZBrQxx/kM7WW1g+AwNWGW4AzIQTaMRpmDXSYQGMBFmB9fp806NGF+fMB Lb0NFznjuwO7v8D0ni3CHsEcFS7vcp/XiAJaadPA92tFVlbBIdj7lOjvmoBKxjHWMvWi wvZw== X-Received: by 10.66.25.232 with SMTP id f8mr16186292pag.25.1377186468014; Thu, 22 Aug 2013 08:47:48 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id os4sm15642616pbb.25.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 08:47:47 -0700 (PDT) From: "Leaf Yeh" To: "'Sten Carlsen'" , "'Bernie Volz \(volz\)'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <521610a4.0466420a.469b.ffff9582@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> <52161C50.1010407@s-carlsen.dk> In-Reply-To: <52161C50.1010407@s-carlsen.dk> Date: Thu, 22 Aug 2013 23:47:40 +0800 Message-ID: <521632a3.4484440a.6478.5075@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6fQadewU/2eW0NS0Sb0MIC1ZX4IQADCOUg Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:47:49 -0000 Sten - ."snooping" is normally used to describe that you look into/listen to things that are not really meant for you. I regard your understanding (or definition) is right. Sten - . giving information meant for consumption at that point could provide better information than deducting what you need from information that does not really contain what you may need. OPTION_PREFIX_POOL defined in this draft is targeted to the information consumption point (or the relay agent @ PE router), which contains the information of prefix pool (maintained by the server) for the aggregation route. Best Regards, Leaf ---------------------------------------------------------------------- From: Sten Carlsen [mailto:stenc@s-carlsen.dk] Sent: Thursday, August 22, 2013 10:13 PM To: Bernie Volz (volz) Cc: Leaf Yeh; dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Also my understanding, "snooping" is normally used to describe that you look into/listen to things that are not really meant for you. My point was that giving information meant for consumption at that point could provide better information than deducting what you need from information that does not really contain what you may need. On 22/08/13 15:33, Bernie Volz (volz) wrote: Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Thursday, August 22, 2013 9:23 AM To: 'Sten Carlsen'; dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Sten - ... snooping sounds to me like a stop gap solution . Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact. Best Regards, Leaf ---------------------------------------------------------------------------- ------------------------------------------------------ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen Sent: Thursday, August 22, 2013 7:50 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available? Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network. On 22/08/13 12:55, Leaf Yeh wrote: Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, August 22, 2013 12:29 AM To: ; Behcet Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: Isn't it not good to use DHCP options to establish routes? Remember what happened to It's not possible to get IETF consensus on a DHCP option to deliver routes to clients. I never said it was an inherently bad idea. The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work. Really, preventing us from doing real work at all. This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" From leaf.yeh.sdo@gmail.com Thu Aug 22 08:47:52 2013 Return-Path: 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 73D9C21F994A for ; Thu, 22 Aug 2013 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAexmfpuEMV5 for ; Thu, 22 Aug 2013 08:47:51 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD121F9635 for ; Thu, 22 Aug 2013 08:47:51 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so2338589pab.21 for ; Thu, 22 Aug 2013 08:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=tASBBXz4HK4v2oIXr8t4C5ejwOnJFWUzWwRTqYtTwF4=; b=aT6ejp78cq+7a9m5GTPZxdLk/hEchC6MhqWRJh4MtGPsDgqcPSRrSwp3ivpOLgGSOr LBJOeLc2C99n+UlMR+4N2zYTNTooM66VB14iNIpUARwW/8pTaMqM50Un+0gPoTwauEAo aEJqJux7JngiN53P3FxetBxm4CHi4Zj6Nip/gvU9mfCHgZX1O3URy+Oe1ZaYeDUZXWxV MzQoOspkbrkP5aIf92UaAqO7V6skzl/BT96UFxNFPfFfXY8DdAx2mYTgZj8sndG1IXoE vanSz4YKcnHl0fmMUPKM0ZQYb81dTDaAgIXX0I02/ODQUKT84fBKzO6b1pChfKo/E3ar nMhA== X-Received: by 10.67.11.103 with SMTP id eh7mr6173293pad.153.1377186471420; Thu, 22 Aug 2013 08:47:51 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id os4sm15642616pbb.25.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 08:47:50 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , "'Sten Carlsen'" , References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <521610a4.0466420a.469b.ffff9582@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com> Date: Thu, 22 Aug 2013 23:47:40 +0800 Message-ID: <521632a6.4484440a.6478.5077@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6fLc16ZvW6jHPiTlyPCKt/DeDoegAAeGXgAAMGN8AABC+p4A== Content-Language: zh-cn Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:47:52 -0000 BV - ...the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. Right. BV - This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client). We use the word of 'snoop' in this thread is supposed for the PD prefixes (or CE's prefix) contained in OPTION_IA_PD. This draft (OPTION_PREFIX_POOL) has not employ the word of 'snoop' yet. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Thursday, August 22, 2013 9:33 PM To: Leaf Yeh; 'Sten Carlsen'; dhcwg@ietf.org Subject: RE: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Thursday, August 22, 2013 9:23 AM To: 'Sten Carlsen'; dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Sten - ... snooping sounds to me like a stop gap solution . Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact. Best Regards, Leaf ---------------------------------------------------------------------------- ------------------------------------------------------ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen Sent: Thursday, August 22, 2013 7:50 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available? Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network. On 22/08/13 12:55, Leaf Yeh wrote: Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, August 22, 2013 12:29 AM To: ; Behcet Sarikaya Cc: Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya wrote: Isn't it not good to use DHCP options to establish routes? Remember what happened to It's not possible to get IETF consensus on a DHCP option to deliver routes to clients. I never said it was an inherently bad idea. The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work. Really, preventing us from doing real work at all. This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Aug 22 09:07:41 2013 Return-Path: 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 48B3121F9C53 for ; Thu, 22 Aug 2013 09:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXAU-4RJhjL6 for ; Thu, 22 Aug 2013 09:07:34 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9126C21F99BD for ; Thu, 22 Aug 2013 09:07:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUhY3RhRFMVcEVYSVYzsVgh01m8mvaaFO@postini.com; Thu, 22 Aug 2013 09:07:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1B19F1B82BA for ; Thu, 22 Aug 2013 09:07:34 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C384E190071; Thu, 22 Aug 2013 09:07:32 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 09:07:26 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnxAt8+wFVtUaWk6Fo5RISSOBg5mh2psA Date: Thu, 22 Aug 2013 16:07:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775261BE8@mbx-01.win.nominum.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215C910.1040600@gmail.com> In-Reply-To: <5215C910.1040600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0DD008C3C537044E9D625427705FBD99@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:07:41 -0000 On Aug 22, 2013, at 1:17 AM, Alexandru Petrescu wrote: > It is this kind of snooping I refer to, and maybe less the explicit > indication from a server to install a particular route (which was > controversial in MIF). This is a distinction which could be part of an d= ocument. I don't understand the point you are making. There's no controversy about= PD affecting routing, other than that the routing guys would ideally prefe= r to use a routing protocol for it. But fate-sharing argues _for_ PD snoo= ping, not against it. So it's completely different than the discussion ab= out default routes being delivered to end nodes. From leaf.yeh.sdo@gmail.com Thu Aug 22 09:23:47 2013 Return-Path: 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 F3A9011E80ED for ; Thu, 22 Aug 2013 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl2cs8bMQHWi for ; Thu, 22 Aug 2013 09:23:45 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9F11E81C5 for ; Thu, 22 Aug 2013 09:23:44 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so2066113pdj.39 for ; Thu, 22 Aug 2013 09:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=lqes1rW1S50d/h3BtvSahKFuIepWR4R2+BUMAmez2aA=; b=Qj8v0ULk7ZlOX8bOPQ1gAdBHArmETKeu9WU0fksyV0X+szpqjN0z8uOLAb0kv52YNg wNiYsvbxwclYSNHsyy5wa8yRvv8ZPZHEUjOzbsrxZDn7XKKkEHX/q09eBm5WObKBmSRg 2MYKVELYPJ/RCnfcxRIWAnuhPCvIs+yqkpcOCUzl8skkoKwYw4KrNhw79z78JQ+9uP7+ zTf0T+TIRsWPyw9sWzonq5AEejJC6H4aRBqURZi1T3/lzplI3oz3Yx1JhfrQXX8rVuHF YhuDA6Qiv+56gTTdLG8eDUj/Wofr0tCUwk+brrAzjuJIlv3O3pylneNZJ0Hh08N1bjjx 5KQA== X-Received: by 10.69.13.132 with SMTP id ey4mr14274743pbd.52.1377188624307; Thu, 22 Aug 2013 09:23:44 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id dg3sm15816457pbc.24.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 09:23:43 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , "'Ralph Droms'" , "'Alexandru Petrescu'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> Date: Fri, 23 Aug 2013 00:23:36 +0800 Message-ID: <52163b0f.83b3440a.3854.6129@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOnzXvaLHmSLwSfkSFfLi6OLbc0pmhMawAgAAuoZA= Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:23:47 -0000 BV> Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft). No. This question has been answered in Med's mail. BV> ...that is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible idea (IMHO) since there is nothing to guarantee communication on which to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. Lifetime of the prefix pool will be the new concept on the server, = though it might be easy to derive from leases of those active PD prefixes in the = pool. This draft already has the following words: The PE router acting as the relay agent MAY set up a table for the lease or status of the prefix pools on it according to the leases of the delegated customer prefixes within the prefix pools. The lease of the prefix pool SHOULD dynamically set to be the maximum lease of the delegated customer prefix within it. The flag of the pool is designed for including the status of 'Active' or 'Released', which sounds 0=3Dactive=3Dadd the aggregation route, or 1=3Dreleased=3Dremove the aggregation route.=20 BV> But that's more of a minor issue as to whether the entire work is appropriate. Anyway, we will rethink (or revisit) your technical suggestion. BV> Cable CMTS devices have been snooping address and PD assignments for = a long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS. I guess the issue of static configuration is still there on the CMTS.=20 This question has been also answered in Med's mail. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Bernie Volz (volz) Sent: Thursday, August 22, 2013 9:12 PM To: Ralph Droms; Alexandru Petrescu Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Ralph: Thanks for bringing up that old draft! There were issues here that = caused this work to be abandoned. And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I = think one difference in the prefix-pool is that this is more to handle the = case where the relay (router) is told to inject X/48 into the routing instead = of Y/64 or Y/60 that might be going to the client. (This it to avoid having = to inject lots of /64 or /60 routes when many clients are 'connected via = the router'.) Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft). I did like agentop better than this proposal in one respect - and that = is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a = terrible idea (IMHO) since there is nothing to guarantee communication on which = to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. But that's more of a minor issue as to whether the entire = work is appropriate. Cable CMTS devices have been snooping address and PD assignments for a = long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ralph Droms Sent: Thursday, August 22, 2013 8:48 AM To: Alexandru Petrescu Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu wrote: > Hi, >=20 > One point I think is essential is the installment of routes in the=20 > DHCP Relay upon Prefix Assignment. >=20 > The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 > must install a route in the DHCP Relay upon delegation. >=20 > This draft seems to at least assume it, and to describe much more=20 > about > it: how various parts of assigned prefixes are aggregated and communicated. >=20 > I support it. After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have been aimed at the same problem. If I have that right, it might be instructive to review the dhc WG mailing list discussion that lead to = the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. - Ralph >=20 > Alex >=20 > Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >> Hi Tomek, >>=20 >> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20 >> useful feature in order to have more automation and also control=20 >> routes aggregation instead of relying on proprietary behaviors of=20 >> each implementation. Of course, part of these objectives can be=20 >> achieved if routes are installed manually or use an out of band=20 >> mechanism to enforce routing aggregation policies. Still, the=20 >> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because = >> the DHCP server has the knowledge of the prefix assignments; and=20 >> therefore routes can be triggered with dhcpv6 . >>=20 >> A way to progress with this document is to target the Experimental=20 >> track. Based on the experience that will be gained in real=20 >> deployments, the status can be revisited if required. >>=20 >> Cheers, Med >>=20 >>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski = Envoy=E9 >>> : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone=20 >>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>=20 >>> During Berlin meeting chairs asked if there is still interest in the = >>> prefix-pool-option. There was nobody interested in the work in the=20 >>> room. The unanimous consensus in the room was to drop it. I just=20 >>> wanted to confirm that on the list. >>>=20 >>> If you are interested in this work, want to support it and=20 >>> participate in it, please let us know by replying to the mailing=20 >>> list. Otherwise we'll drop this work and mark that draft as a dead=20 >>> WG document. >>>=20 >>> Please respond within 2 weeks (until Sep. 2nd). >>>=20 >>> Bernie & Tomek _______________________________________________ >>> dhcwg mailing list dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list=20 >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Thu Aug 22 11:04:10 2013 Return-Path: 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 B175A11E8112 for ; Thu, 22 Aug 2013 11:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS9rldonpf5w for ; Thu, 22 Aug 2013 11:04:10 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 152AD11E8100 for ; Thu, 22 Aug 2013 11:04:09 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id d10so1034508eaj.26 for ; Thu, 22 Aug 2013 11:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Pw3Ft00LX8oKEtHXdZ07HdIYS6O0f+2PdK/z5ngKAuk=; b=lkJrIjq/ggwwT/0KvXIIPUg3CpWqlwrpq5Qwnhhg5pv6M12gxYi7RCak58J5YRZmoe +Vnc+3cdTEMIxnhdG8us8+5AW8fcs2EVvpkcPFSMOr6zFWUtexXsPVSfh7bzB/kShFBZ obs7LVcmiuCqMTZfUjnKMJiZcf/aPEFxY/pegtoEspOaQAQpPdgM4FoAjFuhgtbGCLfU iY3kLW5UZL4wDk2BrpPbDBG/FRI+GT5FytdYuca3Uq3fMDTe33L0koeMKBBZzQQFW19J z/dPfgqiOZIss1sjMpp/yeq4G76S/PODp57wuAXMwLeHTCMJldzWX6YaBGvn9KULvx+W GTbw== X-Received: by 10.14.88.130 with SMTP id a2mr701eef.120.1377194649143; Thu, 22 Aug 2013 11:04:09 -0700 (PDT) Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id a43sm19114951eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 11:04:07 -0700 (PDT) Message-ID: <52165296.6010401@gmail.com> Date: Thu, 22 Aug 2013 20:04:06 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] IETF87 DHC minutes available (draft) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:04:10 -0000 The draft version of Berlin meeting minutes are available here: http://www.ietf.org/proceedings/87/minutes/minutes-87-dhc Thanks a lot to Suzanne Woolf for taking the minutes. Please review them and tell us if there are any inaccuracies. Send your comments by September 5th. We upload final version shortly afterwards. Bernie & Tomek From robmgl.ietf@gmail.com Thu Aug 22 13:31:30 2013 Return-Path: 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 3B70121F9FD6 for ; Thu, 22 Aug 2013 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAVGZCHZYXvu for ; Thu, 22 Aug 2013 13:31:29 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E321F9F96 for ; Thu, 22 Aug 2013 13:31:28 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 13so2116111lba.34 for ; Thu, 22 Aug 2013 13:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a/WWzA5jvcYibb3HQUPWzVb3qyp9C13+5FjX29FHUvU=; b=OLsPrQqlS3u+49lOWpWlxXMLf2wzO2mnVyeX0ozd0VmJQ8jRmr+XvRNvP4VyGC6ezz 9+B/6E7pK3yeAYoSnIzLTjTn1nfwKSQ1bGhaGsRlhdpge+ivVX2j+urWZZQuVE7hDNU3 PXdZxSOHRKGpNSoenEejMfrMv/GSwa2eqe+JumY2soEERxK0ueqeHsmdzBoZplLhNlKh lkA3qDCjqE10xOp7R7mWOk2ZwrlxjvERp/1WeLlPeFamb4ZC09xNxmsxmQL3tvZb8Fka Ev8myOH01ErTPG0/Jq7fwC6NS1wZE5n3wYJTGsFrr9w9d1yvX6Seu34S4qvuQc5x86TU eoIw== MIME-Version: 1.0 X-Received: by 10.112.128.166 with SMTP id np6mr13121749lbb.7.1377203486255; Thu, 22 Aug 2013 13:31:26 -0700 (PDT) Received: by 10.112.30.203 with HTTP; Thu, 22 Aug 2013 13:31:26 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 22 Aug 2013 16:31:26 -0400 Message-ID: From: Roberta Maglione To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=047d7b343ef294f24b04e48f2c39 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:31:30 -0000 --047d7b343ef294f24b04e48f2c39 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, Maybe I=92m missing something here, but I=92m struggling to see the value a= dded by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure on the router a summary/aggregate route and I announce it into the routing protocol. Moving to IPv6 you could do the same thing, I don=92t quite get what=92s wrong with that? You say you would like to have an automatic way to tell the PE to aggregate the routes, but if I understand correctly the proposal what you are doing here is only moving the configuration of the summary route from the PE to the DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, it would be per box or per service configuration so why do you want to add it to customers=92 profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, wrote: > Re-, > > IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same > objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. > > draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to > trigger route advertisement actions and to control the route aggregates t= o > be injected using a routing protocol. For example, a router can be told b= y > the DHCP server to advertise an aggregate even if not all individual > prefixes are assigned to customer located behind that router. This is a > measure that can help in optimizing routing tables and avoid injecting ve= ry > specific routes. Snooping the assignment and then guide the route > advertisement actions may not be lead to the same optimized routing table= s, > because there will be "holes" that will prevent aggregating routes. > > Having an explicit channel like the one specified in > draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. > > Cheers, > Med > > > >-----Message d'origine----- > >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e > >Ralph Droms > >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 > >=C0 : Alexandru Petrescu > >Cc : dhcwg@ietf.org WG > >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6- > >prefix-pool-opt? > > > > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > > wrote: > > > >> Hi, > >> > >> One point I think is essential is the installment of routes in the DHC= P > >> Relay upon Prefix Assignment. > >> > >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP mus= t > >> install a route in the DHCP Relay upon delegation. > >> > >> This draft seems to at least assume it, and to describe much more abou= t > >> it: how various parts of assigned prefixes are aggregated and > >communicated. > >> > >> I support it. > > > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to hav= e > >been aimed at the same problem. If I have that right, it might be > >instructive to review the dhc WG mailing list discussion that lead to th= e > >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > > > >- Ralph > > > >> > >> Alex > >> > >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : > >>> Hi Tomek, > >>> > >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a > >>> useful feature in order to have more automation and also control > >>> routes aggregation instead of relying on proprietary behaviors of > >>> each implementation. Of course, part of these objectives can be > >>> achieved if routes are installed manually or use an out of band > >>> mechanism to enforce routing aggregation policies. Still, the > >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior > >>> because the DHCP server has the knowledge of the prefix assignments; > >>> and therefore routes can be triggered with dhcpv6 . > >>> > >>> A way to progress with this document is to target the Experimental > >>> track. Based on the experience that will be gained in real > >>> deployments, the status can be revisited if required. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org > >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski > >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] An= yone > >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? > >>>> > >>>> During Berlin meeting chairs asked if there is still interest in > >>>> the prefix-pool-option. There was nobody interested in the work in > >>>> the room. The unanimous consensus in the room was to drop it. I > >>>> just wanted to confirm that on the list. > >>>> > >>>> If you are interested in this work, want to support it and > >>>> participate in it, please let us know by replying to the mailing > >>>> list. Otherwise we'll drop this work and mark that draft as a dead > >>>> WG document. > >>>> > >>>> Please respond within 2 weeks (until Sep. 2nd). > >>>> > >>>> Bernie & Tomek _______________________________________________ > >>>> dhcwg mailing list dhcwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dhcwg > >>> _______________________________________________ dhcwg mailing list > >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > >>> > >>> > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b343ef294f24b04e48f2c39 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello,

Maybe I=92m missing something here, but I=92m s= truggling to see the value added by this new option in terms of route aggregation functional= ity.

Today with IPv4 if I need to summarize some rou= tes I manually configure on the router a summary/aggregate route and I announce i= t into the routing protocol. Moving to IPv6 you could do the same thing, I don=92t qui= te get what=92s wrong with that?

You say you would like to have an automatic way= to tell the PE to aggregate the routes, but if I understand correctly the proposal what you a= re doing here is only moving the configuration of the summary route from the P= E to the DHCPv6 Server; what do you really save here?

In addition the route aggregation is not a per = customer configuration, it would be per box or per service configuration so why do y= ou want to add it to customers=92 profile in DCHPv6 Server?

Thanks

Roberta



= On Thu, Aug 22, 2013 at 9:45 AM, <mohamed.boucadair@orange.com= > wrote:
Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes.

Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO.

Cheers,
Med


>-----Message d'origine-----
>De=A0: dhcwg-bounces@ietf.org= [mailto:dhcwg-bounces@ietf.o= rg] De la part de
>Ralph Droms
>Envoy=E9=A0: jeudi 22 ao=FBt 2013 14:48
>=C0=A0: Alexandru Petrescu
>Cc=A0: dhcwg@ietf.org WG
>Objet=A0: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dh= cpv6-
>prefix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
><alexandru.petrescu@= gmail.com> wrote:
>
>> Hi,
>>
>> One point I think is essential is the installment of routes in the= DHCP
>> Relay upon Prefix Assignment.
>>
>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP= must
>> install a route in the DHCP Relay upon delegation.
>>
>> This draft seems to at least assume it, and to describe much more = about
>> it: how various parts of assigned prefixes are aggregated and
>communicated.
>>
>> I support it.
>
>After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to ha= ve
>been aimed at the same problem. =A0If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to t= he
>abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
>
>- Ralph
>
>>
>> Alex
>>
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit :
>>> Hi Tomek,
>>>
>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documen= ts a
>>> useful feature in order to have more automation and also contr= ol
>>> routes aggregation instead of relying on proprietary behaviors= of
>>> each implementation. Of course, part of these objectives can b= e
>>> achieved if routes are installed manually or use an out of ban= d
>>> mechanism to enforce routing aggregation policies. Still, the<= br> >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior<= br> >>> because the DHCP server has the knowledge of the prefix assign= ments;
>>> and therefore routes can be triggered with dhcpv6 .
>>>
>>> A way to progress with this document is to target the Experime= ntal
>>> track. Based on the experience that will be gained in real
>>> deployments, the status can be revisited if required.
>>>
>>> Cheers, Med
>>>
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mailto:dhcwg-bo= unces@ietf.org] De la part de Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : = [dhcwg] Anyone
>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-poo= l-opt?
>>>>
>>>> During Berlin meeting chairs asked if there is still inter= est in
>>>> the prefix-pool-option. There was nobody interested in the= work in
>>>> the room. The unanimous consensus in the room was to drop = it. I
>>>> just wanted to confirm that on the list.
>>>>
>>>> If you are interested in this work, want to support it and=
>>>> participate in it, please let us know by replying to the m= ailing
>>>> list. Otherwise we'll drop this work and mark that dra= ft as a dead
>>>> WG document.
>>>>
>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>>
>>>> Bernie & Tomek _______________________________________= ________
>>>> dhcwg mailing list dhcwg= @ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing = list
>>> dhcwg@ietf.org https://= www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--047d7b343ef294f24b04e48f2c39-- From mohamed.boucadair@orange.com Thu Aug 22 23:15:22 2013 Return-Path: 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 44FE311E8231 for ; Thu, 22 Aug 2013 23:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ysyvjLK2zrC for ; Thu, 22 Aug 2013 23:15:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 12B9911E81C6 for ; Thu, 22 Aug 2013 23:15:12 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6D2FF2ACF23; Fri, 23 Aug 2013 08:15:09 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 51738C805F; Fri, 23 Aug 2013 08:15:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 23 Aug 2013 08:15:09 +0200 From: To: Roberta Maglione Date: Fri, 23 Aug 2013 08:15:07 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+g Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EEEE4E6DBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.23.35415 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 06:15:22 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E6DBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roberta, Yes, as indicated in the document, manual configuration is an option... but= it has its limits too. This proposal is a contribution to add more automation to network configura= tion without requiring an additional dynamic protocol to drive how aggregat= es are built in a router co-located with a requestor, and therefore interac= t in a more dynamic fashion with a routing protocol (e.g., drive route with= drawals, etc.). Of course, some routers can offer some features to optimize the size of rou= ting tables and prevent from injecting (very) specific entries. But still t= his behavior is implementation-specific and does not provide the same aggre= gation level as the one proposed in this document. Unlike implementation-specific behaviors, this proposal is deterministic si= nce it is fully controlled by the entity which has the full knowledge of pr= efix related states and network policies: e.g., the server has the knowledg= e of prefix assignment, prefix assignment policies, prefix aggregates, etc. I confirm this option is not a per-customer configuration parameter. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : jeudi 22 ao=FBt 2013 22:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? Hello, Maybe I'm missing something here, but I'm struggling to see the value added= by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure on = the router a summary/aggregate route and I announce it into the routing pro= tocol. Moving to IPv6 you could do the same thing, I don't quite get what's= wrong with that? You say you would like to have an automatic way to tell the PE to aggregate= the routes, but if I understand correctly the proposal what you are doing = here is only moving the configuration of the summary route from the PE to t= he DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, it w= ould be per box or per service configuration so why do you want to add it t= o customers' profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, > wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] De la part de >Ralph Droms >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 >=C0 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >> wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la p= art de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyo= ne >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/list= info/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E6DBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E6DBPUEXCB1Bnante_-- From jinmei@isc.org Fri Aug 23 00:01:54 2013 Return-Path: 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 77CAD11E82D0 for ; Fri, 23 Aug 2013 00:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxUPs+mx2MSc for ; Fri, 23 Aug 2013 00:01:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A498A11E82CC for ; Fri, 23 Aug 2013 00:01:48 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B71B0C94CF; Fri, 23 Aug 2013 07:01:34 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 07:01:34 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 91AF6160363; Fri, 23 Aug 2013 07:01:52 +0000 (UTC) Received: from jmb.jinmei.org (99-115-129-51.uvs.sntcca.sbcglobal.net [99.115.129.51]) by zmx1.isc.org (Postfix) with ESMTPSA id 66F1F1602B4; Fri, 23 Aug 2013 07:01:52 +0000 (UTC) Date: Fri, 23 Aug 2013 00:01:31 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6664@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E186A6664@xmb-rcd-x04.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 07:01:54 -0000 At Thu, 22 Aug 2013 13:17:08 +0000, "Bernie Volz (volz)" wrote: > Unless we receive some additional comments from the WG, we will be forced to conclude that there is NO support for advancing these documents to Internet Standard. I don't know if this is a blocking issue, but I found some unclear points regarding DHCPv6 authentication and described them in an I-D several years ago: http://tools.ietf.org/id/draft-ietf-dhc-dhcpv6-clarify-auth-01.txt While the I-D itself was effectively dead, I suspect the issues are still open today. On a related note, I suspect the delayed authentication protocol has not really been used widely and/or proving interoperability beyond the experimental/testing level. In terms of the RFC6410 criteria, these are probably related to the following points: (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. -- JINMEI, Tatuya From leaf.yeh.sdo@gmail.com Fri Aug 23 00:52:27 2013 Return-Path: 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 56C911F0ED5 for ; Fri, 23 Aug 2013 00:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcaLZRauwVhA for ; Fri, 23 Aug 2013 00:52:15 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CB5C71F0D57 for ; Fri, 23 Aug 2013 00:52:15 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so370641pdi.28 for ; Fri, 23 Aug 2013 00:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=/kWdYwIbJwRQe7h5Q6Wdi7N1H++s7Ly7DIbhAVbqOKk=; b=bDkUVEVvp16K/0GWlvYHf1zywB1CA1zvo10dZsByfiIcWI/MPEFOJkKu6C+bZq54wP pkTkRFDyKeGGfZlF/yfSK9QFTrhQB/O2GlH3JnXR5c7Q8r5GcWhZ4+Q+bUiyhnYl3SWf 8kXS0hfSz9INsqC4rLvOq6uuEH2QzKj9YXPVY2BqJBgT0BCfShMf0Ov8fzmdYx04g0Yj dPjZwWmyii04KvMvp7IMfYOp5uHx4JjyRO472eNTHh9XSZhwhmQxloslQIAl+bufKbHx Ko1juZNN43vixxwT0wrGxiReG6Cst6ICLucGjNsBcfrEebuiphwtvZsl/BaumAyiUzIl v2Vg== X-Received: by 10.66.26.132 with SMTP id l4mr9778520pag.138.1377244335505; Fri, 23 Aug 2013 00:52:15 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id br3sm1789398pbd.31.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 00:52:14 -0700 (PDT) From: "Leaf Yeh" To: "'Roberta Maglione'" , References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Fri, 23 Aug 2013 15:52:06 +0800 Message-ID: <521714ae.e302450a.21db.6884@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6fdphFWKpf3nEhQX+HSdrz/9YSUQAP/mmA Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ralph Droms' Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 07:52:27 -0000 Roberta - ... I don=92t quite get what=92s wrong with that? If operator can't see the advantage of OPTION_PREFIX_POOL, he can still = live with the manual configuration for aggregation route on the PE router. = The draft just propose a new DHCPv6 option, operator could choose whether = or not to employ it. But I guess you will need route aggregation on most of your PE router, if you employ DHCPv6-PD for your IPv6 deployment. Roberta - ... but if I understand correctly the proposal what you are = doing here is only moving the configuration of the summary route from the PE = to the DHCPv6 Server; what do you really save here? That sounds the difference between the static (or manual) and the = dynamic. In the network scenario of centralized DHCPv6 server and distributed = relay agent, operator could deploy aggregation route automatic & dynamically = on each relay (or PE router) by the DHCPv6 server while employing OPTION_PREFIX_POOL, and not by the manual & static configuration on each = of them. As you know, the server has all the information about the customer's = address plan. If the DHCPv6 server employs the OPTION_PREFIX_POOL, operator = could also get the additional capability to revise the address plan for = customers, such as renumbering; or adjust the size of prefix pool on the DHCPv6 = server (as the centralized deployment). Roberta - ... why do you want to add it to customers=92 profile in = DCHPv6 Server? As mentioned above, DHCPv6 server not only has information about = customer's profile (eg. the lease & its' status of each customers prefix), but also = has information about the address plan for customers (eg. the associated = prefix pools)). We could try to define new concept on lease, lifetime or = status of the prefix pool (eg. for the dynamic aggregation route @ PE router), to enhance the deployment capability of DHCPv6 server. Best Regards, Leaf -------------------------------------------------------------------------= --- ------------------------------------------------------------- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Roberta Maglione Sent: Friday, August 23, 2013 4:31 AM To: mohamed.boucadair@orange.com Cc: dhcwg@ietf.org WG; Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Hello, Maybe I=92m missing something here, but I=92m struggling to see the = value added by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure = on the router a summary/aggregate route and I announce it into the routing protocol. Moving to IPv6 you could do the same thing, I don=92t quite = get what=92s wrong with that? You say you would like to have an automatic way to tell the PE to = aggregate the routes, but if I understand correctly the proposal what you are = doing here is only moving the configuration of the summary route from the PE = to the DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, = it would be per box or per service configuration so why do you want to add = it to customers=92 profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to trigger route advertisement actions and to control the route aggregates = to be injected using a routing protocol. For example, a router can be told = by the DHCP server to advertise an aggregate even if not all individual prefixes are assigned to customer located behind that router. This is a measure that can help in optimizing routing tables and avoid injecting = very specific routes. Snooping the assignment and then guide the route advertisement actions may not be lead to the same optimized routing = tables, because there will be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part de >Ralph Droms >Envoy=E9=A0: jeudi 22 ao=FBt 2013 14:48 >=C0=A0: Alexandru Petrescu >Cc=A0: dhcwg@ietf.org WG >Objet=A0: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the = DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP = must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more = about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have >been aimed at the same problem. =A0If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to = the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] = Anyone >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Aug 23 04:20:32 2013 Return-Path: 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 6F71C11E82F9 for ; Fri, 23 Aug 2013 04:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn+rs+XmEmp2 for ; Fri, 23 Aug 2013 04:20:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 173F911E82F5 for ; Fri, 23 Aug 2013 04:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25024; q=dns/txt; s=iport; t=1377256821; x=1378466421; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SNbidQ15Y3yZN0LeLZ++GOv09qTf7Dv6lMguOC66FWQ=; b=X5W8gcsNkJe1GjAe30fRAsiKfGNXT2k0fjrykvj6hKLvW+dDHywQDM8T vhTP9q468cXtMZUOTRJDNKhAb3TErZ/LAgpUyq11Vp/qLdF1rO85Y81pn EiFY0c5iWp0mhelufeAiGhQ54OI6covTPf3gaYnfvS4MqZxcSHrh0QL// U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggGAPZEF1KtJXG8/2dsb2JhbABagkNENcBPgR8WbQeCJAEBAQMBAQEBKj8CCxACAQgYIAcHIQYLFBEBAQQOBYd+AwkGDK0SDYlkBI1tgnUEBgGDG3sDlA2BcIFpjDGFKYFkgTs X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="scan'208,217";a="250850993" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 23 Aug 2013 11:20:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7NBKFce014497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 11:20:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 06:20:15 -0500 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+gAAuV46E= Date: Fri, 23 Aug 2013 11:20:14 +0000 Message-ID: <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7B81A958943446B6973AD4BD7F2C424Fciscocom_" MIME-Version: 1.0 Cc: Ralph Droms , "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:20:33 -0000 --_000_7B81A958943446B6973AD4BD7F2C424Fciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable BTW - I think I may have indicated this before, but does this really avoid = the need for configuration on the router (relay)? How are items such as the= link-address and next hop (dhcp server) addresses configured (rfc 3315 has= a multicast default)? So there is still a bunch of "manual" configuration = required? Admittedly you do say "more automation" but not really sure that = has a lot of value - perhaps we need a Dynamic Router Configuration BOF? - Bernie (from iPad) On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" > wrote: Hi Roberta, Yes, as indicated in the document, manual configuration is an option=85 but= it has its limits too. This proposal is a contribution to add more automation to network configura= tion without requiring an additional dynamic protocol to drive how aggregat= es are built in a router co-located with a requestor, and therefore interac= t in a more dynamic fashion with a routing protocol (e.g., drive route with= drawals, etc.). Of course, some routers can offer some features to optimize the size of rou= ting tables and prevent from injecting (very) specific entries. But still t= his behavior is implementation-specific and does not provide the same aggre= gation level as the one proposed in this document. Unlike implementation-specific behaviors, this proposal is deterministic si= nce it is fully controlled by the entity which has the full knowledge of pr= efix related states and network policies: e.g., the server has the knowledg= e of prefix assignment, prefix assignment policies, prefix aggregates, etc. I confirm this option is not a per-customer configuration parameter. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : jeudi 22 ao=FBt 2013 22:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? Hello, Maybe I=92m missing something here, but I=92m struggling to see the value a= dded by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure on = the router a summary/aggregate route and I announce it into the routing pro= tocol. Moving to IPv6 you could do the same thing, I don=92t quite get what= =92s wrong with that? You say you would like to have an automatic way to tell the PE to aggregate= the routes, but if I understand correctly the proposal what you are doing = here is only moving the configuration of the summary route from the PE to t= he DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, it w= ould be per box or per service configuration so why do you want to add it t= o customers=92 profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, > wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] De la part de >Ralph Droms >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 >=C0 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >> wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la p= art de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyo= ne >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/list= info/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_7B81A958943446B6973AD4BD7F2C424Fciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
BTW - I think I may have indicated this before, but does this really a= void the need for configuration on the router (relay)? How are items such a= s the link-address and next hop (dhcp server) addresses configured (rfc 331= 5 has a multicast default)? So there is still a bunch of "manual" configuration required? Admittedly = you do say "more automation" but not really sure that has a lot o= f value - perhaps we need a Dynamic Router Configuration BOF?

- Bernie (from iPad)

On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

Hi Roberta,

 

Yes, as indicated in the document, manual co= nfiguration is an option=85 but it has its limits too.

 

This proposal is a contribution to add more = automation to network configuration without requiring an additional dynamic= protocol to drive how aggregates are built in a router co-located with a requestor, and therefore interact in a more dyn= amic fashion with a routing protocol (e.g., drive route withdrawals, etc.).

 

Of course, some routers can offer some featu= res to optimize the size of routing tables and prevent from injecting (very= ) specific entries. But still this behavior is implementation-specific and does not provide the same aggregation level as= the one proposed in this document.

 

Unlike implementation-specific behaviors, th= is proposal is deterministic since it is fully controlled by the entity whi= ch has the full knowledge of prefix related states and network policies: e.g., the server has the knowledge of prefix assignm= ent, prefix assignment policies, prefix aggregates, etc.  <= /span>

 

I confirm this option is not a per-customer = configuration parameter.

 

Cheers,

Med

 

 

De : Robe= rta Maglione [mailto:robmgl.ietf@g= mail.com]
Envoy=E9 : jeudi 22 ao=FBt 2013 22:31
=C0 : BOUCADAIR Mohamed IMT/OLN<= br> Cc : Ralph Droms; dhcwg@ietf.= org WG
Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-= dhc-dhcpv6-prefix-pool-opt?

 

Hello,

Maybe I=92m missing s= omething here, but I=92m struggling to see the value added by this new opti= on in terms of route aggregation functionality.

Today with IPv4 if I = need to summarize some routes I manually configure on the router a summary/= aggregate route and I announce it into the routing protocol. Moving to IPv6 you could do the same thing, I don=92t quite get what=92s w= rong with that?

You say you would lik= e to have an automatic way to tell the PE to aggregate the routes, but if I= understand correctly the proposal what you are doing here is only moving the configuration of the summary route from the PE to the D= HCPv6 Server; what do you really save here?

In addition the route= aggregation is not a per customer configuration, it would be per box or pe= r service configuration so why do you want to add it to customers=92 profile in DCHPv6 Server?

Thanks

Roberta

 

On Thu, Aug 22, 2013 at 9:45 AM, <mohamed.boucadair@orange= .com> wrote:

Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes are assigned to customer located behin= d that router. This is a measure that can help in optimizing routing tables= and avoid injecting very specific routes. Snooping the assignment and then= guide the route advertisement actions may not be lead to the same optimized routing tables, because there will b= e "holes" that will prevent aggregating routes.

Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO.


Cheers,
Med


>-----Message d'origine-----
>De : dhcwg-bounces@ietf.= org [mailto:dhcwg-bounces@iet= f.org] De la part de

>Ralph Droms
>Envoy=E9 : jeudi 22 ao=FBt 2013 14:48
>=C0 : Alexandru Petrescu
>Cc : dhcwg@ietf.org WG
>Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc= -dhcpv6-

>prefix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
><alexandru.petrescu@= gmail.com> wrote:
>
>> Hi,
>>
>> One point I think is essential is the installment of routes in the= DHCP
>> Relay upon Prefix Assignment.
>>
>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP= must
>> install a route in the DHCP Relay upon delegation.
>>
>> This draft seems to at least assume it, and to describe much more = about
>> it: how various parts of assigned prefixes are aggregated and
>communicated.
>>
>> I support it.
>
>After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to ha= ve
>been aimed at the same problem.  If I have that right, it might be=
>instructive to review the dhc WG mailing list discussion that lead to t= he
>abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
>
>- Ralph
>
>>
>> Alex
>>
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit :
>>> Hi Tomek,
>>>
>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documen= ts a
>>> useful feature in order to have more automation and also contr= ol
>>> routes aggregation instead of relying on proprietary behaviors= of
>>> each implementation. Of course, part of these objectives can b= e
>>> achieved if routes are installed manually or use an out of ban= d
>>> mechanism to enforce routing aggregation policies. Still, the<= br> >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior<= br> >>> because the DHCP server has the knowledge of the prefix assign= ments;
>>> and therefore routes can be triggered with dhcpv6 .
>>>
>>> A way to progress with this document is to target the Experime= ntal
>>> track. Based on the experience that will be gained in real
>>> deployments, the status can be revisited if required.
>>>
>>> Cheers, Med
>>>
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mailto:dhcwg-bo= unces@ietf.org] De la part de Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : = [dhcwg] Anyone
>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-poo= l-opt?
>>>>
>>>> During Berlin meeting chairs asked if there is still inter= est in
>>>> the prefix-pool-option. There was nobody interested in the= work in
>>>> the room. The unanimous consensus in the room was to drop = it. I
>>>> just wanted to confirm that on the list.
>>>>
>>>> If you are interested in this work, want to support it and=
>>>> participate in it, please let us know by replying to the m= ailing
>>>> list. Otherwise we'll drop this work and mark that draft a= s a dead
>>>> WG document.
>>>>
>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>>
>>>> Bernie & Tomek _______________________________________= ________
>>>> dhcwg mailing list dhcwg= @ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing = list
>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.i= etf.org/mailman/listinfo/dhcwg
--_000_7B81A958943446B6973AD4BD7F2C424Fciscocom_-- From otroan@employees.org Fri Aug 23 04:24:46 2013 Return-Path: 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 3418E21F9A81 for ; Fri, 23 Aug 2013 04:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayGhGIzbPaJf for ; Fri, 23 Aug 2013 04:24:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2541321F9D82 for ; Fri, 23 Aug 2013 04:24:39 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="asc'?scan'208";a="86088581" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 23 Aug 2013 11:24:39 +0000 Received: from dhcp-lys01-vla250-10-147-112-91.cisco.com (dhcp-lys01-vla250-10-147-112-91.cisco.com [10.147.112.91]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7NBOaHk010964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 11:24:37 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6C2D01D7-7CDD-416B-8AFD-A9EDDD0B3B88"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> Date: Fri, 23 Aug 2013 13:24:36 +0200 Message-Id: References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:24:46 -0000 --Apple-Mail=_6C2D01D7-7CDD-416B-8AFD-A9EDDD0B3B88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > BTW - I think I may have indicated this before, but does this really = avoid the need for configuration on the router (relay)? How are items = such as the link-address and next hop (dhcp server) addresses configured = (rfc 3315 has a multicast default)? So there is still a bunch of = "manual" configuration required? Admittedly you do say "more automation" = but not really sure that has a lot of value - perhaps we need a Dynamic = Router Configuration BOF? that isn't handled by netconf, netmod, i2rs already? not to mention all the other protocols for network management. cheers, Ole --Apple-Mail=_6C2D01D7-7CDD-416B-8AFD-A9EDDD0B3B88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSF0Z0AAoJEFuJXizso86gcNEH+gInF2Ln7rI2QFEqHTFrbUDf MbgwVtvdLhfq30DsxPA0yrKq0Lr89cPVwEkqXpvcKkVvRh72a4AO2e+7cwgrj6Ri 7syAO3XJxIyuZNOsg7sYTaSkpBovcYUC7VzjJ+WkLXtOZ02zG5sqLhblnMlDWPp9 KLis7T2DYlA1m50MmXevMTdNT9ZTRMEMvGYAMFFOskkVckwgPFslfD1gcGKOIdSF 2wRCBTHwsMKe8tTiJpCTAfsQFeyI4WnNqBzvUUnDQMNf0ndyWXDMYb29ByE8pYns RNAOlur32SqXvFeyYcEl2U8lkdhOXb97ch47CbhjEWP28yA66NewK7npSU5Aq0c= =vLgj -----END PGP SIGNATURE----- --Apple-Mail=_6C2D01D7-7CDD-416B-8AFD-A9EDDD0B3B88-- From volz@cisco.com Fri Aug 23 04:28:46 2013 Return-Path: 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 CE9E111E8147 for ; Fri, 23 Aug 2013 04:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEk9cPKd+gUO for ; Fri, 23 Aug 2013 04:28:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24111E8128 for ; Fri, 23 Aug 2013 04:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=751; q=dns/txt; s=iport; t=1377257321; x=1378466921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LlAUJmqaGozrhhpooz5BRNvvcqozk+RqmU+ya082WA8=; b=jsB8XGDCNLdE58fWe82EmL7ByJ0XqIqF6pfLm0gelvZ3Uj+TX1roZcWM PFVaOG2XPcuEkUNfAyYmLm6fYRKyqAdk1nMn1iiRSVwcCg/CihAWNF7If XvAJprO8fVktwaGgIOCMvAFEDfwpWlTqc+cRDbFgsujHFNmCENmfp/aKX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMFAFhGF1KtJXHA/2dsb2JhbABagweDWr0qgR8WdIIkAQEBAwE6PxACAQgOKBAyJQEBBA4FiAoGtwiQMzMHgxt7A5dmkVqBZIE7 X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="scan'208";a="247880171" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2013 11:28:41 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7NBSd1N026958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 11:28:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 06:28:39 -0500 From: "Bernie Volz (volz)" To: Ole Troan Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+gAAuV46EACqEtAP//rU+w Date: Fri, 23 Aug 2013 11:28:38 +0000 Message-ID: <3BC0306F-73FE-4C49-9CA6-D1602F4D7AFB@cisco.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:28:46 -0000 I was joking about the BOF ... - Bernie (from iPad) On Aug 23, 2013, at 7:24 AM, "Ole Troan" wrote: >> BTW - I think I may have indicated this before, but does this really avo= id the need for configuration on the router (relay)? How are items such as = the link-address and next hop (dhcp server) addresses configured (rfc 3315 = has a multicast default)? So there is still a bunch of "manual" configurati= on required? Admittedly you do say "more automation" but not really sure th= at has a lot of value - perhaps we need a Dynamic Router Configuration BOF? >=20 > that isn't handled by netconf, netmod, i2rs already? > not to mention all the other protocols for network management. >=20 > cheers, > Ole From otroan@employees.org Fri Aug 23 04:30:41 2013 Return-Path: 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 D1B8111E8128 for ; Fri, 23 Aug 2013 04:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFBPnVwr9C84 for ; Fri, 23 Aug 2013 04:30:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C02D511E8147 for ; Fri, 23 Aug 2013 04:30:35 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="asc'?scan'208";a="158824065" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 23 Aug 2013 11:30:34 +0000 Received: from dhcp-lys01-vla250-10-147-112-91.cisco.com (dhcp-lys01-vla250-10-147-112-91.cisco.com [10.147.112.91]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7NBUWEg011061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 11:30:32 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_1FFCE504-A25B-4553-8111-676D6B401B34"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <3BC0306F-73FE-4C49-9CA6-D1602F4D7AFB@cisco.com> Date: Fri, 23 Aug 2013 13:30:31 +0200 Message-Id: <53ED8714-760E-438C-A29B-5A5212B68B7E@employees.org> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com>, <3BC0306F-73FE-4C49-9CA6-D1602F4D7AFB@cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:30:41 -0000 --Apple-Mail=_1FFCE504-A25B-4553-8111-676D6B401B34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I was joking about the BOF ... LOL, I did laugh. ;-) cheers, Ole >=20 > - Bernie (from iPad) >=20 > On Aug 23, 2013, at 7:24 AM, "Ole Troan" wrote: >=20 >>> BTW - I think I may have indicated this before, but does this really = avoid the need for configuration on the router (relay)? How are items = such as the link-address and next hop (dhcp server) addresses configured = (rfc 3315 has a multicast default)? So there is still a bunch of = "manual" configuration required? Admittedly you do say "more automation" = but not really sure that has a lot of value - perhaps we need a Dynamic = Router Configuration BOF? >>=20 >> that isn't handled by netconf, netmod, i2rs already? >> not to mention all the other protocols for network management. >>=20 >> cheers, >> Ole --Apple-Mail=_1FFCE504-A25B-4553-8111-676D6B401B34 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSF0fYAAoJEFuJXizso86gWCoH/03l78SXf1ZeqvTWZdSXdQT0 MrWf4Wn9jH2WhQfEWFkL2zXfoSR+9723WhYS99pRwgSODOGF/m0+nxdxIbN5fJv+ Oe4b36Oj7Y8PhOpjBdegmiLY2kGeKE+UDfoQ2siRal7doFRkcyY94lWfkgHFw6BS Rf8T9hEgVL9k3qj1EgpBG7PIfV+Wtg9k+X9Fny05lqVOR00Mbo39r7NjjObfRiHs gEw9bx2C+Axzn6jIlstGkgs26O3hoV4lQUWFPwLdfbQ7a8Oo8hYj9tf/kQyd1Spm V+opFaqGGYa9RrWzEQ8+9Qcx/7v5rfpiX3Jmn841+kfI96+3aYjdUKysAqLjPVw= =Dn5/ -----END PGP SIGNATURE----- --Apple-Mail=_1FFCE504-A25B-4553-8111-676D6B401B34-- From mohamed.boucadair@orange.com Fri Aug 23 05:11:05 2013 Return-Path: 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 9A65211E80F4 for ; Fri, 23 Aug 2013 05:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i+n2Xr2n8Z6 for ; Fri, 23 Aug 2013 05:11:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B704811E80D1 for ; Fri, 23 Aug 2013 05:10:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5CE463255F8; Fri, 23 Aug 2013 14:10:58 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 399DB35C045; Fri, 23 Aug 2013 14:10:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 23 Aug 2013 14:10:58 +0200 From: To: "Bernie Volz (volz)" Date: Fri, 23 Aug 2013 14:10:55 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+gAAuV46EAAQ37gA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4E80B@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> In-Reply-To: <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EEEE4E80BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.23.95722 Cc: Ralph Droms , "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:11:05 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E80BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernie, This proposal does not conflict with the use of dedicated dynamic provision= ing channels (e.g., COPS, NETCONF, home-made scripts, etc.) for other needs= . It does focus on a very specific issue of controlling route entries in a = specific network element. The server which owns the information can trigger required route advertisem= ent actions in-band without requiring an out of band mechanism for this pur= pose. No interface is needed between the dhcp server and a dedicated contro= ller which is responsible for generating and communicating appropriate rout= ing policies to the router. Cheers, Med De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : vendredi 23 ao=FBt 2013 13:20 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Roberta Maglione; dhcwg@ietf.org WG; Ralph Droms Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? BTW - I think I may have indicated this before, but does this really avoid = the need for configuration on the router (relay)? How are items such as the= link-address and next hop (dhcp server) addresses configured (rfc 3315 has= a multicast default)? So there is still a bunch of "manual" configuration = required? Admittedly you do say "more automation" but not really sure that = has a lot of value - perhaps we need a Dynamic Router Configuration BOF? - Bernie (from iPad) On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" > wrote: Hi Roberta, Yes, as indicated in the document, manual configuration is an option... but= it has its limits too. This proposal is a contribution to add more automation to network configura= tion without requiring an additional dynamic protocol to drive how aggregat= es are built in a router co-located with a requestor, and therefore interac= t in a more dynamic fashion with a routing protocol (e.g., drive route with= drawals, etc.). Of course, some routers can offer some features to optimize the size of rou= ting tables and prevent from injecting (very) specific entries. But still t= his behavior is implementation-specific and does not provide the same aggre= gation level as the one proposed in this document. Unlike implementation-specific behaviors, this proposal is deterministic si= nce it is fully controlled by the entity which has the full knowledge of pr= efix related states and network policies: e.g., the server has the knowledg= e of prefix assignment, prefix assignment policies, prefix aggregates, etc. I confirm this option is not a per-customer configuration parameter. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : jeudi 22 ao=FBt 2013 22:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? Hello, Maybe I'm missing something here, but I'm struggling to see the value added= by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure on = the router a summary/aggregate route and I announce it into the routing pro= tocol. Moving to IPv6 you could do the same thing, I don't quite get what's= wrong with that? You say you would like to have an automatic way to tell the PE to aggregate= the routes, but if I understand correctly the proposal what you are doing = here is only moving the configuration of the summary route from the PE to t= he DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, it w= ould be per box or per service configuration so why do you want to add it t= o customers' profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, > wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] De la part de >Ralph Droms >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 >=C0 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >> wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la p= art de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyo= ne >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/list= info/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E80BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roberta,

 

Yes, as indicated in the document, manual configuration is an option&= #8230; but it has its limits too.

=  

This proposal is a contribut= ion to add more automation to network configuration without requiring an ad= ditional dynamic protocol to drive how aggregates are built in a router co-= located with a requestor, and therefore interact in a more dynamic fashion = with a routing protocol (e.g., drive route withdrawals, etc.). <= /span>

 

Of course, some routers can offer some features to optimize the size of ro= uting tables and prevent from injecting (very) specific entries. But still = this behavior is implementation-specific and does not provide the same aggr= egation level as the one proposed in this document.

<= p class=3DMsoNormal> 

Unlike imp= lementation-specific behaviors, this proposal is deterministic since it is = fully controlled by the entity which has the full knowledge of prefix relat= ed states and network policies: e.g., the server has the knowledge of prefi= x assignment, prefix assignment policies, prefix aggregates, etc. =A0<= /o:p>

 

I confirm this option is not a per-customer configuration parameter.=

 

Cheers,

Med

 

 

De = ;: Roberta Maglione [mailto:robmgl.ietf@gmail.com]
Envoy=E9 = : jeudi 22 ao=FBt 2013 22:31
=C0 : BOUCADAIR Mo= hamed IMT/OLN
Cc : Ralph Droms; dhcwg@ietf.org WG
Obje= t : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhc= pv6-prefix-pool-opt?

=  

Hello,

Maybe I’m missing some= thing here, but I’m struggling to see the value added by this new opt= ion in terms of route aggregation functionality.

Today with IPv4 if I need to summarize some ro= utes I manually configure on the router a summary/aggregate route and I ann= ounce it into the routing protocol. Moving to IPv6 you could do the same th= ing, I don’t quite get what’s wrong with that?

You say you would like to have an au= tomatic way to tell the PE to aggregate the routes, but if I understand cor= rectly the proposal what you are doing here is only moving the configuratio= n of the summary route from the PE to the DHCPv6 Server; what do you really= save here?

In addit= ion the route aggregation is not a per customer configuration, it would be = per box or per service configuration so why do you want to add it to custom= ers’ profile in DCHPv6 Server?

Thanks

Roberta

 

On Thu,= Aug 22, 2013 at 9:45 AM, <mohamed.boucadair@orange.com> wrote:=

Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-d= elegate does not cover the same objectives as in draft-ietf-dhc-dhcpv6-pref= ix-pool-opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a= dynamic means to trigger route advertisement actions and to control the ro= ute aggregates to be injected using a routing protocol. For example, a rout= er can be told by the DHCP server to advertise an aggregate even if not all= individual prefixes are assigned to customer located behind that router. T= his is a measure that can help in optimizing routing tables and avoid injec= ting very specific routes. Snooping the assignment and then guide the route= advertisement actions may not be lead to the same optimized routing tables= , because there will be "holes" that will prevent aggregating rou= tes.

Having an explicit channel like the one specified in draft-ietf= -dhc-dhcpv6-prefix-pool-opt is superior IMHO.


Cheers,
Med


>-----Message d'origine-----<= br>>De : dhcwg-bounces@ie= tf.org [mailto:dhcwg-bounces@= ietf.org] De la part de

>Ra= lph Droms
>Envoy=E9 : jeudi 22 ao=FBt 2013 14:48
>=C0 = ;: Alexandru Petrescu
>Cc : dh= cwg@ietf.org WG
>Objet : Re: [dhcwg] Anyone interested in co= ntinuing draft-ietf-dhc-dhcpv6-

>prefix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8= /21/13, Alexandru Petrescu
><alexandru.petrescu@gmail.com> wrote:
>
>> = Hi,
>>
>> One point I think is essential is the installme= nt of routes in the DHCP
>> Relay upon Prefix Assignment.
>&= gt;
>> The base DHCPv6 Prefix Delegation RFC does not stipulate th= at DHCP must
>> install a route in the DHCP Relay upon delegation.=
>>
>> This draft seems to at least assume it, and to des= cribe much more about
>> it: how various parts of assigned prefixe= s are aggregated and
>communicated.
>>
>> I support= it.
>
>After a quick read, draft-ietf-dhc-dhcpv6-agentopt-dele= gate seems to have
>been aimed at the same problem.  If I have t= hat right, it might be
>instructive to review the dhc WG mailing list= discussion that lead to the
>abandonment of draft-ietf-dhc-dhcpv6-ag= entopt-delegate.
>
>- Ralph
>
>>
>> Ale= x
>>
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit :
>>= ;> Hi Tomek,
>>>
>>> I do still think draft-ietf= -dhc-dhcpv6-prefix-pool-opt documents a
>>> useful feature in o= rder to have more automation and also control
>>> routes aggreg= ation instead of relying on proprietary behaviors of
>>> each i= mplementation. Of course, part of these objectives can be
>>> a= chieved if routes are installed manually or use an out of band
>>&= gt; mechanism to enforce routing aggregation policies. Still, the
>&g= t;> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior
>= ;>> because the DHCP server has the knowledge of the prefix assignmen= ts;
>>> and therefore routes can be triggered with dhcpv6 .
= >>>
>>> A way to progress with this document is to tar= get the Experimental
>>> track. Based on the experience that wi= ll be gained in real
>>> deployments, the status can be revisit= ed if required.
>>>
>>> Cheers, Med
>>>=
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mailto= :dhcwg-bounces@ietf.org] De l= a part de Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 20= 13 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone
>>>> interested = in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>>>>>> During Berlin meeting chairs asked if there is still int= erest in
>>>> the prefix-pool-option. There was nobody inter= ested in the work in
>>>> the room. The unanimous consensus = in the room was to drop it. I
>>>> just wanted to confirm th= at on the list.
>>>>
>>>> If you are interest= ed in this work, want to support it and
>>>> participate in = it, please let us know by replying to the mailing
>>>> list.= Otherwise we'll drop this work and mark that draft as a dead
>>&g= t;> WG document.
>>>>
>>>> Please respond = within 2 weeks (until Sep. 2nd).
>>>>
>>>> Be= rnie & Tomek _______________________________________________
>>= ;>> dhcwg mailing list dhcwg@ietf.o= rg
>>>> https://www.ietf.org/mailman/listinfo/dhcwg>>> _______________________________________________ dhcwg mailin= g list
>>> dhcwg@ietf.org= = https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>= >
>>
>>
>> __________________________________= _____________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/= listinfo/dhcwg
>
>_________________________________________= ______
>dhcwg mailing list
>d= hcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg
= _______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/m= ailman/listinfo/dhcwg

 

Hi Bernie,

 

This proposal does not conflict with the use of dedicated dynamic prov= isioning channels (e.g., COPS, NETCONF, home-made scripts, etc.) for other = needs. It does focus on a very specific issue of controlling route entries = in a specific network element.

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'> 

The server which owns the infor= mation can trigger required route advertisement actions in-band without req= uiring an out of band mechanism for this purpose. No interface is needed be= tween the dhcp server and a dedicated controller which is responsible for g= enerating and communicating appropriate routing policies to the router.

 

Cheers,

Med

 

=  

= De : Bernie Volz (volz) [mailto:volz@cisco.com]
En= voy=E9 : vendredi 23 ao=FBt 2013 13:20
=C0 : BOUCAD= AIR Mohamed IMT/OLN
Cc : Roberta Maglione; dhcwg@ietf.org WG= ; Ralph Droms
Objet : Re: [dhcwg] Anyone interested in conti= nuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

 

BTW = - I think I may have indicated this before, but does this really avoid the = need for configuration on the router (relay)? How are items such as the lin= k-address and next hop (dhcp server) addresses configured (rfc 3315 has a m= ulticast default)? So there is still a bunch of "manual" configur= ation required? Admittedly you do say "more automation" but not r= eally sure that has a lot of value - perhaps we need a Dynamic Router Confi= guration BOF?


- Bernie (f= rom iPad)


On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t; wrote:

Hi Roberta,

 

Yes, as indic= ated in the document, manual configuration is an option… but it has i= ts limits too.

 <= /o:p>

This proposal is a contribution to add more aut= omation to network configuration without requiring an additional dynamic pr= otocol to drive how aggregates are built in a router co-located with a requ= estor, and therefore interact in a more dynamic fashion with a routing prot= ocol (e.g., drive route withdrawals, etc.).

 

Of course, some r= outers can offer some features to optimize the size of routing tables and p= revent from injecting (very) specific entries. But still this behavior is i= mplementation-specific and does not provide the same aggregation level as t= he one proposed in this document.

=  

Unlike implementation-specif= ic behaviors, this proposal is deterministic since it is fully controlled b= y the entity which has the full knowledge of prefix related states and netw= ork policies: e.g., the server has the knowledge of prefix assignment, pref= ix assignment policies, prefix aggregates, etc.  

 

I confir= m this option is not a per-customer configuration parameter.

 

= Ch= eers,

Med

 

 =

De : Roberta Ma= glione [mailto:robmgl.ietf@gmail.c= om]
Envoy=E9 : jeudi 22 ao=FBt 2013 22:31
=C0&nbs= p;: BOUCADAIR Mohamed IMT/OLN
Cc : Ralph Droms;= dhcwg@ietf.org WG
Objet := Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-pref= ix-pool-opt?

 

Hello,

Maybe I’m missing something he= re, but I’m struggling to see the value added by this new option in t= erms of route aggregation functionality.

Today with IPv4 if I need to summarize some routes I m= anually configure on the router a summary/aggregate route and I announce it= into the routing protocol. Moving to IPv6 you could do the same thing, I d= on’t quite get what’s wrong with that?

You say you would like to have an automatic = way to tell the PE to aggregate the routes, but if I understand correctly t= he proposal what you are doing here is only moving the configuration of the= summary route from the PE to the DHCPv6 Server; what do you really save he= re?

In addition the = route aggregation is not a per customer configuration, it would be per box = or per service configuration so why do you want to add it to customers̵= 7; profile in DCHPv6 Server?

Thanks

Robe= rta

 

On Thu, Aug 22,= 2013 at 9:45 AM, <mohamed.boucadair@orange.com> wrote:

Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate = does not cover the same objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-= opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic= means to trigger route advertisement actions and to control the route aggr= egates to be injected using a routing protocol. For example, a router can b= e told by the DHCP server to advertise an aggregate even if not all individ= ual prefixes are assigned to customer located behind that router. This is a= measure that can help in optimizing routing tables and avoid injecting ver= y specific routes. Snooping the assignment and then guide the route adverti= sement actions may not be lead to the same optimized routing tables, becaus= e there will be "holes" that will prevent aggregating routes.
=
Having an explicit channel like the one specified in draft-ietf-dhc-dhc= pv6-prefix-pool-opt is superior IMHO.


Cheers,
Med


>-----Message d'origine-----
>De&= nbsp;: dhcwg-bounces@ietf.org= [mailto:dhcwg-bounces@ietf.org] De la part de

>Ralph Droms<= br>>Envoy=E9 : jeudi 22 ao=FBt 2013 14:48
>=C0 : Alexand= ru Petrescu
>Cc : dhcwg@ietf.o= rg WG
>Objet : Re: [dhcwg] Anyone interested in continuing d= raft-ietf-dhc-dhcpv6-

>pref= ix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8/21/13, Al= exandru Petrescu
><alexandru.petrescu@gmail.com> wrote:
>
>> Hi,
>= ;>
>> One point I think is essential is the installment of rout= es in the DHCP
>> Relay upon Prefix Assignment.
>>
>= ;> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP mu= st
>> install a route in the DHCP Relay upon delegation.
>&g= t;
>> This draft seems to at least assume it, and to describe much= more about
>> it: how various parts of assigned prefixes are aggr= egated and
>communicated.
>>
>> I support it.
&g= t;
>After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems= to have
>been aimed at the same problem.  If I have that right,= it might be
>instructive to review the dhc WG mailing list discussio= n that lead to the
>abandonment of draft-ietf-dhc-dhcpv6-agentopt-del= egate.
>
>- Ralph
>
>>
>> Alex
>&= gt;
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit :
>>> Hi T= omek,
>>>
>>> I do still think draft-ietf-dhc-dhcpv= 6-prefix-pool-opt documents a
>>> useful feature in order to ha= ve more automation and also control
>>> routes aggregation inst= ead of relying on proprietary behaviors of
>>> each implementat= ion. Of course, part of these objectives can be
>>> achieved if= routes are installed manually or use an out of band
>>> mechan= ism to enforce routing aggregation policies. Still, the
>>> pro= posal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior
>>> = because the DHCP server has the knowledge of the prefix assignments;
>= ;>> and therefore routes can be triggered with dhcpv6 .
>>&g= t;
>>> A way to progress with this document is to target the Ex= perimental
>>> track. Based on the experience that will be gain= ed in real
>>> deployments, the status can be revisited if requ= ired.
>>>
>>> Cheers, Med
>>>
>&g= t;>> -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mailto:dhcwg-bounces@ietf.org] De la part d= e Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52= =C0 : dhcwg Objet : [dhcwg] Anyone
>>>> interested in conti= nuing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>>
>&g= t;>> During Berlin meeting chairs asked if there is still interest in=
>>>> the prefix-pool-option. There was nobody interested in= the work in
>>>> the room. The unanimous consensus in the r= oom was to drop it. I
>>>> just wanted to confirm that on th= e list.
>>>>
>>>> If you are interested in th= is work, want to support it and
>>>> participate in it, plea= se let us know by replying to the mailing
>>>> list. Otherwi= se we'll drop this work and mark that draft as a dead
>>>> W= G document.
>>>>
>>>> Please respond within 2= weeks (until Sep. 2nd).
>>>>
>>>> Bernie &am= p; Tomek _______________________________________________
>>>>= ; dhcwg mailing list dhcwg@ietf.org>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>&g= t;> _______________________________________________ dhcwg mailing list>>> dhcwg@ietf.org https://= www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
= >>
>>
>> __________________________________________= _____
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo= /dhcwg
>
>_______________________________________________>dhcwg mailing list
>dhcwg@iet= f.org
>https://www.ietf.org/mailman/listinfo/dhcwg
________= _______________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/l= istinfo/dhcwg

&nbs= p;

_________________= ______________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E80BPUEXCB1Bnante_-- From sthaug@nethelp.no Fri Aug 23 05:18:53 2013 Return-Path: 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 C1D9711E82F5 for ; Fri, 23 Aug 2013 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTsHMk0nF46a for ; Fri, 23 Aug 2013 05:18:48 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0167111E811D for ; Fri, 23 Aug 2013 05:18:47 -0700 (PDT) Received: (qmail 41396 invoked from network); 23 Aug 2013 12:18:44 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Aug 2013 12:18:44 -0000 Date: Fri, 23 Aug 2013 14:18:44 +0200 (CEST) Message-Id: <20130823.141844.74728418.sthaug@nethelp.no> To: volz@cisco.com From: sthaug@nethelp.no In-Reply-To: <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rdroms.ietf@gmail.com Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:18:53 -0000 > BTW - I think I may have indicated this before, but does this really avoid the need for configuration on the router (relay)? How are items such as the link-address and next hop (dhcp server) addresses configured (rfc 3315 has a multicast default)? So there is still a bunch of "manual" configuration required? Admittedly you do say "more automation" but not really sure that has a lot of value - perhaps we need a Dynamic Router Configuration BOF? As an operator I would prefer DHCPv6 to work similarly to DHCPv4 in a typical scenario of: - Large pools are explicitly configured on routers (relay agents). - DHCP server is allowed to hand out addresses *within these pools*. - Routers (relay agents) use information in the relayed DHCP packets to build up some state (for instance making it possible to invalidate the IP address when the lease expires). Thus the DHCP server has a *limited* amount of freedom to hand out IP within pools already known by the routers. I would be very uncomfortable with, and probably would not want to use, DHCP options which would let the DHCP server control address allocation without any kind of preconfiguration on the router. Steinar Haug, AS 2116 From leaf.yeh.sdo@gmail.com Fri Aug 23 05:29:40 2013 Return-Path: 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 49E0311E82F1 for ; Fri, 23 Aug 2013 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrlBMmLhjhFH for ; Fri, 23 Aug 2013 05:29:39 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 601CC11E81B9 for ; Fri, 23 Aug 2013 05:29:39 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so634399pdi.0 for ; Fri, 23 Aug 2013 05:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=CceFBMeT7FgV6+s5LS4K7gr95/quC3ZKriycJx38PUY=; b=Aa2uTSEgQE/F8fr4sPO1SXIGPKj4M9Dn1UaNoUrRIhNAwJE2d3iTjd9YCS3ZbEceTi sAVU6x10kSv+eGNrojgHFRRw0kI2ztL3Wb8zG9X2eN5eDah1E7XH/AC/mB2jphMLCdX4 BZv9vAUUouRRIWWy3y39ordcLpJ7FUFy+bPnjEwFzANKPxLCQ3ncMuF2WRK3gj5fxNQ5 c/rKzE4HaWSlm89uy1ZNcUXjgj2Ka70weQCvOTXYagPKKfIIljMUzS40N6AG1NKaCeuj ex0sKzi4tp/vJDp4271sRqjhZITwzgrEs3U9gBSkglHhwKUaggSaZfO6YP/rzVPJWP/a SjJw== X-Received: by 10.68.241.6 with SMTP id we6mr2802767pbc.174.1377260979105; Fri, 23 Aug 2013 05:29:39 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id nj9sm21261879pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 05:29:38 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , , "'Ole Troan'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> In-Reply-To: <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> Date: Fri, 23 Aug 2013 20:29:29 +0800 Message-ID: <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+gAAuV46EAADNqYA== Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ralph Droms' Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:29:40 -0000 BV> How are items such as the link-address and next hop (dhcp server) addresses configured (rfc 3315 has a multicast default)? So there is = still a bunch of "manual" configuration required? Those parameters mentioned above sounds the static part of configuration = on the relay (at PE router). In fact of parameter configuration, = link-address of the relay could be IPv6 Link-Local address, you might not need to configure it; though 'next hop (dhcp server) addresses' of the relay is = a must for manual configuration or through a ready management tool. BV> Dynamic Router Configuration BOF? That sounds a new chapter of this draft. I suspect I will have a chance = to join. :-) LOL :-) Best Regards, Leaf -------------------------------------------------------------------------= --- ------------------------------------------------------------ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Bernie Volz (volz) Sent: Friday, August 23, 2013 7:20 PM To: mohamed.boucadair@orange.com Cc: Ralph Droms; dhcwg@ietf.org WG Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? BTW - I think I may have indicated this before, but does this really = avoid the need for configuration on the router (relay)? How are items such as = the link-address and next hop (dhcp server) addresses configured (rfc 3315 = has a multicast default)? So there is still a bunch of "manual" configuration required? Admittedly you do say "more automation" but not really sure = that has a lot of value - perhaps we need a Dynamic Router Configuration BOF? - Bernie (from iPad) On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" wrote: Hi Roberta, =A0 Yes, as indicated in the document, manual configuration is an option=85 = but it has its limits too.=20 =A0 This proposal is a contribution to add more automation to network configuration without requiring an additional dynamic protocol to drive = how aggregates are built in a router co-located with a requestor, and = therefore interact in a more dynamic fashion with a routing protocol (e.g., drive route withdrawals, etc.).=20 =A0 Of course, some routers can offer some features to optimize the size of routing tables and prevent from injecting (very) specific entries. But = still this behavior is implementation-specific and does not provide the same aggregation level as the one proposed in this document.=20 =A0 Unlike implementation-specific behaviors, this proposal is deterministic since it is fully controlled by the entity which has the full knowledge = of prefix related states and network policies: e.g., the server has the knowledge of prefix assignment, prefix assignment policies, prefix aggregates, etc. =A0 =A0 I confirm this option is not a per-customer configuration parameter. =A0 Cheers, Med =A0 =A0 De=A0: Roberta Maglione [mailto:robmgl.ietf@gmail.com]=20 Envoy=E9=A0: jeudi 22 ao=FBt 2013 22:31 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: Ralph Droms; dhcwg@ietf.org WG Objet=A0: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? =A0 Hello, Maybe I=92m missing something here, but I=92m struggling to see the = value added by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure = on the router a summary/aggregate route and I announce it into the routing protocol. Moving to IPv6 you could do the same thing, I don=92t quite = get what=92s wrong with that? You say you would like to have an automatic way to tell the PE to = aggregate the routes, but if I understand correctly the proposal what you are = doing here is only moving the configuration of the summary route from the PE = to the DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, = it would be per box or per service configuration so why do you want to add = it to customers=92 profile in DCHPv6 Server? Thanks Roberta =A0 On Thu, Aug 22, 2013 at 9:45 AM, wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to trigger route advertisement actions and to control the route aggregates = to be injected using a routing protocol. For example, a router can be told = by the DHCP server to advertise an aggregate even if not all individual prefixes are assigned to customer located behind that router. This is a measure that can help in optimizing routing tables and avoid injecting = very specific routes. Snooping the assignment and then guide the route advertisement actions may not be lead to the same optimized routing = tables, because there will be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part de >Ralph Droms >Envoy=E9=A0: jeudi 22 ao=FBt 2013 14:48 >=C0=A0: Alexandru Petrescu >Cc=A0: dhcwg@ietf.org WG >Objet=A0: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the = DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP = must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more = about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have >been aimed at the same problem. =A0If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to = the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] = Anyone >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =A0 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Fri Aug 23 06:16:44 2013 Return-Path: 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 5042A11E81BE for ; Fri, 23 Aug 2013 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vIXUcjzh0CH for ; Fri, 23 Aug 2013 06:16:43 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAE11E81B7 for ; Fri, 23 Aug 2013 06:16:43 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so671953pbc.3 for ; Fri, 23 Aug 2013 06:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=gw9d67YG7I9USXqCFWJ+EUeT15y2XXcKK/f0AKgMNAU=; b=iMKIAtQA09SwkA1oqH0b1fq4i2VjUqy/4yGG/nrEN7gqJ5xUPZclJgsD24m9b3uwgW wSSoRj4BGQwr6OUVM8vUEW5Jhkuq67Gg6RNd+haEmylT+fuaTu+svybx1D/619GuV487 IW5XZ9i2PSIwpM2lrZO9n7ArEKZCwf0g5zhQ0jGVHPMLjC2dgKM5MMtNK359WmQFjUbi RRUrA68wSUVqX28V50YdpBgZXxJWHzUdZZbRWDY0MPIKxtPY7eEA37kfBqfB1XYhrcEb Z+HqCI09itCwxeYRZwPisOILS6pNzu0ptkvJwr+iyI1P12h1/ThRLLx6lGPFx/zmw5Em NHQg== X-Received: by 10.66.228.38 with SMTP id sf6mr21067385pac.21.1377263802759; Fri, 23 Aug 2013 06:16:42 -0700 (PDT) Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id oj6sm1059013pab.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:16:41 -0700 (PDT) From: "Leaf Yeh" To: , References: <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> <20130823.141844.74728418.sthaug@nethelp.no> In-Reply-To: <20130823.141844.74728418.sthaug@nethelp.no> Date: Fri, 23 Aug 2013 21:16:34 +0800 Message-ID: <521760b9.2683420a.5c2f.36fc@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6f+vFXymVeN2eXTeaNivJYeYUd/QABqQOA Content-Language: zh-cn Cc: dhcwg@ietf.org, rdroms.ietf@gmail.com Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 13:16:44 -0000 Steinar - I would be very uncomfortable with, and probably would not want to use, DHCP options which would let the DHCP server control address allocation without any kind of preconfiguration on the router. What kind of preconfiguration on the router you need ? Pls. read my reply to Bernie's question. OPTION_PREFIX_POOL defined in this draft just help your relay to know which pool your customer's prefix are from, and this information could help your router to do the dynamic route aggregation, which sounds your need on your PE router. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of sthaug@nethelp.no Sent: Friday, August 23, 2013 8:19 PM To: volz@cisco.com Cc: dhcwg@ietf.org; rdroms.ietf@gmail.com Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? > BTW - I think I may have indicated this before, but does this really avoid the need for configuration on the router (relay)? How are items such as the link-address and next hop (dhcp server) addresses configured (rfc 3315 has a multicast default)? So there is still a bunch of "manual" configuration required? Admittedly you do say "more automation" but not really sure that has a lot of value - perhaps we need a Dynamic Router Configuration BOF? As an operator I would prefer DHCPv6 to work similarly to DHCPv4 in a typical scenario of: - Large pools are explicitly configured on routers (relay agents). - DHCP server is allowed to hand out addresses *within these pools*. - Routers (relay agents) use information in the relayed DHCP packets to build up some state (for instance making it possible to invalidate the IP address when the lease expires). Thus the DHCP server has a *limited* amount of freedom to hand out IP within pools already known by the routers. I would be very uncomfortable with, and probably would not want to use, DHCP options which would let the DHCP server control address allocation without any kind of preconfiguration on the router. Steinar Haug, AS 2116 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Fri Aug 23 07:48:46 2013 Return-Path: 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 EC12811E80E6 for ; Fri, 23 Aug 2013 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlH4wQU8vBRi for ; Fri, 23 Aug 2013 07:48:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 53BB511E80D3 for ; Fri, 23 Aug 2013 07:48:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7NEmdLW013693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Aug 2013 16:48:39 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7NEmdrV025586 for ; Fri, 23 Aug 2013 16:48:39 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7NEmSVr027747 for ; Fri, 23 Aug 2013 16:48:39 +0200 Message-ID: <5217763C.8010702@gmail.com> Date: Fri, 23 Aug 2013 16:48:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> In-Reply-To: <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:48:47 -0000 Le 23/08/2013 14:29, Leaf Yeh a écrit : [...] > That sounds a new chapter of this draft. I suspect I will have a chance to > join. :-) LOL :-) What would be the toc of this DHCPv6 Prefix Delegation and Relay Problem Statement? Alex > > > Best Regards, > Leaf > > > > ---------------------------------------------------------------------------- > ------------------------------------------------------------ > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Bernie Volz (volz) > Sent: Friday, August 23, 2013 7:20 PM > To: mohamed.boucadair@orange.com > Cc: Ralph Droms; dhcwg@ietf.org WG > Subject: Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > BTW - I think I may have indicated this before, but does this really avoid > the need for configuration on the router (relay)? How are items such as the > link-address and next hop (dhcp server) addresses configured (rfc 3315 has a > multicast default)? So there is still a bunch of "manual" configuration > required? Admittedly you do say "more automation" but not really sure that > has a lot of value - perhaps we need a Dynamic Router Configuration BOF? > > - Bernie (from iPad) > > On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" > wrote: > Hi Roberta, > > Yes, as indicated in the document, manual configuration is an option. but it > has its limits too. > > This proposal is a contribution to add more automation to network > configuration without requiring an additional dynamic protocol to drive how > aggregates are built in a router co-located with a requestor, and therefore > interact in a more dynamic fashion with a routing protocol (e.g., drive > route withdrawals, etc.). > > Of course, some routers can offer some features to optimize the size of > routing tables and prevent from injecting (very) specific entries. But still > this behavior is implementation-specific and does not provide the same > aggregation level as the one proposed in this document. > > Unlike implementation-specific behaviors, this proposal is deterministic > since it is fully controlled by the entity which has the full knowledge of > prefix related states and network policies: e.g., the server has the > knowledge of prefix assignment, prefix assignment policies, prefix > aggregates, etc. > > I confirm this option is not a per-customer configuration parameter. > > Cheers, > Med > > > De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] > Envoyé : jeudi 22 août 2013 22:31 > À : BOUCADAIR Mohamed IMT/OLN > Cc : Ralph Droms; dhcwg@ietf.org WG > Objet : Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Hello, > Maybe I'm missing something here, but I'm struggling to see the value added > by this new option in terms of route aggregation functionality. > Today with IPv4 if I need to summarize some routes I manually configure on > the router a summary/aggregate route and I announce it into the routing > protocol. Moving to IPv6 you could do the same thing, I don't quite get > what's wrong with that? > You say you would like to have an automatic way to tell the PE to aggregate > the routes, but if I understand correctly the proposal what you are doing > here is only moving the configuration of the summary route from the PE to > the DHCPv6 Server; what do you really save here? > In addition the route aggregation is not a per customer configuration, it > would be per box or per service configuration so why do you want to add it > to customers' profile in DCHPv6 Server? > Thanks > Roberta > > On Thu, Aug 22, 2013 at 9:45 AM, wrote: > Re-, > > IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same > objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. > > draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to > trigger route advertisement actions and to control the route aggregates to > be injected using a routing protocol. For example, a router can be told by > the DHCP server to advertise an aggregate even if not all individual > prefixes are assigned to customer located behind that router. This is a > measure that can help in optimizing routing tables and avoid injecting very > specific routes. Snooping the assignment and then guide the route > advertisement actions may not be lead to the same optimized routing tables, > because there will be "holes" that will prevent aggregating routes. > > Having an explicit channel like the one specified in > draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. > > Cheers, > Med > > >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de >> Ralph Droms >> Envoyé : jeudi 22 août 2013 14:48 >> À : Alexandru Petrescu >> Cc : dhcwg@ietf.org WG >> Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >> prefix-pool-opt? >> >> >> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >> wrote: >> >>> Hi, >>> >>> One point I think is essential is the installment of routes in the DHCP >>> Relay upon Prefix Assignment. >>> >>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >>> install a route in the DHCP Relay upon delegation. >>> >>> This draft seems to at least assume it, and to describe much more about >>> it: how various parts of assigned prefixes are aggregated and >> communicated. >>> >>> I support it. >> >> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >> been aimed at the same problem. If I have that right, it might be >> instructive to review the dhc WG mailing list discussion that lead to the >> abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. >> >> - Ralph >> >>> >>> Alex >>> >>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a écrit : >>>> Hi Tomek, >>>> >>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>>> useful feature in order to have more automation and also control >>>> routes aggregation instead of relying on proprietary behaviors of >>>> each implementation. Of course, part of these objectives can be >>>> achieved if routes are installed manually or use an out of band >>>> mechanism to enforce routing aggregation policies. Still, the >>>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>>> because the DHCP server has the knowledge of the prefix assignments; >>>> and therefore routes can be triggered with dhcpv6 . >>>> >>>> A way to progress with this document is to target the Experimental >>>> track. Based on the experience that will be gained in real >>>> deployments, the status can be revisited if required. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>>> Envoyé : lundi 19 août 2013 16:52 À : dhcwg Objet : [dhcwg] Anyone >>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>> >>>>> During Berlin meeting chairs asked if there is still interest in >>>>> the prefix-pool-option. There was nobody interested in the work in >>>>> the room. The unanimous consensus in the room was to drop it. I >>>>> just wanted to confirm that on the list. >>>>> >>>>> If you are interested in this work, want to support it and >>>>> participate in it, please let us know by replying to the mailing >>>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>>> WG document. >>>>> >>>>> Please respond within 2 weeks (until Sep. 2nd). >>>>> >>>>> Bernie & Tomek _______________________________________________ >>>>> dhcwg mailing list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> _______________________________________________ dhcwg mailing list >>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>>> >>> >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > From robmgl.ietf@gmail.com Fri Aug 23 11:51:47 2013 Return-Path: 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 5B29811E80F3 for ; Fri, 23 Aug 2013 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmRSDOSJbH0G for ; Fri, 23 Aug 2013 11:51:45 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 891A311E8107 for ; Fri, 23 Aug 2013 11:51:41 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id r10so775741lbi.1 for ; Fri, 23 Aug 2013 11:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HJFgr+AaRiyDr36wKIeD45sM7gGCc5BfZtgGrqQwRPo=; b=Hl0KKnUvNb+kzYV2i8cWY33wnRtvYrcWA9Fe7HjDzd1wai3KWJ0T/hb0UEfSjFblji +SezqjgyZHvRwQypZVhQxOYSi8Pk6AA7LnbicM7TIT0jCJg/sh+LVy1anCWlIynM2Vch VI9BvQ3cwT9WmyHOwn0BHx1ZpytAx5V5rD6tTAFUCSNllgMSa5JXKpMJOXNFhfSNEGS8 vS3syzhBvRMWJbO7C9nq1XiHsrC1Vc1aCTB+TJEc9D7Qx2ZkVxgAaYjY7sY4Vx28OprF ewcxdvI00Ju6MpvoufxBC6iYWu+EXHTpcb0wh6Sy3ZMTExp9bUd7OqbUyrQg6dJb9rjX JwKA== MIME-Version: 1.0 X-Received: by 10.112.200.228 with SMTP id jv4mr225755lbc.44.1377283895753; Fri, 23 Aug 2013 11:51:35 -0700 (PDT) Received: by 10.112.30.203 with HTTP; Fri, 23 Aug 2013 11:51:35 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Aug 2013 14:51:35 -0400 Message-ID: From: Roberta Maglione To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a11c389d85c821204e4a1e546 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 18:51:47 -0000 --001a11c389d85c821204e4a1e546 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med, Leaf, I fully understand the requirement for network automation versus manual configuration, but I still don=92t think defining a new dhcp option is the right direction to go in order to do routes aggregations in a router. As somebody else already pointed out here, if you need a way to automatically interact with the router i2rs is the right place to discuss your requirements. In addition you said: =D8 I confirm this option is not a per-customer configuration parameter. If it is not a per-client configuration why would you like to use DHCP for that? I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I=92m wrong, is that the DHCP Server provides a per-client configuration. How would it work with this new option? How does the DHCP Server know if it has to add or not this option if it is not based on client profile or on client request? Do you plan to insert the option in all the DHCP Server replies/to all clients? I assume the router is going to install the route once and what does it do if it gets the same routes more the one? Just ignore? It seems like a waste of cycles on the router. In my opinion having global parameters on DHCP Server seems a major change in the DHCP model. Thanks Roberta On Fri, Aug 23, 2013 at 2:15 AM, wrote: > Hi Roberta,**** > > ** ** > > Yes, as indicated in the document, manual configuration is an option=85 b= ut > it has its limits too. **** > > ** ** > > This proposal is a contribution to add more automation to network > configuration without requiring an additional dynamic protocol to drive h= ow > aggregates are built in a router co-located with a requestor, and therefo= re > interact in a more dynamic fashion with a routing protocol (e.g., drive > route withdrawals, etc.). **** > > ** ** > > Of course, some routers can offer some features to optimize the size of > routing tables and prevent from injecting (very) specific entries. But > still this behavior is implementation-specific and does not provide the > same aggregation level as the one proposed in this document. **** > > ** ** > > Unlike implementation-specific behaviors, this proposal is deterministic > since it is fully controlled by the entity which has the full knowledge o= f > prefix related states and network policies: e.g., the server has the > knowledge of prefix assignment, prefix assignment policies, prefix > aggregates, etc. **** > > ** ** > > I confirm this option is not a per-customer configuration parameter.**** > > ** ** > > Cheers,**** > > Med**** > > ** ** > > ** ** > > *De :* Roberta Maglione [mailto:robmgl.ietf@gmail.com] > *Envoy=E9 :* jeudi 22 ao=FBt 2013 22:31 > *=C0 :* BOUCADAIR Mohamed IMT/OLN > *Cc :* Ralph Droms; dhcwg@ietf.org WG > > *Objet :* Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt?**** > > ** ** > > Hello,**** > > Maybe I=92m missing something here, but I=92m struggling to see the value > added by this new option in terms of route aggregation functionality.**** > > Today with IPv4 if I need to summarize some routes I manually configure o= n > the router a summary/aggregate route and I announce it into the routing > protocol. Moving to IPv6 you could do the same thing, I don=92t quite get > what=92s wrong with that?**** > > You say you would like to have an automatic way to tell the PE to > aggregate the routes, but if I understand correctly the proposal what you > are doing here is only moving the configuration of the summary route from > the PE to the DHCPv6 Server; what do you really save here?**** > > In addition the route aggregation is not a per customer configuration, it > would be per box or per service configuration so why do you want to add i= t > to customers=92 profile in DCHPv6 Server?**** > > Thanks**** > > Roberta**** > > ** ** > > On Thu, Aug 22, 2013 at 9:45 AM, wrote:***= * > > Re-, > > IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same > objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. > > draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to > trigger route advertisement actions and to control the route aggregates t= o > be injected using a routing protocol. For example, a router can be told b= y > the DHCP server to advertise an aggregate even if not all individual > prefixes are assigned to customer located behind that router. This is a > measure that can help in optimizing routing tables and avoid injecting ve= ry > specific routes. Snooping the assignment and then guide the route > advertisement actions may not be lead to the same optimized routing table= s, > because there will be "holes" that will prevent aggregating routes. > > Having an explicit channel like the one specified in > draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO.**** > > > Cheers, > Med > > > >-----Message d'origine----- > >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e > **** > > >Ralph Droms > >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 > >=C0 : Alexandru Petrescu > >Cc : dhcwg@ietf.org WG > >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6- > **** > > >prefix-pool-opt? > > > > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > > wrote: > > > >> Hi, > >> > >> One point I think is essential is the installment of routes in the DHC= P > >> Relay upon Prefix Assignment. > >> > >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP mus= t > >> install a route in the DHCP Relay upon delegation. > >> > >> This draft seems to at least assume it, and to describe much more abou= t > >> it: how various parts of assigned prefixes are aggregated and > >communicated. > >> > >> I support it. > > > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to hav= e > >been aimed at the same problem. If I have that right, it might be > >instructive to review the dhc WG mailing list discussion that lead to th= e > >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > > > >- Ralph > > > >> > >> Alex > >> > >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : > >>> Hi Tomek, > >>> > >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a > >>> useful feature in order to have more automation and also control > >>> routes aggregation instead of relying on proprietary behaviors of > >>> each implementation. Of course, part of these objectives can be > >>> achieved if routes are installed manually or use an out of band > >>> mechanism to enforce routing aggregation policies. Still, the > >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior > >>> because the DHCP server has the knowledge of the prefix assignments; > >>> and therefore routes can be triggered with dhcpv6 . > >>> > >>> A way to progress with this document is to target the Experimental > >>> track. Based on the experience that will be gained in real > >>> deployments, the status can be revisited if required. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org > >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski > >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] An= yone > >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? > >>>> > >>>> During Berlin meeting chairs asked if there is still interest in > >>>> the prefix-pool-option. There was nobody interested in the work in > >>>> the room. The unanimous consensus in the room was to drop it. I > >>>> just wanted to confirm that on the list. > >>>> > >>>> If you are interested in this work, want to support it and > >>>> participate in it, please let us know by replying to the mailing > >>>> list. Otherwise we'll drop this work and mark that draft as a dead > >>>> WG document. > >>>> > >>>> Please respond within 2 weeks (until Sep. 2nd). > >>>> > >>>> Bernie & Tomek _______________________________________________ > >>>> dhcwg mailing list dhcwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dhcwg > >>> _______________________________________________ dhcwg mailing list > >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > >>> > >>> > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg**** > > ** ** > --001a11c389d85c821204e4a1e546 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Med, Leaf,

I fully understand the requirement for network = automation versus manual configuration, but I still don=92t think defining a new dhcp = option is the right direction to go in order to do routes aggregations in a router= .

As somebody else already pointed out here, if y= ou need a way to automatically interact with the router i2rs is the right place to discus= s your requirements.

In addition you said:

<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

=D8=A0 I confirm this option is not a per= -customer configuration parameter.

=A0If it is not a per-client confi= guration why =A0would you like to use DHCP for that?

I understand that in DHCP Server there are alre= ady some global parameters like the pool of addresses=A0to be used for the clients, = but my understanding of DHCP behavior , and please correct me if I=92m wrong, is t= hat the DHCP Server provides a per-client configuration.

How would it work with this new option? How doe= s the DHCP Server know if it has to add or not this option if it is not based on clien= t profile or on client request?

Do you plan to=A0insert the option in all =A0the DHCP Server replies/to all clients?

I assume the router is going to install the rou= te once and what does it do if it gets the same routes more the one? Just ignore? It se= ems like a waste of cycles on the router.

In my opinion=A0having global parameters on DHC= P Server seems=A0 a major change in the DHCP model.

Thanks

Roberta



= On Fri, Aug 23, 2013 at 2:15 AM, <mohamed.boucadair@orange.com= > wrote:

Hi Roberta,

=A0

Yes, as indicated in the document, manual configur= ation is an option=85 but it has its limits too.

=A0

This proposal is a contribution to add more automa= tion to network configuration without requiring an additional dynamic proto= col to drive how aggregates are built in a router co-located with a request= or, and therefore interact in a more dynamic fashion with a routing protoco= l (e.g., drive route withdrawals, etc.).

=A0

Of course, some routers can offer some features to= optimize the size of routing tables and prevent from injecting (very) spec= ific entries. But still this behavior is implementation-specific and does n= ot provide the same aggregation level as the one proposed in this document.=

=A0

Unlike implementation-specific behaviors, this pro= posal is deterministic since it is fully controlled by the entity which has= the full knowledge of prefix related states and network policies: e.g., th= e server has the knowledge of prefix assignment, prefix assignment policies= , prefix aggregates, etc. =A0

=A0

I confirm this option is not a per-customer config= uration parameter.

=A0

Cheers,

Med

=A0

=A0

De=A0: Rober= ta Maglione [mailto:robmgl.ietf@gmail.com]
Envoy=E9=A0: jeudi 22 ao=FBt 2013 22:31
=C0=A0: BOUCADAIR Mohamed IMT/OLN
Cc=A0: Ralph Droms; = dhcwg@ietf.org WG


Objet=A0: Re: [dhcwg] Anyone interested in con= tinuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

=

= =A0

Hello,

Maybe I=92m missing something here, but I=92m struggling t= o see the value added by this new option in terms of route aggregation func= tionality.

Today with IPv4 if I need to summarize some rou= tes I manually configure on the router a summary/aggregate route and I anno= unce it into the routing protocol. Moving to IPv6 you could do the same thi= ng, I don=92t quite get what=92s wrong with that?

You say you would like to have an automatic way= to tell the PE to aggregate the routes, but if I understand correctly the = proposal what you are doing here is only moving the configuration of the su= mmary route from the PE to the DHCPv6 Server; what do you really save here?=

In addition the route aggregation is not a per = customer configuration, it would be per box or per service configuration so= why do you want to add it to customers=92 profile in DCHPv6 Server?=

Thanks

Roberta

=A0

On Thu, Aug 22, 2013 at 9:45 AM, <<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com> wrote:

Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-del= egate does not cover the same objectives as in draft-ietf-dhc-dhcpv6-prefix= -pool-opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a d= ynamic means to trigger route advertisement actions and to control the rout= e aggregates to be injected using a routing protocol. For example, a router= can be told by the DHCP server to advertise an aggregate even if not all i= ndividual prefixes are assigned to customer located behind that router. Thi= s is a measure that can help in optimizing routing tables and avoid injecti= ng very specific routes. Snooping the assignment and then guide the route a= dvertisement actions may not be lead to the same optimized routing tables, = because there will be "holes" that will prevent aggregating route= s.

Having an explicit channel like the one specified in draft-ietf-dhc-dhc= pv6-prefix-pool-opt is superior IMHO.


Cheers,
Med


>-----Message d'origine----- >De=A0: dhcw= g-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de

=

>Ralph Droms
>Envoy=E9=A0: jeudi 22 ao=FBt = 2013 14:48
>=C0=A0: Alexandru Petrescu
>Cc=A0: dhcwg@ietf.org WG
>Objet=A0: = Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-

>prefix-pool-opt?
>
>
&g= t;On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
><alexandru.petre= scu@gmail.com> wrote:
>
>> Hi,
>>
>> One point I think is essential= is the installment of routes in the DHCP
>> Relay upon Prefix Ass= ignment.
>>
>> The base DHCPv6 Prefix Delegation RFC does= not stipulate that DHCP must
>> install a route in the DHCP Relay upon delegation.
>>
= >> This draft seems to at least assume it, and to describe much more = about
>> it: how various parts of assigned prefixes are aggregated= and
>communicated.
>>
>> I support it.
>
>Afte= r a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have
&g= t;been aimed at the same problem. =A0If I have that right, it might be
>instructive to review the dhc WG mailing list discussion that lead to t= he
>abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
>>- Ralph
>
>>
>> Alex
>>
>> = Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit :
>>> Hi Tomek,
>>>
>>> I do still think dra= ft-ietf-dhc-dhcpv6-prefix-pool-opt documents a
>>> useful featu= re in order to have more automation and also control
>>> routes= aggregation instead of relying on proprietary behaviors of
>>> each implementation. Of course, part of these objectives can b= e
>>> achieved if routes are installed manually or use an out o= f band
>>> mechanism to enforce routing aggregation policies. S= till, the
>>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior<= br>>>> because the DHCP server has the knowledge of the prefix ass= ignments;
>>> and therefore routes can be triggered with dhcpv6= .
>>>
>>> A way to progress with this document is to tar= get the Experimental
>>> track. Based on the experience that wi= ll be gained in real
>>> deployments, the status can be revisit= ed if required.
>>>
>>> Cheers, Med
>>>
>>>>= ; -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mai= lto:dhcwg-bounc= es@ietf.org] De la part de Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : = [dhcwg] Anyone
>>>> interested in continuing draft-ietf-dhc-= dhcpv6- prefix-pool-opt?
>>>>
>>>> During Ber= lin meeting chairs asked if there is still interest in
>>>> the prefix-pool-option. There was nobody interested in the= work in
>>>> the room. The unanimous consensus in the room = was to drop it. I
>>>> just wanted to confirm that on the li= st.
>>>>
>>>> If you are interested in this work, wa= nt to support it and
>>>> participate in it, please let us k= now by replying to the mailing
>>>> list. Otherwise we'l= l drop this work and mark that draft as a dead
>>>> WG document.
>>>>
>>>> Pleas= e respond within 2 weeks (until Sep. 2nd).
>>>>
>>&= gt;> Bernie & Tomek _______________________________________________<= br> >>>> dhcwg mailing list dhcwg@ietf.org
>>>> https://www.ietf.org/mai= lman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing = list
>>> dh= cwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>> __________= _____________________________________
>> dhcwg mailing list
>= ;> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>____= ___________________________________________
>dhcwg mailing list
&g= t;dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg
_____________________= __________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

=A0

=

--001a11c389d85c821204e4a1e546-- From leaf.yeh.sdo@gmail.com Sun Aug 25 08:52:07 2013 Return-Path: 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 4501321F9D46 for ; Sun, 25 Aug 2013 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60QUBk7bSsGC for ; Sun, 25 Aug 2013 08:52:06 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E51D321F9D35 for ; Sun, 25 Aug 2013 08:52:05 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so2495375pdj.40 for ; Sun, 25 Aug 2013 08:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=jkmx+KF7ldso36O63Mn6LYKsHy45W6e+Ku7wGoLJgmA=; b=mtjd4aco52SoQY8rO6mxDYpyHhaz/L9kZGuaT2sWeTjNrd7EdnDH6ci3sXKhaxYULg K8UXG689x9zDyd3kzP/Wal6juanQDTqFpnH8fveLF6nHqIns8DOxQtyPlEuCVv90byPQ u/LpPBJlhHeKxvlzcNsPqtCV3o+ng8wiJdnmLW9JeTwEje9Z8/FAL3+V4Gbe64mtK3jx +mUsYr6dadQWC4BTK6PhTlnjItfcSAwNOkF2fiLp3smvQKGSbOp3cIc0nIwSlzZBCUeC K0ej4ihH/BWbd6AXyrktU3fz8LEgv274tD3b/XV1kZNv0Fh+rr+lZIXeDjH5QjJT6q8U h5Sg== X-Received: by 10.68.135.101 with SMTP id pr5mr892188pbb.196.1377445925588; Sun, 25 Aug 2013 08:52:05 -0700 (PDT) Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id yg1sm12605031pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Aug 2013 08:52:04 -0700 (PDT) From: "Leaf Yeh" To: "'Roberta Maglione'" , References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Sun, 25 Aug 2013 23:51:54 +0800 Message-ID: <521a2824.41a3440a.1475.4b84@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6gMdlP7dDUrXHAQFydxeaL3b9KSwAAbO9Q Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ralph Droms' Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:52:07 -0000 Roberta - I understand that in DHCP Server there are already some global = parameters like the pool of addresses to be used for the clients, but my = understanding of DHCP behavior , and please correct me if I=E2=80=99m = wrong, is that the DHCP Server provides a per-client configuration. Not sure you have interest to read draft (RAAN, = draft-ietf-dhc-dhcpv6-agentopt-delegate) again.=20 I believe Bernie (or Tomek) have better answer for this question. Roberta - How would it work with this new option? How does the DHCP = Server know if it has to add or not this option if it is not based on = client profile or on client request? The OPTION_PREFIX_POOL will be included in the Relay-Reply message for = DHCPv6-PD Reply to the clients.=20 Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam. Roberta - Do you plan to insert the option in all the DHCP Server = replies/to all clients?=20 Yes, almost every Relay-Reply message for Reply to the clients as = described in the draft.=20 Roberta - I assume the router is going to install the route once and = what does it do if it gets the same routes more the one? Just ignore?=20 Read the draft, keep in mind you have a smart PE with strong CPU. :-) Roberta - It seems like a waste of cycles on the router. The OPTION_PREFIX_POOL proposed by the draft to include in the = Relay-Reply message is not more than 22 bytes with a fixed format.=20 Your concern here sounds not a problem. Roberta - In my opinion having global parameters on DHCP Server seems a = major change in the DHCP model. The DHCPv6 server already has the =E2=80=98global parameters=E2=80=99, = such as the prefix pool =E2=80=A6 as you mentioned above.=20 The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) = capability of DHCPv6 server. Pls. read my last reply mail to you & Med's = mail again.=20 The solution with a newly defined option is a solution we thought with a = minimal protocol change.=20 New capability from the new protocol design do need a little change on = your habit for the employment in your deployment. Best Regards, Leaf -------------------------------------------------------------------------= --------------------------------------------------------------- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Roberta Maglione Sent: Saturday, August 24, 2013 2:52 AM To: mohamed.boucadair@orange.com Cc: dhcwg@ietf.org WG; Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? Hi Med, Leaf, I fully understand the requirement for network automation versus manual = configuration, but I still don=E2=80=99t think defining a new dhcp = option is the right direction to go in order to do routes aggregations = in a router.=20 As somebody else already pointed out here, if you need a way to = automatically interact with the router i2rs is the right place to = discuss your requirements. In addition you said: =E2=9E=A2 I confirm this option is not a per-customer configuration = parameter. If it is not a per-client configuration why would you like to use DHCP = for that? I understand that in DHCP Server there are already some global = parameters like the pool of addresses to be used for the clients, but my = understanding of DHCP behavior , and please correct me if I=E2=80=99m = wrong, is that the DHCP Server provides a per-client configuration. How would it work with this new option? How does the DHCP Server know if = it has to add or not this option if it is not based on client profile or = on client request? Do you plan to insert the option in all the DHCP Server replies/to all = clients?=20 I assume the router is going to install the route once and what does it = do if it gets the same routes more the one? Just ignore? It seems like a = waste of cycles on the router. In my opinion having global parameters on DHCP Server seems a major = change in the DHCP model. Thanks Roberta On Fri, Aug 23, 2013 at 2:15 AM, wrote: Hi Roberta, =20 Yes, as indicated in the document, manual configuration is an = option=E2=80=A6 but it has its limits too.=20 =20 This proposal is a contribution to add more automation to network = configuration without requiring an additional dynamic protocol to drive = how aggregates are built in a router co-located with a requestor, and = therefore interact in a more dynamic fashion with a routing protocol = (e.g., drive route withdrawals, etc.).=20 =20 Of course, some routers can offer some features to optimize the size of = routing tables and prevent from injecting (very) specific entries. But = still this behavior is implementation-specific and does not provide the = same aggregation level as the one proposed in this document.=20 =20 Unlike implementation-specific behaviors, this proposal is deterministic = since it is fully controlled by the entity which has the full knowledge = of prefix related states and network policies: e.g., the server has the = knowledge of prefix assignment, prefix assignment policies, prefix = aggregates, etc. =20 =20 I confirm this option is not a per-customer configuration parameter. =20 Cheers, Med =20 =20 De : Roberta Maglione [mailto:robmgl.ietf@gmail.com]=20 Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 22:31 =C3=80 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? =20 Hello, Maybe I=E2=80=99m missing something here, but I=E2=80=99m struggling to = see the value added by this new option in terms of route aggregation = functionality. Today with IPv4 if I need to summarize some routes I manually configure = on the router a summary/aggregate route and I announce it into the = routing protocol. Moving to IPv6 you could do the same thing, I = don=E2=80=99t quite get what=E2=80=99s wrong with that? You say you would like to have an automatic way to tell the PE to = aggregate the routes, but if I understand correctly the proposal what = you are doing here is only moving the configuration of the summary route = from the PE to the DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, = it would be per box or per service configuration so why do you want to = add it to customers=E2=80=99 profile in DCHPv6 Server? Thanks Roberta =20 On Thu, Aug 22, 2013 at 9:45 AM, wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same = objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to = trigger route advertisement actions and to control the route aggregates = to be injected using a routing protocol. For example, a router can be = told by the DHCP server to advertise an aggregate even if not all = individual prefixes are assigned to customer located behind that router. = This is a measure that can help in optimizing routing tables and avoid = injecting very specific routes. Snooping the assignment and then guide = the route advertisement actions may not be lead to the same optimized = routing tables, because there will be "holes" that will prevent = aggregating routes. Having an explicit channel like the one specified in = draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part = de >Ralph Droms >Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 14:48 >=C3=80 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the = DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP = must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more = about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to = the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =C3=A9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>> Envoy=C3=A9 : lundi 19 ao=C3=BBt 2013 16:52 =C3=80 : dhcwg Objet : = [dhcwg] Anyone >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 From robmgl.ietf@gmail.com Sun Aug 25 15:04:28 2013 Return-Path: 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 61C4411E80F2 for ; Sun, 25 Aug 2013 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NkfAbVOQJcL for ; Sun, 25 Aug 2013 15:04:26 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F111211E80D5 for ; Sun, 25 Aug 2013 15:04:19 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id r11so880829lbi.18 for ; Sun, 25 Aug 2013 15:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m2cFVK69MYSYAkoCG3QxPRcz5x2EP2voCi884Sms70M=; b=YseXBrhIvz8mZhtKrKt1+Jh7n3ZxGJhy1HXdkQiMK6DTn0M/Z40WMIA9t9FUSWnlgE h0on6nWveDXXH+BfgHo9EgnaCoPn+FlwOCJaoZm9i6pZ14pZWjx06atGGY7C1JFCW+Se EY2oM5NKSa+qv17Wnt0/23UTy435+FRrcZzvlhNUZDp8Nl42/XIXts4kTVeIIwzq4G9s DxrsCdIdlYpItIB+CG1D/qvibkhTNB+jMVxw+BhlPZvZHhYQ8uh31voF9ZhMsb/m8rJ2 cQLODoZgGb6p0kFnhiZa+jcgMMKYsFjkNt3Hmh6iaUf8yqpHqX3HImq6FxE0wGFY9e3a Gk/w== MIME-Version: 1.0 X-Received: by 10.152.8.12 with SMTP id n12mr10740756laa.10.1377468258782; Sun, 25 Aug 2013 15:04:18 -0700 (PDT) Received: by 10.112.30.203 with HTTP; Sun, 25 Aug 2013 15:04:18 -0700 (PDT) In-Reply-To: <521a2824.41a3440a.1475.4b84@mx.google.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <521a2824.41a3440a.1475.4b84@mx.google.com> Date: Sun, 25 Aug 2013 18:04:18 -0400 Message-ID: From: Roberta Maglione To: Leaf Yeh Content-Type: multipart/alternative; boundary=001a11c365b641120204e4ccd2f8 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 22:04:28 -0000 --001a11c365b641120204e4ccd2f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Leaf, thanks for your comments please see inline [RM] Best Regards Roberta On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh wrote: > > Not sure you have interest to read draft (RAAN, > draft-ietf-dhc-dhcpv6-agentopt-delegate) again. > I believe Bernie (or Tomek) have better answer for this question. > > [RM] The main difference here is that RAAN option was used to provide > per-client configuration/route while if I understand correctly your > proposal this option will be used to configure a per-box/per-relay route = or > per-group of users (per-service) route on the relay as both you and Med > confirmed. > Roberta - How would it work with this new option? How does the DHCP Serve= r > know if it has to add or not this option if it is not based on client > profile or on client request? > > The OPTION_PREFIX_POOL will be included in the Relay-Reply message for > DHCPv6-PD Reply to the clients. > Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam. > > > Roberta - Do you plan to insert the option in all the DHCP Server > replies/to all clients? > > Yes, almost every Relay-Reply message for Reply to the clients as > described in the draft. > > [RM] This is my point: you repeat the same option in every Relay-reply > message in order to do a one time/per-relay configuration in my opinion > this does not seem to be very efficient, but I may be wrong. > Roberta - I assume the router is going to install the route once and what > does it do if it gets the same routes more the one? Just ignore? > > Read the draft, keep in mind you have a smart PE with strong CPU. :-) > > > Roberta - It seems like a waste of cycles on the router. > > The OPTION_PREFIX_POOL proposed by the draft to include in the Relay-Repl= y > message is not more than 22 bytes with a fixed format. > Your concern here sounds not a problem. > > [RM] My point was not about the packet length, but more mode of > operation: you are asking the Relay to process multiple times the same > option in order to install a route that is already there. > Roberta - In my opinion having global parameters on DHCP Server seems a > major change in the DHCP model. > > The DHCPv6 server already has the =E2=80=98global parameters=E2=80=99, su= ch as the prefix > pool =E2=80=A6 as you mentioned above. > The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) > capability of DHCPv6 server. Pls. read my last reply mail to you & Med's > mail again. > The solution with a newly defined option is a solution we thought with a > minimal protocol change. > New capability from the new protocol design do need a little change on > your habit for the employment in your deployment. > > > > Best Regards, > Leaf > > > > > -------------------------------------------------------------------------= --------------------------------------------------------------- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Roberta Maglione > Sent: Saturday, August 24, 2013 2:52 AM > To: mohamed.boucadair@orange.com > Cc: dhcwg@ietf.org WG; Ralph Droms > Subject: Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Hi Med, Leaf, > I fully understand the requirement for network automation versus manual > configuration, but I still don=E2=80=99t think defining a new dhcp option= is the > right direction to go in order to do routes aggregations in a router. > As somebody else already pointed out here, if you need a way to > automatically interact with the router i2rs is the right place to discuss > your requirements. > In addition you said: > =E2=9E=A2 I confirm this option is not a per-customer configuration para= meter. > If it is not a per-client configuration why would you like to use DHCP > for that? > I understand that in DHCP Server there are already some global parameters > like the pool of addresses to be used for the clients, but my understandi= ng > of DHCP behavior , and please correct me if I=E2=80=99m wrong, is that th= e DHCP > Server provides a per-client configuration. > How would it work with this new option? How does the DHCP Server know if > it has to add or not this option if it is not based on client profile or = on > client request? > Do you plan to insert the option in all the DHCP Server replies/to all > clients? > I assume the router is going to install the route once and what does it d= o > if it gets the same routes more the one? Just ignore? It seems like a was= te > of cycles on the router. > In my opinion having global parameters on DHCP Server seems a major > change in the DHCP model. > Thanks > Roberta > > On Fri, Aug 23, 2013 at 2:15 AM, wrote: > Hi Roberta, > > Yes, as indicated in the document, manual configuration is an option=E2= =80=A6 but > it has its limits too. > > This proposal is a contribution to add more automation to network > configuration without requiring an additional dynamic protocol to drive h= ow > aggregates are built in a router co-located with a requestor, and therefo= re > interact in a more dynamic fashion with a routing protocol (e.g., drive > route withdrawals, etc.). > > Of course, some routers can offer some features to optimize the size of > routing tables and prevent from injecting (very) specific entries. But > still this behavior is implementation-specific and does not provide the > same aggregation level as the one proposed in this document. > > Unlike implementation-specific behaviors, this proposal is deterministic > since it is fully controlled by the entity which has the full knowledge o= f > prefix related states and network policies: e.g., the server has the > knowledge of prefix assignment, prefix assignment policies, prefix > aggregates, etc. > > I confirm this option is not a per-customer configuration parameter. > > Cheers, > Med > > > De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] > Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 22:31 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : Ralph Droms; dhcwg@ietf.org WG > > Objet : Re: [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Hello, > Maybe I=E2=80=99m missing something here, but I=E2=80=99m struggling to s= ee the value > added by this new option in terms of route aggregation functionality. > Today with IPv4 if I need to summarize some routes I manually configure o= n > the router a summary/aggregate route and I announce it into the routing > protocol. Moving to IPv6 you could do the same thing, I don=E2=80=99t qui= te get > what=E2=80=99s wrong with that? > You say you would like to have an automatic way to tell the PE to > aggregate the routes, but if I understand correctly the proposal what you > are doing here is only moving the configuration of the summary route from > the PE to the DHCPv6 Server; what do you really save here? > In addition the route aggregation is not a per customer configuration, it > would be per box or per service configuration so why do you want to add i= t > to customers=E2=80=99 profile in DCHPv6 Server? > Thanks > Roberta > > On Thu, Aug 22, 2013 at 9:45 AM, wrote: > Re-, > > IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same > objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. > > draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to > trigger route advertisement actions and to control the route aggregates t= o > be injected using a routing protocol. For example, a router can be told b= y > the DHCP server to advertise an aggregate even if not all individual > prefixes are assigned to customer located behind that router. This is a > measure that can help in optimizing routing tables and avoid injecting ve= ry > specific routes. Snooping the assignment and then guide the route > advertisement actions may not be lead to the same optimized routing table= s, > because there will be "holes" that will prevent aggregating routes. > > Having an explicit channel like the one specified in > draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. > > Cheers, > Med > > > >-----Message d'origine----- > >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e > >Ralph Droms > >Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 14:48 > >=C3=80 : Alexandru Petrescu > >Cc : dhcwg@ietf.org WG > >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6- > >prefix-pool-opt? > > > > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > > wrote: > > > >> Hi, > >> > >> One point I think is essential is the installment of routes in the DHC= P > >> Relay upon Prefix Assignment. > >> > >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP mus= t > >> install a route in the DHCP Relay upon delegation. > >> > >> This draft seems to at least assume it, and to describe much more abou= t > >> it: how various parts of assigned prefixes are aggregated and > >communicated. > >> > >> I support it. > > > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to hav= e > >been aimed at the same problem. If I have that right, it might be > >instructive to review the dhc WG mailing list discussion that lead to th= e > >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > > > >- Ralph > > > >> > >> Alex > >> > >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =C3=A9crit : > >>> Hi Tomek, > >>> > >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a > >>> useful feature in order to have more automation and also control > >>> routes aggregation instead of relying on proprietary behaviors of > >>> each implementation. Of course, part of these objectives can be > >>> achieved if routes are installed manually or use an out of band > >>> mechanism to enforce routing aggregation policies. Still, the > >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior > >>> because the DHCP server has the knowledge of the prefix assignments; > >>> and therefore routes can be triggered with dhcpv6 . > >>> > >>> A way to progress with this document is to target the Experimental > >>> track. Based on the experience that will be gained in real > >>> deployments, the status can be revisited if required. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org > >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski > >>>> Envoy=C3=A9 : lundi 19 ao=C3=BBt 2013 16:52 =C3=80 : dhcwg Objet : [= dhcwg] Anyone > >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? > >>>> > >>>> During Berlin meeting chairs asked if there is still interest in > >>>> the prefix-pool-option. There was nobody interested in the work in > >>>> the room. The unanimous consensus in the room was to drop it. I > >>>> just wanted to confirm that on the list. > >>>> > >>>> If you are interested in this work, want to support it and > >>>> participate in it, please let us know by replying to the mailing > >>>> list. Otherwise we'll drop this work and mark that draft as a dead > >>>> WG document. > >>>> > >>>> Please respond within 2 weeks (until Sep. 2nd). > >>>> > >>>> Bernie & Tomek _______________________________________________ > >>>> dhcwg mailing list dhcwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dhcwg > >>> _______________________________________________ dhcwg mailing list > >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > >>> > >>> > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > --001a11c365b641120204e4ccd2f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Leaf,
thanks for your comments please see inline [RM]
Best Regards
Roberta
<= br>
On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:

Not sure you have interest to read draft (RAAN, draft-ietf-dhc-dhcpv6-agent= opt-delegate) again.
I believe Bernie (or Tomek) have better answer for this question.

[RM] The main difference here is that RAAN option was used to provide p= er-client configuration/route while if I understand correctly your proposal= =C2=A0this option=C2=A0will be used to configure a per-box/per-relay route= =C2=A0or per-group of=C2=A0users (per-service) route on the relay as both y= ou and Med confirmed.=C2=A0

Roberta - How would it work with this new option? How does the DHCP Server = know if it has to add or not this option if it is not based on client profi= le or on client request?

The OPTION_PREFIX_POOL will be included in the Relay-Reply message for DHCP= v6-PD Reply to the clients.
Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam.


Roberta - Do you plan to insert the option in all =C2=A0the DHCP Server rep= lies/to all clients?

Yes, almost every Relay-Reply message for Reply to the clients as described= in the draft.

[RM]=C2=A0 This is my point: you repeat the same option in every Relay-= reply message=C2=A0 in order to do a one time/per-relay configuration in my= opinion this does not seem to be=C2=A0very efficient, but I may be wrong.= =C2=A0
=C2=A0

Roberta - I assume the router is going to install the route once and what d= oes it do if it gets the same routes more the one? Just ignore?

Read the draft, keep in mind you have a smart PE with strong CPU. :-)


Roberta - It seems like a waste of cycles on the router.

The OPTION_PREFIX_POOL proposed by the draft to include in the Relay-Reply = message is not more than 22 bytes with a fixed format.
Your concern here sounds not a problem.

[RM]=C2=A0My point=C2=A0was=C2=A0=C2=A0not about the packet=C2=A0length= , but more=C2=A0mode of operation: you are=C2=A0asking the Relay to process= multiple times the same option in order to install a route that is already= there.=C2=A0=C2=A0=C2=A0

Roberta - In my opinion having global parameters on DHCP Server seems =C2= =A0a major change in the DHCP model.

The DHCPv6 server already has the =E2=80=98global parameters=E2=80=99, such= as the prefix pool =E2=80=A6 as you mentioned above.
The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) capa= bility of DHCPv6 server. Pls. read my last reply mail to you & Med'= s mail again.
The solution with a newly defined option is a solution we thought with a mi= nimal protocol change.
New capability from the new protocol design do need a little change on your= habit for the employment in your deployment.

=C2=A0


Best Regards,
Leaf



---------------------------------------------------------------------------= -------------------------------------------------------------
From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Roberta Maglione
Sent: Saturday, August 24, 2013 2:52 AM
To: moham= ed.boucadair@orange.com
Cc: dhcwg@ietf.org WG; Ralph Droms
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-d= hcpv6-prefix-pool-opt?

Hi Med, Leaf,
I fully understand the requirement for network automation versus manual con= figuration, but I still don=E2=80=99t think defining a new dhcp option is t= he right direction to go in order to do routes aggregations in a router. As somebody else already pointed out here, if you need a way to automatical= ly interact with the router i2rs is the right place to discuss your require= ments.
In addition you said:
=E2=9E=A2 =C2=A0I confirm this option is not a per-customer configura= tion parameter.
=C2=A0If it is not a per-client con= figuration why =C2=A0would you like to use DHCP for that?
I understand that in DHCP Server there are already some global parameters l= ike the pool of addresses to be used for the clients, but my understanding = of DHCP behavior , and please correct me if I=E2=80=99m wrong, is that the = DHCP Server provides a per-client configuration.
How would it work with this new option? How does the DHCP Server know if it= has to add or not this option if it is not based on client profile or on c= lient request?
Do you plan to insert the option in all =C2=A0the DHCP Server replies/to al= l clients?
I assume the router is going to install the route once and what does it do = if it gets the same routes more the one? Just ignore? It seems like a waste= of cycles on the router.
In my opinion having global parameters on DHCP Server seems =C2=A0a major c= hange in the DHCP model.
Thanks
Roberta

On Fri, Aug 23, 2013 at 2:15 AM, <mohamed.boucadair@orange.com> wrote:
Hi Roberta,

Yes, as indicated in the document, manual configuration is an option=E2=80= =A6 but it has its limits too.

This proposal is a contribution to add more automation to network configura= tion without requiring an additional dynamic protocol to drive how aggregat= es are built in a router co-located with a requestor, and therefore interac= t in a more dynamic fashion with a routing protocol (e.g., drive route with= drawals, etc.).

Of course, some routers can offer some features to optimize the size of rou= ting tables and prevent from injecting (very) specific entries. But still t= his behavior is implementation-specific and does not provide the same aggre= gation level as the one proposed in this document.

Unlike implementation-specific behaviors, this proposal is deterministic si= nce it is fully controlled by the entity which has the full knowledge of pr= efix related states and network policies: e.g., the server has the knowledg= e of prefix assignment, prefix assignment policies, prefix aggregates, etc.=

I confirm this option is not a per-customer configuration parameter.

Cheers,
Med


De : Roberta Maglione [mailto:robm= gl.ietf@gmail.com]
Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 22:31
=C3=80 : BOUCADAIR Mohamed IMT/OLN
Cc : Ralph Droms; dhcwg@ietf.org WG
Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt?

Hello,
Maybe I=E2=80=99m missing something here, but I=E2=80=99m struggling to see= the value added by this new option in terms of route aggregation functiona= lity.
Today with IPv4 if I need to summarize some routes I manually configure on = the router a summary/aggregate route and I announce it into the routing pro= tocol. Moving to IPv6 you could do the same thing, I don=E2=80=99t quite ge= t what=E2=80=99s wrong with that?
You say you would like to have an automatic way to tell the PE to aggregate= the routes, but if I understand correctly the proposal what you are doing = here is only moving the configuration of the summary route from the PE to t= he DHCPv6 Server; what do you really save here?
In addition the route aggregation is not a per customer configuration, it w= ould be per box or per service configuration so why do you want to add it t= o customers=E2=80=99 profile in DCHPv6 Server?
Thanks
Roberta

On Thu, Aug 22, 2013 at 9:45 AM, <mohamed.boucadair@orange.com> wrote:
Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.

draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes.

Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO.

Cheers,
Med


>-----Message d'origine-----
>De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org= ] De la part de
>Ralph Droms
>Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 14:48
>=C3=80 : Alexandru Petrescu
>Cc : dhcwg@ietf.org WG
>Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcp= v6-
>prefix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
><alexandru.petrescu@= gmail.com> wrote:
>
>> Hi,
>>
>> One point I think is essential is the installment of routes in the= DHCP
>> Relay upon Prefix Assignment.
>>
>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP= must
>> install a route in the DHCP Relay upon delegation.
>>
>> This draft seems to at least assume it, and to describe much more = about
>> it: how various parts of assigned prefixes are aggregated and
>communicated.
>>
>> I support it.
>
>After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to ha= ve
>been aimed at the same problem. =C2=A0If I have that right, it might be=
>instructive to review the dhc WG mailing list discussion that lead to t= he
>abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
>
>- Ralph
>
>>
>> Alex
>>
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =C3=A9crit :
>>> Hi Tomek,
>>>
>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documen= ts a
>>> useful feature in order to have more automation and also contr= ol
>>> routes aggregation instead of relying on proprietary behaviors= of
>>> each implementation. Of course, part of these objectives can b= e
>>> achieved if routes are installed manually or use an out of ban= d
>>> mechanism to enforce routing aggregation policies. Still, the<= br> >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior<= br> >>> because the DHCP server has the knowledge of the prefix assign= ments;
>>> and therefore routes can be triggered with dhcpv6 .
>>>
>>> A way to progress with this document is to target the Experime= ntal
>>> track. Based on the experience that will be gained in real
>>> deployments, the status can be revisited if required.
>>>
>>> Cheers, Med
>>>
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org
>>>> [mailto:dhcwg-bo= unces@ietf.org] De la part de Tomek Mrugalski
>>>> Envoy=C3=A9 : lundi 19 ao=C3=BBt 2013 16:52 =C3=80 : dhcwg= Objet : [dhcwg] Anyone
>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-poo= l-opt?
>>>>
>>>> During Berlin meeting chairs asked if there is still inter= est in
>>>> the prefix-pool-option. There was nobody interested in the= work in
>>>> the room. The unanimous consensus in the room was to drop = it. I
>>>> just wanted to confirm that on the list.
>>>>
>>>> If you are interested in this work, want to support it and=
>>>> participate in it, please let us know by replying to the m= ailing
>>>> list. Otherwise we'll drop this work and mark that dra= ft as a dead
>>>> WG document.
>>>>
>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>>
>>>> Bernie & Tomek _______________________________________= ________
>>>> dhcwg mailing list dhcwg= @ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing = list
>>> dhcwg@ietf.org https://= www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--001a11c365b641120204e4ccd2f8-- From mohamed.boucadair@orange.com Sun Aug 25 23:47:36 2013 Return-Path: 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 38A0211E8155 for ; Sun, 25 Aug 2013 23:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHypxQwmzPTJ for ; Sun, 25 Aug 2013 23:47:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5211E8130 for ; Sun, 25 Aug 2013 23:47:28 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 94F241B81E3; Mon, 26 Aug 2013 08:47:27 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7057615805E; Mon, 26 Aug 2013 08:47:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 26 Aug 2013 08:47:27 +0200 From: To: Roberta Maglione Date: Mon, 26 Aug 2013 08:47:24 +0200 Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: Ac6gMcvnGYEsj4R6SxqJ4VCvnwZaDwB8UWHw Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4E959@PUEXCB1B.nanterre.francetelecom.fr> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EEEE4E959PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.26.54519 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 06:47:36 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E959PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roberta, Thank you for your answer. Please see inline. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : vendredi 23 ao=FBt 2013 20:52 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? Hi Med, Leaf, I fully understand the requirement for network automation versus manual con= figuration, but I still don't think defining a new dhcp option is the right= direction to go in order to do routes aggregations in a router. [Med] Can you please elaborate why this is not a right direction? Isn't pre= fix assignment a key point which would impact route aggregation? Doesn't pr= efix assignment has requirements on routing? Couldn't dhcp be tweaked to op= timize prefix assignments and avoid increasing the size of routing tables? = Wouldn't be there a need to sync prefix assignment state and the routing co= ntroller which would interact with a routing engine? Wouldn't be optimize t= o get rid of that interface and let dhcp pass that information directly to = the routing protocol without passing through a routing controller? As somebody else already pointed out here, if you need a way to automatical= ly interact with the router i2rs is the right place to discuss your require= ments. [Med] this is not conflicting. I2rs does not define protocols...it does (ai= m to) define an interface. If we want to use i2rs terminology, this draft p= roposes to use dhcp as the i2rs interface for the purpose of tweaking route= aggregation, and only for this need because this is the place where prefix= es are managed. In addition you said: > I confirm this option is not a per-customer configuration parameter. If it is not a per-client configuration why would you like to use DHCP fo= r that? [Med] The per-client assigned prefix is part of the prefix returned by this= option. There is dependency between routing and prefix assignment. I understand that in DHCP Server there are already some global parameters l= ike the pool of addresses to be used for the clients, but my understanding = of DHCP behavior , and please correct me if I'm wrong, is that the DHCP Ser= ver provides a per-client configuration. How would it work with this new option? How does the DHCP Server know if it= has to add or not this option if it is not based on client profile or on c= lient request? Do you plan to insert the option in all the DHCP Server replies/to all cli= ents? [Med] The current text says it is inserted in all messages by relay. The se= rver may not inserted the option in all responses. It can insert the option= only if there are changes. I assume the router is going to install the route once and what does it do = if it gets the same routes more the one? Just ignore? It seems like a waste= of cycles on the router. [Med] The server is not requirement to insert the option in all responses. = BTW, in any dynamic provisioning protocol there is a provisioning epoch to = be followed to ensure consistent policies are enforced. Inserting the optio= n on all relay-agent messages is a way to preserve a provisioning epoch. In my opinion having global parameters on DHCP Server seems a major change= in the DHCP model. [Med] There is no change in the model. The prefix returned in the option ma= y be for instance a per-region prefix. See the example in: http://tools.iet= f.org/html/draft-lemon-dhc-topo-conf-01#section-4: "... In this example, link C is a regional backbone for an ISP. Link E = is also a regional backbone for that ISP. Relays A, B, C and D are PE routers, and Links A, B, F and G are actually link aggregators with individual layer 2 circuits to each customer-\u002Dfor example, the relays might be DSLAMs or cable head-end systems. At each customer site we assume there is a single CPE device attached to the link. ..." draft-ietf-dhc-dhcpv6-prefix-pool-opt does only return the aggregate for ea= ch relays A, B, C and D. As you can see draft-lemon-*, this information (i.= e., /40s) is configured to the server. Thanks Roberta On Fri, Aug 23, 2013 at 2:15 AM, > wrote: Hi Roberta, Yes, as indicated in the document, manual configuration is an option... but= it has its limits too. This proposal is a contribution to add more automation to network configura= tion without requiring an additional dynamic protocol to drive how aggregat= es are built in a router co-located with a requestor, and therefore interac= t in a more dynamic fashion with a routing protocol (e.g., drive route with= drawals, etc.). Of course, some routers can offer some features to optimize the size of rou= ting tables and prevent from injecting (very) specific entries. But still t= his behavior is implementation-specific and does not provide the same aggre= gation level as the one proposed in this document. Unlike implementation-specific behaviors, this proposal is deterministic si= nce it is fully controlled by the entity which has the full knowledge of pr= efix related states and network policies: e.g., the server has the knowledg= e of prefix assignment, prefix assignment policies, prefix aggregates, etc. I confirm this option is not a per-customer configuration parameter. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : jeudi 22 ao=FBt 2013 22:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-p= refix-pool-opt? Hello, Maybe I'm missing something here, but I'm struggling to see the value added= by this new option in terms of route aggregation functionality. Today with IPv4 if I need to summarize some routes I manually configure on = the router a summary/aggregate route and I announce it into the routing pro= tocol. Moving to IPv6 you could do the same thing, I don't quite get what's= wrong with that? You say you would like to have an automatic way to tell the PE to aggregate= the routes, but if I understand correctly the proposal what you are doing = here is only moving the configuration of the summary route from the PE to t= he DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, it w= ould be per box or per service configuration so why do you want to add it t= o customers' profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, > wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same objec= tives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to tr= igger route advertisement actions and to control the route aggregates to be= injected using a routing protocol. For example, a router can be told by th= e DHCP server to advertise an aggregate even if not all individual prefixes= are assigned to customer located behind that router. This is a measure tha= t can help in optimizing routing tables and avoid injecting very specific r= outes. Snooping the assignment and then guide the route advertisement actio= ns may not be lead to the same optimized routing tables, because there will= be "holes" that will prevent aggregating routes. Having an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-= prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] De la part de >Ralph Droms >Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 >=C0 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >> wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la p= art de Tomek Mrugalski >>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyo= ne >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/list= info/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E959PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roberta,

 

Thank you for your answer.

=  

Please see inline.<= /span>

 

Cheers,

Med

=

 

&nbs= p;

De = : Roberta Maglione [mailto:robmgl.ietf@gmail.com]
Envoy= =E9 : vendredi 23 ao=FBt 2013 20:52
=C0 : BOUCADAIR= Mohamed IMT/OLN
Cc : Ralph Droms; dhcwg@ietf.org WG
O= bjet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-= dhcpv6-prefix-pool-opt?

 

= Hi Med, Leaf= ,

I fully understand= the requirement for network automation versus manual configuration, but I = still don’t think defining a new dhcp option is the right direction t= o go in order to do routes aggregations in a router.

[Med] Can you please elaborate why this is= not a right direction? Isn’t prefix assignment a key point which wou= ld impact route aggregation? Doesn’t prefix assignment has requiremen= ts on routing? Couldn’t dhcp be tweaked to optimize prefix assignment= s and avoid increasing the size of routing tables? Wouldn’t be there = a need to sync prefix assignment state and the routing controller which wou= ld interact with a routing engine? Wouldn’t be optimize to get rid of= that interface and let dhcp pass that information directly to the routing = protocol without passing through a routing controller?

 

As somebody else already pointed ou= t here, if you need a way to automatically interact with the router i2rs is= the right place to discuss your requirements.

[Med] this is not conflicting. I2rs does not defi= ne protocols...it does (aim to) define an interface. If we want to use i2rs= terminology, this draft proposes to use dhcp as the i2rs interface for the= purpose of tweaking route aggregation, and only for this need because this= is the place where prefixes are managed.

 

In addition you said:

=D8  I= confirm this option is not a per-customer configuration parameter.<= o:p>

 If it is not a per-cl= ient configuration why  would you like to use DHCP for that?

[Med] The per-client assigned = prefix is part of the prefix returned by this option. There is dependency b= etween routing and prefix assignment.

 

I understand that in DHCP Server there are already s= ome global parameters like the pool of addresses to be used for the cl= ients, but my understanding of DHCP behavior , and please correct me if I&#= 8217;m wrong, is that the DHCP Server provides a per-client configuration.<= /span>

How would it wo= rk with this new option? How does the DHCP Server know if it has to add or = not this option if it is not based on client profile or on client request?<= /span>

Do you plan to = insert the option in all  the DHCP Server replies/to all clients?

[Med] The current text s= ays it is inserted in all messages by relay. The server may not inserted th= e option in all responses. It can insert the option only if there are chang= es.

 

I assume t= he router is going to install the route once and what does it do if it gets= the same routes more the one? Just ignore? It seems like a waste of cycles= on the router.

[Med]= The server is not requirement to insert the option in all responses. BTW, = in any dynamic provisioning protocol there is a provisioning epoch to be fo= llowed to ensure consistent policies are enforced. Inserting the option on = all relay-agent messages is a way to preserve a provisioning epoch.

&nbs= p;

In my opinion hav= ing global parameters on DHCP Server seems  a major change in the DHCP= model.

[Med] There i= s no change in the model. The prefix returned in the option may be for inst= ance a per-region prefix. See the example in: http://tools.ietf.org/html= /draft-lemon-dhc-topo-conf-01#section-4:

<= p style=3D'margin:0cm;margin-bottom:.0001pt'> 

=A0=A0 “… In this example, link C is a regional = backbone for an ISP.=A0 Link E is

=A0=A0 also a r= egional backbone for that ISP.=A0 Relays A, B, C and D are PE

=A0=A0 routers, and Links A, B, F and G are actually link aggr= egators with

=A0=A0 individual layer 2 circuits t= o each customer-\u002Dfor example, the

=A0=A0 rel= ays might be DSLAMs or cable head-end systems.=A0 At each customer

=A0=A0 site we assume there is a single CPE device attach= ed to the link. …”

 

draft-ietf-dhc-dhcpv6-prefix-pool-opt do= es only return the aggregate for each relays A, B, C and D. As you can see = draft-lemon-*, this information (i.e., /40s) is configured to the server.

= =A0=A0

 

Thanks

Roberta

 

On Fri, Aug 23, 2013 at 2:15 AM,= <moha= med.boucadair@orange.com> wrote:

Hi Rob= erta,

 

Yes, as in= dicated in the document, manual configuration is an option… but it ha= s its limits too.

 

This proposal is a contribution to add more automation to network config= uration without requiring an additional dynamic protocol to drive how aggre= gates are built in a router co-located with a requestor, and therefore inte= ract in a more dynamic fashion with a routing protocol (e.g., drive route w= ithdrawals, etc.).

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Of course, some routers can offer some features to optimize the size of= routing tables and prevent from injecting (very) specific entries. But sti= ll this behavior is implementation-specific and does not provide the same a= ggregation level as the one proposed in this document.

 

Unlike implementation-specific beha= viors, this proposal is deterministic since it is fully controlled by the e= ntity which has the full knowledge of prefix related states and network pol= icies: e.g., the server has the knowledge of prefix assignment, prefix assi= gnment policies, prefix aggregates, etc.  

&= nbsp;

I confirm this option is not a per-customer= configuration parameter.

 

Cheers,

Med

 

 

De : Roberta Maglione [mail= to:robmgl.ietf@g= mail.com]
Envoy=E9 : jeudi 22 ao=FBt 2013 22:31
= =C0 : BOUCADAIR Mohamed IMT/OLN
Cc : Ralph= Droms; dhcwg@ietf.org<= /a> WG

&nbs= p;

Hello,

Maybe I’m missing something here, but I’m st= ruggling to see the value added by this new option in terms of route aggreg= ation functionality.

Today with = IPv4 if I need to summarize some routes I manually configure on the router = a summary/aggregate route and I announce it into the routing protocol. Movi= ng to IPv6 you could do the same thing, I don’t quite get what’= s wrong with that?

You say you w= ould like to have an automatic way to tell the PE to aggregate the routes, = but if I understand correctly the proposal what you are doing here is only = moving the configuration of the summary route from the PE to the DHCPv6 Ser= ver; what do you really save here?

In addition the route aggregation is not a per customer configuration, i= t would be per box or per service configuration so why do you want to add i= t to customers’ profile in DCHPv6 Server?

Thanks

Roberta

 

On Thu, Au= g 22, 2013 at 9:45 AM, <mohamed.boucadair@orange.com> wrote:

Re-,

IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not = cover the same objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.
<= br>draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to= trigger route advertisement actions and to control the route aggregates to= be injected using a routing protocol. For example, a router can be told by= the DHCP server to advertise an aggregate even if not all individual prefi= xes are assigned to customer located behind that router. This is a measure = that can help in optimizing routing tables and avoid injecting very specifi= c routes. Snooping the assignment and then guide the route advertisement ac= tions may not be lead to the same optimized routing tables, because there w= ill be "holes" that will prevent aggregating routes.

Havin= g an explicit channel like the one specified in draft-ietf-dhc-dhcpv6-prefi= x-pool-opt is superior IMHO.


Cheers,
Med<= br>

>-----Message d'origine-----
>De : dhcwg-bounces@ietf.org [ma= ilto:dhcwg-boun= ces@ietf.org] De la part de

>Ralph Droms<= br>>Envoy=E9 : jeudi 22 ao=FBt 2013 14:48
>=C0 : Alexand= ru Petrescu
>Cc : dhcwg@ietf.org WG
>Objet : Re: [dhcwg] Anyone interest= ed in continuing draft-ietf-dhc-dhcpv6-

>= prefix-pool-opt?
>
>
>On Aug 21, 2013, at 9:24 AM 8/21/13= , Alexandru Petrescu
><alexandru.petrescu@gmail.com> wrote:
><= br>>> Hi,
>>
>> One point I think is essential is t= he installment of routes in the DHCP
>> Relay upon Prefix Assignme= nt.
>>
>> The base DHCPv6 Prefix Delegation RFC does not = stipulate that DHCP must
>> install a route in the DHCP Relay upon= delegation.
>>
>> This draft seems to at least assume it= , and to describe much more about
>> it: how various parts of assi= gned prefixes are aggregated and
>communicated.
>>
>&g= t; I support it.
>
>After a quick read, draft-ietf-dhc-dhcpv6-a= gentopt-delegate seems to have
>been aimed at the same problem.  = ;If I have that right, it might be
>instructive to review the dhc WG = mailing list discussion that lead to the
>abandonment of draft-ietf-d= hc-dhcpv6-agentopt-delegate.
>
>- Ralph
>
>>
= >> Alex
>>
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.= com a =E9crit :
>>> Hi Tomek,
>>>
>>&g= t; I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a
&g= t;>> useful feature in order to have more automation and also control=
>>> routes aggregation instead of relying on proprietary behav= iors of
>>> each implementation. Of course, part of these objec= tives can be
>>> achieved if routes are installed manually or u= se an out of band
>>> mechanism to enforce routing aggregation = policies. Still, the
>>> proposal in draft-ietf-dhc-dhcpv6-pref= ix-pool-opt is superior
>>> because the DHCP server has the kno= wledge of the prefix assignments;
>>> and therefore routes can = be triggered with dhcpv6 .
>>>
>>> A way to progres= s with this document is to target the Experimental
>>> track. B= ased on the experience that will be gained in real
>>> deployme= nts, the status can be revisited if required.
>>>
>>&g= t; Cheers, Med
>>>
>>>> -----Message d'origine--= --- De : dhcwg-= bounces@ietf.org
>>>> [mailto:dhcwg-bounces@ietf.org] De la part de= Tomek Mrugalski
>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 = =C0 : dhcwg Objet : [dhcwg] Anyone
>>>> interested in contin= uing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>>
>>= ;>> During Berlin meeting chairs asked if there is still interest in<= br>>>>> the prefix-pool-option. There was nobody interested in = the work in
>>>> the room. The unanimous consensus in the ro= om was to drop it. I
>>>> just wanted to confirm that on the= list.
>>>>
>>>> If you are interested in thi= s work, want to support it and
>>>> participate in it, pleas= e let us know by replying to the mailing
>>>> list. Otherwis= e we'll drop this work and mark that draft as a dead
>>>> WG= document.
>>>>
>>>> Please respond within 2 = weeks (until Sep. 2nd).
>>>>
>>>> Bernie &= ; Tomek _______________________________________________
>>>>= dhcwg mailing list dhc= wg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dh= cwg
>>> _______________________________________________ dhc= wg mailing list
>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg<= br>>>>
>>>
>>
>>
>> _______= ________________________________________
>> dhcwg mailing list
= >> dhcwg@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
= >_______________________________________________
>dhcwg mailing li= st
>dhcwg@ietf.or= g
>https://www.ietf.org/mailman/listinfo/dhcwg
____________= ___________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf= .org/mailman/listinfo/dhcwg

&nbs= p;

 

= --_000_94C682931C08B048B7A8645303FDC9F36EEEE4E959PUEXCB1Bnante_-- From leaf.yeh.sdo@gmail.com Mon Aug 26 07:36:12 2013 Return-Path: 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 4E75F21F9B91 for ; Mon, 26 Aug 2013 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msfiC6aYp7jV for ; Mon, 26 Aug 2013 07:36:10 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8843721F9B8C for ; Mon, 26 Aug 2013 07:36:10 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so3498462pad.2 for ; Mon, 26 Aug 2013 07:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=wth2FhBcNIzU2FZnGhRFPZzWs0zhL5YWz5zgSZ8mY3o=; b=ij0fu1c1G03tevTPbh90d0qwMn01V6fGHQqC/WsCLJ2Mee+b0yFeKz6vy6GjzCpgoW D+1QjzFM0x3kXcymk2Ij7yoreA3Lr5AFKkyjsrIgf6L1+EHvH4R8tC1bfeGSr3yBDp+n e9owwdJYXKIlx02Ji6xfctwHke+J3ZXXNvwkzwMHhW7ubIU8OyxNABYfjJ1aQLNZ/e3F 7IP8nBFKBUjj2IpbYPTfBXU/9TQ40IwE2Y2YtRGXxYesWKU0jnv/RPl2Zih23oa7k/T9 6pbPKNH+1d/w79Te74LYm3npF9pe+AO5lAaLeA1DICnNPuyhdrPNOQoWaCxhVwMLTUdW jRUA== X-Received: by 10.66.182.229 with SMTP id eh5mr3652342pac.139.1377527768906; Mon, 26 Aug 2013 07:36:08 -0700 (PDT) Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id ar5sm18396230pbc.40.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Aug 2013 07:36:07 -0700 (PDT) From: "Leaf Yeh" To: "'Roberta Maglione'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <521a2824.41a3440a.1475.4b84@mx.google.com> In-Reply-To: Date: Mon, 26 Aug 2013 22:35:57 +0800 Message-ID: <521b67d7.25ab440a.09bb.ffff8e42@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6h3wvqvOtK3D57TIKq8j7+Ofkb6AAKBQCA Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ralph Droms' Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:36:12 -0000 [RM] The main difference here is that RAAN option was used to provide = per-client configuration/route while if I understand correctly your = proposal this option will be used to configure a per-box/per-relay route = or per-group of users (per-service) route on the relay as both you and = Med confirmed.=20 The better understanding is that OPTION_PREFIX_POOL is used for a group = of 'clients', whose client's PD prefixes is from the same pool. The = OPTION_PREFIX_POOL is associated with those OPTION_IA_PDs for the = clients. The DHCPv6 server has full knowledge (including lease) about = this kind of resource in your address plan. [RM] This is my point: you repeat the same option in every Relay-reply = message in order to do a one time/per-relay configuration in my opinion = this does not seem to be very efficient, but I may be wrong. In the mechanism described in this draft, the relay includes OPTION_ORO = in the Relay-Forward message to request the server to response = OPTION_PREFIX_POOL included in the Relay-Reply message. The relay don't = know whether the prefix will be delegated to the client is from a new = prefix pool, it will include OPTION_ORO in the Relay-Forward of = Solicit/Request message to request the server to response = OPTION_PREFIX_POOL. After T1/T2 of this client, the relay who keep = status of each lease of the client's PD prefixes in the same pool might = know the 'Lease of the Pool' has not expired; but it doesn't know = whether the server had changed the status of the pool according to = policy on the route aggregation or not, it still will include OPTION_ORO = in the Relay-Forward of Renew/Rebind message to request the server to = response OPTION_PREFIX_POOL. [RM] My point was not about the packet length, but more mode of = operation: you are asking the Relay to process multiple times the same = option in order to install a route that is already there. =20 The draft has not touched how to implement the aggregated route (eg. = black-hole route) into the routing table yet, but to provide the PE = router the information about the prefix pools and their status, then to = sync the status of pools on the server with the status of pools on the = relay through the above 'piggyback' option in the PD messages. The draft = believe your PE router will have enough logic to keep (or handle) each = lease of the client's PD prefix and the status of the associated = aggregated routes (or the prefix pools). That means that your PE router = might need to establish a new table to keep the status of the associated = prefix pools (or the aggregated routes); only after the status of the = prefix pools changed, then your PE router need to take action to add or = withdraw the associated route. Best Regards, Leaf -------------------------------------------------------------------------= -------- From: Roberta Maglione [mailto:robmgl.ietf@gmail.com]=20 Sent: Monday, August 26, 2013 6:04 AM To: Leaf Yeh Cc: mohamed.boucadair@orange.com; dhcwg@ietf.org WG; Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? Hello Leaf, thanks for your comments please see inline [RM] Best Regards Roberta On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh = wrote: Not sure you have interest to read draft (RAAN, = draft-ietf-dhc-dhcpv6-agentopt-delegate) again. I believe Bernie (or Tomek) have better answer for this question. [RM] The main difference here is that RAAN option was used to provide = per-client configuration/route while if I understand correctly your = proposal this option will be used to configure a per-box/per-relay route = or per-group of users (per-service) route on the relay as both you and = Med confirmed.=20 Roberta - How would it work with this new option? How does the DHCP = Server know if it has to add or not this option if it is not based on = client profile or on client request? The OPTION_PREFIX_POOL will be included in the Relay-Reply message for = DHCPv6-PD Reply to the clients. Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam. Roberta - Do you plan to insert the option in all the DHCP Server = replies/to all clients? Yes, almost every Relay-Reply message for Reply to the clients as = described in the draft. [RM] This is my point: you repeat the same option in every Relay-reply = message in order to do a one time/per-relay configuration in my opinion = this does not seem to be very efficient, but I may be wrong.=20 =20 Roberta - I assume the router is going to install the route once and = what does it do if it gets the same routes more the one? Just ignore? Read the draft, keep in mind you have a smart PE with strong CPU. :-) Roberta - It seems like a waste of cycles on the router. The OPTION_PREFIX_POOL proposed by the draft to include in the = Relay-Reply message is not more than 22 bytes with a fixed format. Your concern here sounds not a problem. [RM] My point was not about the packet length, but more mode of = operation: you are asking the Relay to process multiple times the same = option in order to install a route that is already there. =20 Roberta - In my opinion having global parameters on DHCP Server seems a = major change in the DHCP model. The DHCPv6 server already has the =E2=80=98global parameters=E2=80=99, = such as the prefix pool =E2=80=A6 as you mentioned above. The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) = capability of DHCPv6 server. Pls. read my last reply mail to you & Med's = mail again. The solution with a newly defined option is a solution we thought with a = minimal protocol change. New capability from the new protocol design do need a little change on = your habit for the employment in your deployment. =20 Best Regards, Leaf -------------------------------------------------------------------------= --------------------------------------------------------------- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Roberta Maglione Sent: Saturday, August 24, 2013 2:52 AM To: mohamed.boucadair@orange.com Cc: dhcwg@ietf.org WG; Ralph Droms Subject: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? Hi Med, Leaf, I fully understand the requirement for network automation versus manual = configuration, but I still don=E2=80=99t think defining a new dhcp = option is the right direction to go in order to do routes aggregations = in a router. As somebody else already pointed out here, if you need a way to = automatically interact with the router i2rs is the right place to = discuss your requirements. In addition you said: =E2=9E=A2 I confirm this option is not a per-customer configuration = parameter. If it is not a per-client configuration why would you like to use DHCP = for that? I understand that in DHCP Server there are already some global = parameters like the pool of addresses to be used for the clients, but my = understanding of DHCP behavior , and please correct me if I=E2=80=99m = wrong, is that the DHCP Server provides a per-client configuration. How would it work with this new option? How does the DHCP Server know if = it has to add or not this option if it is not based on client profile or = on client request? Do you plan to insert the option in all the DHCP Server replies/to all = clients? I assume the router is going to install the route once and what does it = do if it gets the same routes more the one? Just ignore? It seems like a = waste of cycles on the router. In my opinion having global parameters on DHCP Server seems a major = change in the DHCP model. Thanks Roberta On Fri, Aug 23, 2013 at 2:15 AM, wrote: Hi Roberta, Yes, as indicated in the document, manual configuration is an = option=E2=80=A6 but it has its limits too. This proposal is a contribution to add more automation to network = configuration without requiring an additional dynamic protocol to drive = how aggregates are built in a router co-located with a requestor, and = therefore interact in a more dynamic fashion with a routing protocol = (e.g., drive route withdrawals, etc.). Of course, some routers can offer some features to optimize the size of = routing tables and prevent from injecting (very) specific entries. But = still this behavior is implementation-specific and does not provide the = same aggregation level as the one proposed in this document. Unlike implementation-specific behaviors, this proposal is deterministic = since it is fully controlled by the entity which has the full knowledge = of prefix related states and network policies: e.g., the server has the = knowledge of prefix assignment, prefix assignment policies, prefix = aggregates, etc. I confirm this option is not a per-customer configuration parameter. Cheers, Med De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 22:31 =C3=80 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? Hello, Maybe I=E2=80=99m missing something here, but I=E2=80=99m struggling to = see the value added by this new option in terms of route aggregation = functionality. Today with IPv4 if I need to summarize some routes I manually configure = on the router a summary/aggregate route and I announce it into the = routing protocol. Moving to IPv6 you could do the same thing, I = don=E2=80=99t quite get what=E2=80=99s wrong with that? You say you would like to have an automatic way to tell the PE to = aggregate the routes, but if I understand correctly the proposal what = you are doing here is only moving the configuration of the summary route = from the PE to the DHCPv6 Server; what do you really save here? In addition the route aggregation is not a per customer configuration, = it would be per box or per service configuration so why do you want to = add it to customers=E2=80=99 profile in DCHPv6 Server? Thanks Roberta On Thu, Aug 22, 2013 at 9:45 AM, wrote: Re-, IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same = objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means to = trigger route advertisement actions and to control the route aggregates = to be injected using a routing protocol. For example, a router can be = told by the DHCP server to advertise an aggregate even if not all = individual prefixes are assigned to customer located behind that router. = This is a measure that can help in optimizing routing tables and avoid = injecting very specific routes. Snooping the assignment and then guide = the route advertisement actions may not be lead to the same optimized = routing tables, because there will be "holes" that will prevent = aggregating routes. Having an explicit channel like the one specified in = draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part = de >Ralph Droms >Envoy=C3=A9 : jeudi 22 ao=C3=BBt 2013 14:48 >=C3=80 : Alexandru Petrescu >Cc : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6- >prefix-pool-opt? > > >On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu > wrote: > >> Hi, >> >> One point I think is essential is the installment of routes in the = DHCP >> Relay upon Prefix Assignment. >> >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP = must >> install a route in the DHCP Relay upon delegation. >> >> This draft seems to at least assume it, and to describe much more = about >> it: how various parts of assigned prefixes are aggregated and >communicated. >> >> I support it. > >After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have >been aimed at the same problem. If I have that right, it might be >instructive to review the dhc WG mailing list discussion that lead to = the >abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. > >- Ralph > >> >> Alex >> >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =C3=A9crit : >>> Hi Tomek, >>> >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a >>> useful feature in order to have more automation and also control >>> routes aggregation instead of relying on proprietary behaviors of >>> each implementation. Of course, part of these objectives can be >>> achieved if routes are installed manually or use an out of band >>> mechanism to enforce routing aggregation policies. Still, the >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior >>> because the DHCP server has the knowledge of the prefix assignments; >>> and therefore routes can be triggered with dhcpv6 . >>> >>> A way to progress with this document is to target the Experimental >>> track. Based on the experience that will be gained in real >>> deployments, the status can be revisited if required. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski >>>> Envoy=C3=A9 : lundi 19 ao=C3=BBt 2013 16:52 =C3=80 : dhcwg Objet : = [dhcwg] Anyone >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>> >>>> During Berlin meeting chairs asked if there is still interest in >>>> the prefix-pool-option. There was nobody interested in the work in >>>> the room. The unanimous consensus in the room was to drop it. I >>>> just wanted to confirm that on the list. >>>> >>>> If you are interested in this work, want to support it and >>>> participate in it, please let us know by replying to the mailing >>>> list. Otherwise we'll drop this work and mark that draft as a dead >>>> WG document. >>>> >>>> Please respond within 2 weeks (until Sep. 2nd). >>>> >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Aug 26 08:46:58 2013 Return-Path: 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 5D1FC11E81C5 for ; Mon, 26 Aug 2013 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Yx+3tJASTFl for ; Mon, 26 Aug 2013 08:46:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2F11E81BC for ; Mon, 26 Aug 2013 08:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15355; q=dns/txt; s=iport; t=1377532010; x=1378741610; h=from:to:subject:date:message-id:mime-version; bh=76g4WBQcrbDNc7l7N/iQQRb4jkMsK5VNmuqsJ+q7ebA=; b=I+vjD2eWXmg/vNM254u2Qw5oS0hIdRgYKRLvYYsybIygTWAjPGT8BE9U vXj2iWcJzYLWdAoKa17inJz3JUlYfslx/P1NYlr5ROmlmeOLtodhCL5KL nGn3q2tUsKFTu6yvVGaQ+cVtg8qC+j9jpjdcptlZReJFQ4Sy/ppViQ1Lg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQGAAp4G1KtJXG+/2dsb2JhbABbgkNENVG3UohDgSIWbQeCJAEBAQQtXgEZBAEBCx05FAkJAQQTCId5DJY/oSSQRzeDHX0DmRuQNIFjgTuCKg X-IronPort-AV: E=Sophos;i="4.89,959,1367971200"; d="scan'208,217";a="251695479" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2013 15:46:50 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7QFknq5000570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Aug 2013 15:46:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 10:46:49 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Results of WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! Thread-Index: Ac6icy7/MgcharbVTkOi3dDn+8ixdQ== Date: Mon, 26 Aug 2013 15:46:48 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186ACE5A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.163] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E186ACE5Axmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:46:58 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E186ACE5Axmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ... here's the results of this WGLC: The WG co-chairs feel this document has WG consensus as there were multiple= reviews and responses in favor, and no one objecting to advancing the docu= ment. The work also builds on the DHCPv4 failover draft work which had year= s of discussion and review (though never having been completed). However, a= s there were nits and some potential substantive clarifications (more on th= is to come from either Kim or Bernie), it will be prudent to wait until the= updated draft is available and give people a week or so to review these ch= anges before advancing. If you have not yet reviewed the document and your provided input, please u= se this additional time to provide your comments and support for or objecti= on against advancing the document. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Friday, July 19, 2013 9:59 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respon= d by August 9, 2013! Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tool= s.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe it is ready = for working group last call. Please review this draft and indicate whether = or not you feel it is ready to be published. Your input is important! This document is the 2nd series of documents related to DHCPv6 failover - t= he first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requi= rements which is currently being reviewed by the IESG for publication appro= val. At the time of this writing, there is no IPR reported against this draft. As Tomek is a co-author, I will primarily evaluate consensus after 2013-08-= 09 (August 9th). This is a 3 week last call because of the Berlin IETF meet= ing and also because of summer-time vacations (at least for those of us in = the northern hemisphere). Thanks, - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E186ACE5Axmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi … here’= s the results of this WGLC:

 

The WG co-chairs feel = this document has WG consensus as there were multiple reviews and responses= in favor, and no one objecting to advancing the document. The work also bu= ilds on the DHCPv4 failover draft work which had years of discussion and review (though never having been complet= ed). However, as there were nits and some potential substantive clarificati= ons (more on this to come from either Kim or Bernie), it will be prudent to= wait until the updated draft is available and give people a week or so to review these changes before adva= ncing.

 

If you have not yet re= viewed the document and your provided input, please use this additional tim= e to provide your comments and support for or objection against advancing t= he document.

 

-          Bernie<= b>

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Friday, July 19, 2013 9:59 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 -= Respond by August 9, 2013!

 

Folks, the authors of draft-ietf-dhc-dhcpv6-failo= ver-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-= design) believe it is ready for working group last call. Please review this draft and indicate whether or = not you feel it is ready to be published. Your input is important!

 

This document is the 2nd series of doc= uments related to DHCPv6 failover – the first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements = which is currently being reviewed by the IESG for publication approval.

 

At the time of this writing, there is no IPR repo= rted against this draft.

 

As Tomek is a co-author, I will primarily evaluat= e consensus after 2013-08-09 (August 9th). This is a 3 week last= call because of the Berlin IETF meeting and also because of summer-time va= cations (at least for those of us in the northern hemisphere).

 

Thanks,

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E186ACE5Axmbrcdx04ciscoc_-- From tomasz.mrugalski@gmail.com Mon Aug 26 09:54:28 2013 Return-Path: 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 707E611E81CE for ; Mon, 26 Aug 2013 09:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWetS0abgUPk for ; Mon, 26 Aug 2013 09:54:28 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9230711E81D1 for ; Mon, 26 Aug 2013 09:54:27 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so1767560eaj.27 for ; Mon, 26 Aug 2013 09:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/0H5AfZ/vOEz3eeyflwDSyB94m6sj8AfOdfYb/9LuMc=; b=UZWpeMsTUIJRORRFN3W3RttXTg9Uc1k/OQscfz7O0gaMBC6TSGuDJLSCv/PG4/xRyW Sh5qS3LIDGXzugQpcFAY6ZP+UxTVlo8ZwUnCTvYR7XjgXSKBYKqHGw9ngCbZuFEK/wpY fio4vF/1ymHdGmHBy1qkSvlqKCGgdyWHZc6s9CQP9nB7uEZkk0VkWHsgwUXZSHCaE2VV 8oET/5F3L3GbKdqIaW3mt/TcVwYKNo+XksZNZh6o5vHJx4RMVJ41mX+FueihUssZn2r4 iBTgM7Lom26+3xc5LxBjCqCb6S/0mhFffk4xajXQME0/FlRCxkmAox0YPc8/nPIlFiqo qNNw== X-Received: by 10.14.221.137 with SMTP id r9mr21020eep.86.1377536066714; Mon, 26 Aug 2013 09:54:26 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id a43sm22649083eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 09:54:25 -0700 (PDT) Message-ID: <521B883E.8050205@gmail.com> Date: Mon, 26 Aug 2013 18:54:22 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <489D13FBFA9B3E41812EA89F188F018E185DDC1C@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185DDC1C@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130826185422605 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] 2nd Request - Updated WG Milestones - Need Input from draft Authors! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:54:28 -0000 On 11.07.2013 18:08, Bernie Volz (volz) wrote: > Please help out here! I haven’t received any input!! (*Please reply to > chairs only*. All will have opportunity to review the milestones a bit > later once we’ve developed a proposal.) Bernie, Here are my proposals for some of the drafts: RFC3315: Sep 2013 Convert 3315 nroff sources into XML format Oct 2013 Appoint editor, assemble design team Nov 2013 Decide which RFCs and drafts to merge in 3315bis Mar 2014 Adopt 3315bis document Nov 2014 WC last call on 3315bis document Apr 2015 Submit 3315bis document to IESG v4configuration Oct 2013 WC last call on v4-configuration Dec 2013 Submit v4-configuration to IESG unknown-msg Oct 2013 WC last call on unknown-msg Dec 2013 Submit unknown-msg to IESG draft-ietf-dhc-dhcpv4-over-dhcpv6 Nov 2013 WG last call on dhcpv4-over-dhcpv6 Feb 2014 Submit dhcpv4-over-dhcpv6 to IESG draft-ietf-dhc-option-guidelines Sep 2013 Submit option guidelines to IESG Authors, specifying a challenging, but realistic milestones for your drafts is one way to get your draft worked on in a timely manner. Please send out proposed milestone for items that are in our proposed charter. Thanks, Tomek From rdroms.ietf@gmail.com Mon Aug 26 10:29:40 2013 Return-Path: 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 EA69611E81D6 for ; Mon, 26 Aug 2013 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUNqlYhZSTxV for ; Mon, 26 Aug 2013 10:29:40 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0111E81C8 for ; Mon, 26 Aug 2013 10:29:39 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id c11so1908986qcv.41 for ; Mon, 26 Aug 2013 10:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQPsAnHqg5mOE8AjEgrVP2570I4ndQdy5C2i6xrKYMg=; b=vfaggU+XYMd2FObz6DRJTyTH1NobMKQaowA+ITBC0//IWFxTNN+qBJIUkVmtS6pNRd PoMDyew55a6t7yBQ3gxPK28OT1gN5v7UHtv4cyNeLJYDZ5UzIxMO78pezazx9zCwJlOm YID1r/9USbHRgUA799tJiZbgadj+7qQSyvVKckDFeG6Ud+705fkddiAkRKSf3DmIa2rR nNniq7QMV1c1BfgPrHXdyqllMXlCYjE7eAvXLHM3DpiKyn23jnUGIl77IPh4xKGVLoiL 5rq/pImaSaUL9WC2KJ091R018UCnebWIl4/gKPe5eUBJ4x1ZGDMYCAHGUU5Tb4Ly6fdz +yVQ== X-Received: by 10.224.92.70 with SMTP id q6mr17737420qam.43.1377538179210; Mon, 26 Aug 2013 10:29:39 -0700 (PDT) Received: from che-vpn-cluster-2-418.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id m10sm23305082qae.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 10:29:37 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> Date: Mon, 26 Aug 2013 10:29:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , Alexandru Petrescu Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:29:41 -0000 Bernie - thanks for the clarifications. I'm curious about the demand for this option. Is there explicit demand = from a group of SPs that want to use this option, or is being defined in = speculation of SP demand? Is it really the case that the SP may = dynamically change the prefix delegation architecture in a dynamic way = that requires this specific automated configuration? In my opinion, piggy-backing the prefix-pool option on client-server = communication is not appropriate. As you point out, piggy-backing may = not provide relay-router/server communication at the time it is needed. = Also, if I read the draft correctly and the relay-router snoops the = server->client message to determine how to interpret the = prefix-pool-opt, I think it would be much cleaner to include the = operation code in the prefix-pool-opt itself. If I recall correctly = from the discussion of agentopt-delegate, there were questions about the = reliability of piggy-backing: suppose messages are delivered = out-of-order or delivered through different relay agents? Someone else pointed out that there are many other configuration knobs = that need to be set in the relay-router. Why use DHCP just for the = prefix routing and not the other configuration? Has the alternative of a routing protocol been considered? - Ralph On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) = wrote: > Ralph: >=20 > Thanks for bringing up that old draft! There were issues here that = caused this work to be abandoned. >=20 > And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I = think one difference in the prefix-pool is that this is more to handle = the case where the relay (router) is told to inject X/48 into the = routing instead of Y/64 or Y/60 that might be going to the client. (This = it to avoid having to inject lots of /64 or /60 routes when many clients = are 'connected via the router'.) >=20 > Agentop could have been used to do that, but I'm not sure that was = explicitly discussed or covered (and I didn't check the draft). >=20 > I did like agentop better than this proposal in one respect - and that = is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a = terrible idea (IMHO) since there is nothing to guarantee communication = on which to piggyback the request to remove the pool. A lifetime covers = that as it causes the entry to expire on its own. And, 0 lifetimes can = be used to remove 'now'. But that's more of a minor issue as to whether = the entire work is appropriate. >=20 > Cable CMTS devices have been snooping address and PD assignments for a = long time now and rather successfully. I suspect that the 'prefix pool' = issue there is handled by static configuration on the CMTS. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ralph Droms > Sent: Thursday, August 22, 2013 8:48 AM > To: Alexandru Petrescu > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Anyone interested in continuing = draft-ietf-dhc-dhcpv6-prefix-pool-opt? >=20 >=20 > On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu = wrote: >=20 >> Hi, >>=20 >> One point I think is essential is the installment of routes in the=20 >> DHCP Relay upon Prefix Assignment. >>=20 >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 >> must install a route in the DHCP Relay upon delegation. >>=20 >> This draft seems to at least assume it, and to describe much more=20 >> about >> it: how various parts of assigned prefixes are aggregated and = communicated. >>=20 >> I support it. >=20 > After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have been aimed at the same problem. If I have that right, it might be = instructive to review the dhc WG mailing list discussion that lead to = the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. >=20 > - Ralph >=20 >>=20 >> Alex >>=20 >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>>=20 >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20= >>> useful feature in order to have more automation and also control=20 >>> routes aggregation instead of relying on proprietary behaviors of=20 >>> each implementation. Of course, part of these objectives can be=20 >>> achieved if routes are installed manually or use an out of band=20 >>> mechanism to enforce routing aggregation policies. Still, the=20 >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior = because=20 >>> the DHCP server has the knowledge of the prefix assignments; and=20 >>> therefore routes can be triggered with dhcpv6 . >>>=20 >>> A way to progress with this document is to target the Experimental=20= >>> track. Based on the experience that will be gained in real=20 >>> deployments, the status can be revisited if required. >>>=20 >>> Cheers, Med >>>=20 >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski = Envoy=E9=20 >>>> : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone=20 >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>=20 >>>> During Berlin meeting chairs asked if there is still interest in = the=20 >>>> prefix-pool-option. There was nobody interested in the work in the=20= >>>> room. The unanimous consensus in the room was to drop it. I just=20 >>>> wanted to confirm that on the list. >>>>=20 >>>> If you are interested in this work, want to support it and=20 >>>> participate in it, please let us know by replying to the mailing=20 >>>> list. Otherwise we'll drop this work and mark that draft as a dead=20= >>>> WG document. >>>>=20 >>>> Please respond within 2 weeks (until Sep. 2nd). >>>>=20 >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list=20= >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Aug 26 11:08:52 2013 Return-Path: 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 7E72821F92CD for ; Mon, 26 Aug 2013 11:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwW04CWEv0Zc for ; Mon, 26 Aug 2013 11:08:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 935EF11E81F3 for ; Mon, 26 Aug 2013 11:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7912; q=dns/txt; s=iport; t=1377540526; x=1378750126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zcZ8FeSxMIlftbNpMNyVMBgukdpUenxss6LvWyKThvk=; b=DQJJAepqKL0+NHD03+MWAYQoxRIVIq9IQsCAzY2THn3co0Z3SMxiOB/J 5VhLz3ofUh5Dxwjd3bClFWR3LgK5xe5/24cDCMctDAMJBc4J3f2JGnoHb J34zbtwk0q/UqDdzuO6+MLIU4BmHSteX3ThD4VNsJG1+KlYACc6CxxOnZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJyYG1KtJV2Z/2dsb2JhbABagwc1UcAfgSIWdIIkAQEBAwEBAQEkRQILBQcEAgEIDgMBAwEBAQodByEGCxQDBggCBA4FCIdnAwkGDK1EDYlmBI1/gSULgRgxBwaDFn0DiHmLG4Fxjh6FLIFjgTuBcTk X-IronPort-AV: E=Sophos;i="4.89,960,1367971200"; d="scan'208";a="251877670" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 26 Aug 2013 18:08:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7QI8jMk011757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 18:08:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 13:08:45 -0500 From: "Bernie Volz (volz)" To: Ralph Droms Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Thread-Index: AQHOnzXvaLHmSLwSfkSFfLi6OLbc0pmhMawAgAbnYgD//7QNUA== Date: Mon, 26 Aug 2013 18:08:44 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E186AD2E3@xmb-rcd-x04.cisco.com> References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com> In-Reply-To: <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Alexandru Petrescu Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:08:52 -0000 Hi Ralph: This draft is a WG document (was adopted September 2012) and there has been= a WGLC that did not pass (not enough interest last April) - and in Berlin = there was no interest when Tomek asked the WG. Tomek sent out the email to = gauge the level of interest as the WG meeting is a barometer, but it should= also go to the list. I haven't reviewed the detailed responses, but I don'= t think there has been strong support (and I think an equal level of opposi= tion). Tomek will review September 2nd (I will be on vacation) and announce result= s to the list. If there is explicit demand from a group of SPs, hopefully they will let it= be known (and perhaps provide strong motivation as to why this should be v= ia DHCP rather than alternatives). I too (as an individual, with co-chair hat off) am skeptical of the value o= f this work. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= alph Droms Sent: Monday, August 26, 2013 1:30 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org WG; Alexandru Petrescu Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-= prefix-pool-opt? Bernie - thanks for the clarifications. I'm curious about the demand for this option. Is there explicit demand fro= m a group of SPs that want to use this option, or is being defined in specu= lation of SP demand? Is it really the case that the SP may dynamically cha= nge the prefix delegation architecture in a dynamic way that requires this = specific automated configuration? In my opinion, piggy-backing the prefix-pool option on client-server commun= ication is not appropriate. As you point out, piggy-backing may not provid= e relay-router/server communication at the time it is needed. Also, if I r= ead the draft correctly and the relay-router snoops the server->client mess= age to determine how to interpret the prefix-pool-opt, I think it would be = much cleaner to include the operation code in the prefix-pool-opt itself. = If I recall correctly from the discussion of agentopt-delegate, there were = questions about the reliability of piggy-backing: suppose messages are deli= vered out-of-order or delivered through different relay agents? Someone else pointed out that there are many other configuration knobs that= need to be set in the relay-router. Why use DHCP just for the prefix rout= ing and not the other configuration? Has the alternative of a routing protocol been considered? - Ralph On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) wr= ote: > Ralph: >=20 > Thanks for bringing up that old draft! There were issues here that caused= this work to be abandoned. >=20 > And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I=20 > think one difference in the prefix-pool is that this is more to handle=20 > the case where the relay (router) is told to inject X/48 into the=20 > routing instead of Y/64 or Y/60 that might be going to the client.=20 > (This it to avoid having to inject lots of /64 or /60 routes when many=20 > clients are 'connected via the router'.) >=20 > Agentop could have been used to do that, but I'm not sure that was explic= itly discussed or covered (and I didn't check the draft). >=20 > I did like agentop better than this proposal in one respect - and that is= its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrib= le idea (IMHO) since there is nothing to guarantee communication on which t= o piggyback the request to remove the pool. A lifetime covers that as it ca= uses the entry to expire on its own. And, 0 lifetimes can be used to remove= 'now'. But that's more of a minor issue as to whether the entire work is a= ppropriate. >=20 > Cable CMTS devices have been snooping address and PD assignments for a lo= ng time now and rather successfully. I suspect that the 'prefix pool' issue= there is handled by static configuration on the CMTS. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Ralph Droms > Sent: Thursday, August 22, 2013 8:48 AM > To: Alexandru Petrescu > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv= 6-prefix-pool-opt? >=20 >=20 > On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu wrote: >=20 >> Hi, >>=20 >> One point I think is essential is the installment of routes in the=20 >> DHCP Relay upon Prefix Assignment. >>=20 >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 >> must install a route in the DHCP Relay upon delegation. >>=20 >> This draft seems to at least assume it, and to describe much more=20 >> about >> it: how various parts of assigned prefixes are aggregated and communicat= ed. >>=20 >> I support it. >=20 > After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have= been aimed at the same problem. If I have that right, it might be instruc= tive to review the dhc WG mailing list discussion that lead to the abandonm= ent of draft-ietf-dhc-dhcpv6-agentopt-delegate. >=20 > - Ralph >=20 >>=20 >> Alex >>=20 >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>>=20 >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20 >>> useful feature in order to have more automation and also control=20 >>> routes aggregation instead of relying on proprietary behaviors of=20 >>> each implementation. Of course, part of these objectives can be=20 >>> achieved if routes are installed manually or use an out of band=20 >>> mechanism to enforce routing aggregation policies. Still, the=20 >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior=20 >>> because the DHCP server has the knowledge of the prefix assignments;=20 >>> and therefore routes can be triggered with dhcpv6 . >>>=20 >>> A way to progress with this document is to target the Experimental=20 >>> track. Based on the experience that will be gained in real=20 >>> deployments, the status can be revisited if required. >>>=20 >>> Cheers, Med >>>=20 >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski=20 >>>> Envoy=E9 >>>> : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone=20 >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>=20 >>>> During Berlin meeting chairs asked if there is still interest in=20 >>>> the prefix-pool-option. There was nobody interested in the work in=20 >>>> the room. The unanimous consensus in the room was to drop it. I=20 >>>> just wanted to confirm that on the list. >>>>=20 >>>> If you are interested in this work, want to support it and=20 >>>> participate in it, please let us know by replying to the mailing=20 >>>> list. Otherwise we'll drop this work and mark that draft as a dead=20 >>>> WG document. >>>>=20 >>>> Please respond within 2 weeks (until Sep. 2nd). >>>>=20 >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list=20 >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Aug 26 20:54:32 2013 Return-Path: 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 23A6C11E8133 for ; Mon, 26 Aug 2013 20:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E00g+rwHr3iq for ; Mon, 26 Aug 2013 20:54:27 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2420111E813F for ; Mon, 26 Aug 2013 20:54:25 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so4269798pad.37 for ; Mon, 26 Aug 2013 20:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=EozGZ6wJ1B5ad++pS4tpZEzJ1TJIXbPP9kF+Zsf87dw=; b=wyakNLqDIyly5ANSpPfIZQaG2Ff2nQXKhaexQCweX/TMC4pOOCRTQlLa+zyd50ba5L FQdAasLbbzODeE4OOykXlKwnNIAQgrlFcTolzrz5CKwNR42pmXtyyFqOFKVFjt3RbZ1V SbhqFHKtt+8pdaRbO4Nz0JRt630khEuRNdqgubFqh0tG7Q6xl9/PDJkGBiltFpxetqRn sauBaUN87faQX/4x4SVE+E8TY/vDK+d+s0Ft9Ma977tqltvpWvuGNik0KyWrIeIzUlQg CYBBpArr6fo1bdzKP7NsD65IFYtn29tzkgcp7zWaYPljfb9iHT4cCw1FIsKXERz8G6Ba 9lLg== X-Received: by 10.68.169.161 with SMTP id af1mr18958292pbc.22.1377575658867; Mon, 26 Aug 2013 20:54:18 -0700 (PDT) Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id yg1sm21613623pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Aug 2013 20:54:18 -0700 (PDT) From: "Leaf Yeh" To: "'Ralph Droms'" , "'Bernie Volz \(volz\)'" References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com> In-Reply-To: <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com> Date: Tue, 27 Aug 2013 11:54:06 +0800 Message-ID: <521c22ea.41a3440a.1475.4d9e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6igdunGLX91S+jRsSEGqk84ddDuwAUpbEg Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Alexandru Petrescu' Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 03:54:32 -0000 [Ralph] I think it would be much cleaner to include the operation code = in the prefix-pool-opt itself. =20 The operation code in the OPTION_PREFIX_POOL defined in this draft = sounds in the 'status' field. [Ralph] If I recall correctly from the discussion of agentopt-delegate, there were questions about the reliability of piggy-backing: suppose messages are delivered out-of-order or delivered through different relay agents? I guess the reliability of the DHCPv6 option (eg. OPTION_ORO, OPTION_PREFIX_POOL) sounds the same as that of DHCPv6 (PD) message [Ralph] Someone else pointed out that there are many other configuration knobs that need to be set in the relay-router. Why use DHCP just for the prefix routing and not the other configuration? Just because this part could be dynamic. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ralph Droms Sent: Tuesday, August 27, 2013 1:30 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org WG; Alexandru Petrescu Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Bernie - thanks for the clarifications. I'm curious about the demand for this option. Is there explicit demand = from a group of SPs that want to use this option, or is being defined in speculation of SP demand? Is it really the case that the SP may = dynamically change the prefix delegation architecture in a dynamic way that requires this specific automated configuration? In my opinion, piggy-backing the prefix-pool option on client-server communication is not appropriate. As you point out, piggy-backing may = not provide relay-router/server communication at the time it is needed. = Also, if I read the draft correctly and the relay-router snoops the = server->client message to determine how to interpret the prefix-pool-opt, I think it = would be much cleaner to include the operation code in the prefix-pool-opt = itself. If I recall correctly from the discussion of agentopt-delegate, there = were questions about the reliability of piggy-backing: suppose messages are delivered out-of-order or delivered through different relay agents? Someone else pointed out that there are many other configuration knobs = that need to be set in the relay-router. Why use DHCP just for the prefix routing and not the other configuration? Has the alternative of a routing protocol been considered? - Ralph On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) wrote: > Ralph: >=20 > Thanks for bringing up that old draft! There were issues here that = caused this work to be abandoned. >=20 > And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I=20 > think one difference in the prefix-pool is that this is more to handle = > the case where the relay (router) is told to inject X/48 into the=20 > routing instead of Y/64 or Y/60 that might be going to the client.=20 > (This it to avoid having to inject lots of /64 or /60 routes when many = > clients are 'connected via the router'.) >=20 > Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft). >=20 > I did like agentop better than this proposal in one respect - and that = is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a = terrible idea (IMHO) since there is nothing to guarantee communication on which = to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. But that's more of a minor issue as to whether the entire = work is appropriate. >=20 > Cable CMTS devices have been snooping address and PD assignments for a long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = > Of Ralph Droms > Sent: Thursday, August 22, 2013 8:48 AM > To: Alexandru Petrescu > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? >=20 >=20 > On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu wrote: >=20 >> Hi, >>=20 >> One point I think is essential is the installment of routes in the=20 >> DHCP Relay upon Prefix Assignment. >>=20 >> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 >> must install a route in the DHCP Relay upon delegation. >>=20 >> This draft seems to at least assume it, and to describe much more=20 >> about >> it: how various parts of assigned prefixes are aggregated and communicated. >>=20 >> I support it. >=20 > After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to = have been aimed at the same problem. If I have that right, it might be instructive to review the dhc WG mailing list discussion that lead to = the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. >=20 > - Ralph >=20 >>=20 >> Alex >>=20 >> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>> Hi Tomek, >>>=20 >>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20 >>> useful feature in order to have more automation and also control=20 >>> routes aggregation instead of relying on proprietary behaviors of=20 >>> each implementation. Of course, part of these objectives can be=20 >>> achieved if routes are installed manually or use an out of band=20 >>> mechanism to enforce routing aggregation policies. Still, the=20 >>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior=20 >>> because the DHCP server has the knowledge of the prefix assignments; = >>> and therefore routes can be triggered with dhcpv6 . >>>=20 >>> A way to progress with this document is to target the Experimental=20 >>> track. Based on the experience that will be gained in real=20 >>> deployments, the status can be revisited if required. >>>=20 >>> Cheers, Med >>>=20 >>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski=20 >>>> Envoy=E9 >>>> : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] Anyone=20 >>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>=20 >>>> During Berlin meeting chairs asked if there is still interest in=20 >>>> the prefix-pool-option. There was nobody interested in the work in=20 >>>> the room. The unanimous consensus in the room was to drop it. I=20 >>>> just wanted to confirm that on the list. >>>>=20 >>>> If you are interested in this work, want to support it and=20 >>>> participate in it, please let us know by replying to the mailing=20 >>>> list. Otherwise we'll drop this work and mark that draft as a dead=20 >>>> WG document. >>>>=20 >>>> Please respond within 2 weeks (until Sep. 2nd). >>>>=20 >>>> Bernie & Tomek _______________________________________________ >>>> dhcwg mailing list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing list=20 >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From twinters@iol.unh.edu Tue Aug 27 05:31:47 2013 Return-Path: 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 79CED11E8302 for ; Tue, 27 Aug 2013 05:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TNwFOGhX+6k for ; Tue, 27 Aug 2013 05:31:42 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with SMTP id 4B9F411E82E9 for ; Tue, 27 Aug 2013 05:31:40 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUhycBmW4hAus3/KTYXVu4ZUYGJc5Jg1/@postini.com; Tue, 27 Aug 2013 05:31:42 PDT Received: from [10.0.1.10] (c-24-63-15-128.hsd1.nh.comcast.net [24.63.15.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id D9D218F0082; Tue, 27 Aug 2013 08:31:01 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timothy Winters In-Reply-To: Date: Tue, 27 Aug 2013 08:31:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB925D5-1B43-4D70-B859-03E331D84539@iol.unh.edu> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:31:47 -0000 The UNH-IOL has seen several DHCPv6 Clients and DHCPv6 Server = implementations struggle with the errata for allowing IA_PD to be = processed when IA_NA is NotAvailable. At this point I don't think that = 3315 should not be advanced. Regards, Tim On Aug 22, 2013, at 10:35 AM, "Weil, Jason" = wrote: > I am also not seeing the benefit of pushing two RFCs that are in the > process of being merged to something better than the sum of their = parts > before that merge is successful. And like Ole mentioned wouldn't it = fail > on the errata point (2) from Tomek's original email anyway? >=20 > Jason >=20 > On 8/22/13 9:39 AM, "Ole Troan" wrote: >=20 >>> Unless we receive some additional comments from the WG, we will be >>> forced to conclude that there is NO support for advancing these >>> documents to Internet Standard. >>>=20 >>> Because of the time of year (perhaps the last of summer vacations), = we >>> will wait until September 9th to make a final decision. But at the >>> current rate of response, it does not look favorable. >>=20 >> I do not support advancing RFC3315/RFC3633 to Internet Standard. >> reason being that I believe that there are errata that will lead to >> interoperability problems. >>=20 >> cheers, >> Ole >>=20 >>> -----Original Message----- >>> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >>> Sent: Monday, August 19, 2013 2:52 PM >>> To: dhcwg@ietf.org >>> Cc: Bernie Volz (volz) >>> Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet >>> Standard >>>=20 >>> On 12.08.2013 21:21, Bernie Volz (volz) wrote: >>>> During the Berlin IETF-87 DHC WG session, it was suggested that we >>>> initiate a standards action request to move RFC 3315 (and RFC = 3633), >>>> which are presently Proposed Standards, to Internet Standard. While = we >>>> plan to work on a 3315bis which would merge the work, it was = pointed >>>> out by several people (include our Area Director) that there is >>>> technically no need to wait for that to advance the standards. >>>>=20 >>>> The requirements for advancement are outlined in RFC 2026 and RFC = 6410 >>>> (which removed Draft Standard). >>>>=20 >>>> Per RFC 6410: >>>>=20 >>>> The criteria are: >>>>=20 >>>> (1) There are at least two independent interoperating = implementations >>>> with widespread deployment and successful operational = experience. >>> There are many more than just two. >>>=20 >>>> (2) There are no errata against the specification that would cause = a >>>> new implementation to fail to interoperate with deployed ones. >>> There are known issues, e.g. those described in >>> draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of = annoyance, >>> rather than interoperability breaking problems. New implementations = are >>> interoperating with existing ones without problems. >>>=20 >>>> (3) There are no unused features in the specification that greatly >>>> increase implementation complexity. >>> That's an interesting question. Are there any implementations that >>> implement the whole RFC3315? I mean really everything: = reconfiguration, >>> reconfigure-key, delayed auth, replay detection, sending CONFIRM = when >>> link state changes, sending DECLINE if DAD fails, rapid-commit, >>> supporting 32 relays, all 3 duid types etc.? >>>=20 >>> That's a trick question. I have my own answer for it, but I'd like = to >>> hear WG opinion on that matter. >>>=20 >>>> (4) If the technology required to implement the specification >>>> requires patented or otherwise controlled technology, then the >>>> set of implementations must demonstrate at least two = independent, >>>> separate and successful uses of the licensing process. >>> There are no IPRs claimed against RFC3315 and RFC3633. >>>=20 >>> Ok, so in my opinion all criteria are met. >>>=20 >>>> Please provide input as to whether you support making this request = of >>>> the IETF/IESG (via the Internet Area Directors) or whether you feel >>>> there are issues (based on the above criteria). If you feel one >>>> document is ready but the other isn't, please let us know about = that >>>> too. >>> I feel that we should move forward with this for both 3315 and 3633. >>> There's almost 7000 RFCs published, but there are only 96 that have >>> Internet Standard status. I strongly believe that DHCPv6 is one of = core >>> Internet protocols. This status change would reflect that. >>>=20 >>> With my chair on, I'm disappointed that nobody responded to this = mail >>> so far. Chairs got couple comments off the list, but nobody said >>> anything on the list. I don't know, perhaps people are not that much >>> interested, because this move does not have any immediate practical >>> repercussions. >>> Or perhaps it is a middle of vacation time... >>>=20 >>> Come on, guys. Saying +1 doesn't take much time. ;-) >>>=20 >>> Tomek >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From twinters@iol.unh.edu Tue Aug 27 06:03:28 2013 Return-Path: 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 8795011E8323 for ; Tue, 27 Aug 2013 06:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id razTC+gXr0K5 for ; Tue, 27 Aug 2013 06:03:23 -0700 (PDT) Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with SMTP id 9404B11E8327 for ; Tue, 27 Aug 2013 06:03:22 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKUhyjl+vXorLpmO/d7M+tVqLLQ760Q0xZ@postini.com; Tue, 27 Aug 2013 06:03:23 PDT Received: from openvpn-client17.iol.unh.edu (openvpn-client17.iol.unh.edu [132.177.124.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id BBF328F007F; Tue, 27 Aug 2013 09:03:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Timothy Winters In-Reply-To: <5AB925D5-1B43-4D70-B859-03E331D84539@iol.unh.edu> Date: Tue, 27 Aug 2013 09:03:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88AB5C97-CB8A-4DB1-B32C-C15A5A2C8D68@iol.unh.edu> References: <5AB925D5-1B43-4D70-B859-03E331D84539@iol.unh.edu> To: "Weil, Jason" X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard - NO SUPPORT FOR THIS?????? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:03:28 -0000 Hello, Rereading my last sentence I realize that it's not very clear. = It should read the following: "At this point I don't think that 3315 should be advanced"=20 Regards, Tim On Aug 27, 2013, at 8:31 AM, Timothy Winters = wrote: > The UNH-IOL has seen several DHCPv6 Clients and DHCPv6 Server = implementations struggle with the errata for allowing IA_PD to be = processed when IA_NA is NotAvailable. At this point I don't think that = 3315 should not be advanced. >=20 > Regards, > Tim >=20 > On Aug 22, 2013, at 10:35 AM, "Weil, Jason" = wrote: >=20 >> I am also not seeing the benefit of pushing two RFCs that are in the >> process of being merged to something better than the sum of their = parts >> before that merge is successful. And like Ole mentioned wouldn't it = fail >> on the errata point (2) from Tomek's original email anyway? >>=20 >> Jason >>=20 >> On 8/22/13 9:39 AM, "Ole Troan" wrote: >>=20 >>>> Unless we receive some additional comments from the WG, we will be >>>> forced to conclude that there is NO support for advancing these >>>> documents to Internet Standard. >>>>=20 >>>> Because of the time of year (perhaps the last of summer vacations), = we >>>> will wait until September 9th to make a final decision. But at the >>>> current rate of response, it does not look favorable. >>>=20 >>> I do not support advancing RFC3315/RFC3633 to Internet Standard. >>> reason being that I believe that there are errata that will lead to >>> interoperability problems. >>>=20 >>> cheers, >>> Ole >>>=20 >>>> -----Original Message----- >>>> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >>>> Sent: Monday, August 19, 2013 2:52 PM >>>> To: dhcwg@ietf.org >>>> Cc: Bernie Volz (volz) >>>> Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet >>>> Standard >>>>=20 >>>> On 12.08.2013 21:21, Bernie Volz (volz) wrote: >>>>> During the Berlin IETF-87 DHC WG session, it was suggested that we >>>>> initiate a standards action request to move RFC 3315 (and RFC = 3633), >>>>> which are presently Proposed Standards, to Internet Standard. = While we >>>>> plan to work on a 3315bis which would merge the work, it was = pointed >>>>> out by several people (include our Area Director) that there is >>>>> technically no need to wait for that to advance the standards. >>>>>=20 >>>>> The requirements for advancement are outlined in RFC 2026 and RFC = 6410 >>>>> (which removed Draft Standard). >>>>>=20 >>>>> Per RFC 6410: >>>>>=20 >>>>> The criteria are: >>>>>=20 >>>>> (1) There are at least two independent interoperating = implementations >>>>> with widespread deployment and successful operational = experience. >>>> There are many more than just two. >>>>=20 >>>>> (2) There are no errata against the specification that would cause = a >>>>> new implementation to fail to interoperate with deployed ones. >>>> There are known issues, e.g. those described in >>>> draft-ietf-dhc-dhcpv6-stateful-issues, but these are more of = annoyance, >>>> rather than interoperability breaking problems. New implementations = are >>>> interoperating with existing ones without problems. >>>>=20 >>>>> (3) There are no unused features in the specification that greatly >>>>> increase implementation complexity. >>>> That's an interesting question. Are there any implementations that >>>> implement the whole RFC3315? I mean really everything: = reconfiguration, >>>> reconfigure-key, delayed auth, replay detection, sending CONFIRM = when >>>> link state changes, sending DECLINE if DAD fails, rapid-commit, >>>> supporting 32 relays, all 3 duid types etc.? >>>>=20 >>>> That's a trick question. I have my own answer for it, but I'd like = to >>>> hear WG opinion on that matter. >>>>=20 >>>>> (4) If the technology required to implement the specification >>>>> requires patented or otherwise controlled technology, then the >>>>> set of implementations must demonstrate at least two = independent, >>>>> separate and successful uses of the licensing process. >>>> There are no IPRs claimed against RFC3315 and RFC3633. >>>>=20 >>>> Ok, so in my opinion all criteria are met. >>>>=20 >>>>> Please provide input as to whether you support making this request = of >>>>> the IETF/IESG (via the Internet Area Directors) or whether you = feel >>>>> there are issues (based on the above criteria). If you feel one >>>>> document is ready but the other isn't, please let us know about = that >>>>> too. >>>> I feel that we should move forward with this for both 3315 and = 3633. >>>> There's almost 7000 RFCs published, but there are only 96 that have >>>> Internet Standard status. I strongly believe that DHCPv6 is one of = core >>>> Internet protocols. This status change would reflect that. >>>>=20 >>>> With my chair on, I'm disappointed that nobody responded to this = mail >>>> so far. Chairs got couple comments off the list, but nobody said >>>> anything on the list. I don't know, perhaps people are not that = much >>>> interested, because this move does not have any immediate practical >>>> repercussions. >>>> Or perhaps it is a middle of vacation time... >>>>=20 >>>> Come on, guys. Saying +1 doesn't take much time. ;-) >>>>=20 >>>> Tomek >>>>=20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>=20 >>=20 >> This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Thu Aug 29 02:52:42 2013 Return-Path: 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 A0C7721F9E3A for ; Thu, 29 Aug 2013 02:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gciRW9T+8Jog for ; Thu, 29 Aug 2013 02:52:41 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8339221F856A for ; Thu, 29 Aug 2013 02:52:41 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so708471pab.10 for ; Thu, 29 Aug 2013 02:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=GJFdO3ptDQXsHaVmtRH9LnRKLdbG98x7XQBETMC90Fk=; b=ogv+vVUC0fSaoppqaiXW/VQ0PLHsf7uFSv8+GtzwA6NRKu72AI+8wSCB1phDZSeOLG L7SO29WhKe0YxNIuhKxSt7wXISzkxl14ASrlygOYUgdqprb4xwwtHP6sNuXnx4L+Tdr+ rwDJ4Nv2KOD7/XEnzgXgFur5R/q9bZNEXP+y0kEH//0Z+Qy3agtWSv1YBxulNgvG5iZe ZCoqxmSJ5elMsKrq8y0rgifrneBwvoTHoCyR1CFj+cKk0vNew5Rtw0A4JKMZLuxkDb7z IPatpwLK8+lA4nt/RkoCMLhvUkR8wOv7POMCn/CXVKJL67zv4V8bL4h9RYsq3AyyuvFU PmTA== X-Received: by 10.68.194.104 with SMTP id hv8mr2549348pbc.168.1377769957533; Thu, 29 Aug 2013 02:52:37 -0700 (PDT) Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id ia5sm36845566pbc.42.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 02:52:36 -0700 (PDT) From: "Leaf Yeh" To: "'Alexandru Petrescu'" , References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> <5217763C.8010702@gmail.com> In-Reply-To: <5217763C.8010702@gmail.com> Date: Thu, 29 Aug 2013 17:52:29 +0800 Message-ID: <521f19e4.05c3440a.2ddc.ffff826b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6gD+XCgGiM91qiS0ioVT2YHuvqZQAB7kTw Content-Language: zh-cn Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 09:52:42 -0000 Indeed, the draft might need more text on the Problem Statement for the convincing power & easy understanding ... I guess the PS text should focus on the requirement of route aggregation = on PE for the customer's PD prefixes and the possible solutions ... Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Alexandru Petrescu Sent: Friday, August 23, 2013 10:48 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? Le 23/08/2013 14:29, Leaf Yeh a =E9crit : [...] > That sounds a new chapter of this draft. I suspect I will have a=20 > chance to join. :-) LOL :-) What would be the toc of this DHCPv6 Prefix Delegation and Relay Problem Statement? Alex > > > Best Regards, > Leaf > > > > ---------------------------------------------------------------------- > ------ > ------------------------------------------------------------ > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = > Of Bernie Volz (volz) > Sent: Friday, August 23, 2013 7:20 PM > To: mohamed.boucadair@orange.com > Cc: Ralph Droms; dhcwg@ietf.org WG > Subject: Re: [dhcwg] Anyone interested in continuing=20 > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > BTW - I think I may have indicated this before, but does this really=20 > avoid the need for configuration on the router (relay)? How are items=20 > such as the link-address and next hop (dhcp server) addresses=20 > configured (rfc 3315 has a multicast default)? So there is still a=20 > bunch of "manual" configuration required? Admittedly you do say "more=20 > automation" but not really sure that has a lot of value - perhaps we = need a Dynamic Router Configuration BOF? > > - Bernie (from iPad) > > On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" > wrote: > Hi Roberta, > > Yes, as indicated in the document, manual configuration is an option.=20 > but it has its limits too. > > This proposal is a contribution to add more automation to network=20 > configuration without requiring an additional dynamic protocol to=20 > drive how aggregates are built in a router co-located with a=20 > requestor, and therefore interact in a more dynamic fashion with a=20 > routing protocol (e.g., drive route withdrawals, etc.). > > Of course, some routers can offer some features to optimize the size=20 > of routing tables and prevent from injecting (very) specific entries.=20 > But still this behavior is implementation-specific and does not=20 > provide the same aggregation level as the one proposed in this = document. > > Unlike implementation-specific behaviors, this proposal is=20 > deterministic since it is fully controlled by the entity which has the = > full knowledge of prefix related states and network policies: e.g.,=20 > the server has the knowledge of prefix assignment, prefix assignment=20 > policies, prefix aggregates, etc. > > I confirm this option is not a per-customer configuration parameter. > > Cheers, > Med > > > De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoy=E9 : jeudi = 22=20 > ao=FBt 2013 22:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms;=20 > dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing=20 > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Hello, > Maybe I'm missing something here, but I'm struggling to see the value=20 > added by this new option in terms of route aggregation functionality. > Today with IPv4 if I need to summarize some routes I manually=20 > configure on the router a summary/aggregate route and I announce it=20 > into the routing protocol. Moving to IPv6 you could do the same thing, = > I don't quite get what's wrong with that? > You say you would like to have an automatic way to tell the PE to=20 > aggregate the routes, but if I understand correctly the proposal what=20 > you are doing here is only moving the configuration of the summary=20 > route from the PE to the DHCPv6 Server; what do you really save here? > In addition the route aggregation is not a per customer configuration, = > it would be per box or per service configuration so why do you want to = > add it to customers' profile in DCHPv6 Server? > Thanks > Roberta > > On Thu, Aug 22, 2013 at 9:45 AM, wrote: > Re-, > > IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same=20 > objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. > > draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means=20 > to trigger route advertisement actions and to control the route=20 > aggregates to be injected using a routing protocol. For example, a=20 > router can be told by the DHCP server to advertise an aggregate even=20 > if not all individual prefixes are assigned to customer located behind = > that router. This is a measure that can help in optimizing routing=20 > tables and avoid injecting very specific routes. Snooping the=20 > assignment and then guide the route advertisement actions may not be=20 > lead to the same optimized routing tables, because there will be = "holes" that will prevent aggregating routes. > > Having an explicit channel like the one specified in=20 > draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. > > Cheers, > Med > > >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la=20 >> part de Ralph Droms Envoy=E9 : jeudi 22 ao=FBt 2013 14:48 =C0 : = Alexandru=20 >> Petrescu Cc : dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested = >> in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >> >> >> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu=20 >> wrote: >> >>> Hi, >>> >>> One point I think is essential is the installment of routes in the=20 >>> DHCP Relay upon Prefix Assignment. >>> >>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP=20 >>> must install a route in the DHCP Relay upon delegation. >>> >>> This draft seems to at least assume it, and to describe much more=20 >>> about >>> it: how various parts of assigned prefixes are aggregated and >> communicated. >>> >>> I support it. >> >> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to=20 >> have been aimed at the same problem. If I have that right, it might=20 >> be instructive to review the dhc WG mailing list discussion that lead = >> to the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate. >> >> - Ralph >> >>> >>> Alex >>> >>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a =E9crit : >>>> Hi Tomek, >>>> >>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a=20 >>>> useful feature in order to have more automation and also control=20 >>>> routes aggregation instead of relying on proprietary behaviors of=20 >>>> each implementation. Of course, part of these objectives can be=20 >>>> achieved if routes are installed manually or use an out of band=20 >>>> mechanism to enforce routing aggregation policies. Still, the=20 >>>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior=20 >>>> because the DHCP server has the knowledge of the prefix=20 >>>> assignments; and therefore routes can be triggered with dhcpv6 . >>>> >>>> A way to progress with this document is to target the Experimental=20 >>>> track. Based on the experience that will be gained in real=20 >>>> deployments, the status can be revisited if required. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org=20 >>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski=20 >>>>> Envoy=E9 : lundi 19 ao=FBt 2013 16:52 =C0 : dhcwg Objet : [dhcwg] = Anyone=20 >>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>> >>>>> During Berlin meeting chairs asked if there is still interest in=20 >>>>> the prefix-pool-option. There was nobody interested in the work in = >>>>> the room. The unanimous consensus in the room was to drop it. I=20 >>>>> just wanted to confirm that on the list. >>>>> >>>>> If you are interested in this work, want to support it and=20 >>>>> participate in it, please let us know by replying to the mailing=20 >>>>> list. Otherwise we'll drop this work and mark that draft as a dead = >>>>> WG document. >>>>> >>>>> Please respond within 2 weeks (until Sep. 2nd). >>>>> >>>>> Bernie & Tomek _______________________________________________ >>>>> dhcwg mailing list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> _______________________________________________ dhcwg mailing list=20 >>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>>> >>> >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Thu Aug 29 03:14:38 2013 Return-Path: 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 D3A9421F9BBF for ; Thu, 29 Aug 2013 03:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmBf1AvRBt48 for ; Thu, 29 Aug 2013 03:14:33 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 387F721F9BAD for ; Thu, 29 Aug 2013 03:14:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7TAEUU9021815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Aug 2013 12:14:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7TAEUwU008770; Thu, 29 Aug 2013 12:14:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7TAEE8j022531; Thu, 29 Aug 2013 12:14:30 +0200 Message-ID: <521F1EF6.5020406@gmail.com> Date: Thu, 29 Aug 2013 12:14:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Leaf Yeh References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> <5217763C.8010702@gmail.com> <521f19e4.05c3440a.2ddc.ffff826b@mx.google.com> In-Reply-To: <521f19e4.05c3440a.2ddc.ffff826b@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:14:39 -0000 Hello Leaf, Problem statement text in the solution draft is one possible alternative. Another alternative is to start from scratch a problem statement draft that would cover the pool-opt draft as well as others mentioned in the thread. Not sure which way to go better. Alex Le 29/08/2013 11:52, Leaf Yeh a écrit : > Indeed, the draft might need more text on the Problem Statement for > the convincing power & easy understanding ... > > I guess the PS text should focus on the requirement of route > aggregation on PE for the customer's PD prefixes and the possible > solutions ... > > > Best Regards, Leaf > > > > -----Original Message----- From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Friday, August 23, 2013 10:48 PM To: dhcwg@ietf.org Subject: Re: > [dhcwg] Anyone interested in continuing > draft-ietf-dhc-dhcpv6-prefix-pool-opt? > > Le 23/08/2013 14:29, Leaf Yeh a écrit : [...] >> That sounds a new chapter of this draft. I suspect I will have a >> chance to join. :-) LOL :-) > > What would be the toc of this DHCPv6 Prefix Delegation and Relay > Problem Statement? > > Alex > >> >> >> Best Regards, Leaf >> >> >> >> ---------------------------------------------------------------------- >> >> ------ >> ------------------------------------------------------------ From: >> dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >> Bernie Volz (volz) Sent: Friday, August 23, 2013 7:20 PM To: >> mohamed.boucadair@orange.com Cc: Ralph Droms; dhcwg@ietf.org WG >> Subject: Re: [dhcwg] Anyone interested in continuing >> draft-ietf-dhc-dhcpv6-prefix-pool-opt? >> >> BTW - I think I may have indicated this before, but does this >> really avoid the need for configuration on the router (relay)? How >> are items such as the link-address and next hop (dhcp server) >> addresses configured (rfc 3315 has a multicast default)? So there >> is still a bunch of "manual" configuration required? Admittedly you >> do say "more automation" but not really sure that has a lot of >> value - perhaps we need > a Dynamic Router Configuration BOF? >> >> - Bernie (from iPad) >> >> On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com" >> wrote: Hi Roberta, >> >> Yes, as indicated in the document, manual configuration is an >> option. but it has its limits too. >> >> This proposal is a contribution to add more automation to network >> configuration without requiring an additional dynamic protocol to >> drive how aggregates are built in a router co-located with a >> requestor, and therefore interact in a more dynamic fashion with a >> routing protocol (e.g., drive route withdrawals, etc.). >> >> Of course, some routers can offer some features to optimize the >> size of routing tables and prevent from injecting (very) specific >> entries. But still this behavior is implementation-specific and >> does not provide the same aggregation level as the one proposed in >> this document. >> >> Unlike implementation-specific behaviors, this proposal is >> deterministic since it is fully controlled by the entity which has >> the full knowledge of prefix related states and network policies: >> e.g., the server has the knowledge of prefix assignment, prefix >> assignment policies, prefix aggregates, etc. >> >> I confirm this option is not a per-customer configuration >> parameter. >> >> Cheers, Med >> >> >> De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoyé : jeudi >> 22 août 2013 22:31 À : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; >> dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in >> continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt? >> >> Hello, Maybe I'm missing something here, but I'm struggling to see >> the value added by this new option in terms of route aggregation >> functionality. Today with IPv4 if I need to summarize some routes I >> manually configure on the router a summary/aggregate route and I >> announce it into the routing protocol. Moving to IPv6 you could do >> the same thing, I don't quite get what's wrong with that? You say >> you would like to have an automatic way to tell the PE to aggregate >> the routes, but if I understand correctly the proposal what you are >> doing here is only moving the configuration of the summary route >> from the PE to the DHCPv6 Server; what do you really save here? In >> addition the route aggregation is not a per customer >> configuration, it would be per box or per service configuration so >> why do you want to add it to customers' profile in DCHPv6 Server? >> Thanks Roberta >> >> On Thu, Aug 22, 2013 at 9:45 AM, >> wrote: Re-, >> >> IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the >> same objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt. >> >> draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic >> means to trigger route advertisement actions and to control the >> route aggregates to be injected using a routing protocol. For >> example, a router can be told by the DHCP server to advertise an >> aggregate even if not all individual prefixes are assigned to >> customer located behind that router. This is a measure that can >> help in optimizing routing tables and avoid injecting very specific >> routes. Snooping the assignment and then guide the route >> advertisement actions may not be lead to the same optimized routing >> tables, because there will be "holes" > that will prevent aggregating routes. >> >> Having an explicit channel like the one specified in >> draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO. >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>> [mailto:dhcwg-bounces@ietf.org] De la part de Ralph Droms Envoyé >>> : jeudi 22 août 2013 14:48 À : Alexandru Petrescu Cc : >>> dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in >>> continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>> >>> >>> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu >>> wrote: >>> >>>> Hi, >>>> >>>> One point I think is essential is the installment of routes in >>>> the DHCP Relay upon Prefix Assignment. >>>> >>>> The base DHCPv6 Prefix Delegation RFC does not stipulate that >>>> DHCP must install a route in the DHCP Relay upon delegation. >>>> >>>> This draft seems to at least assume it, and to describe much >>>> more about it: how various parts of assigned prefixes are >>>> aggregated and >>> communicated. >>>> >>>> I support it. >>> >>> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems >>> to have been aimed at the same problem. If I have that right, it >>> might be instructive to review the dhc WG mailing list discussion >>> that lead to the abandonment of >>> draft-ietf-dhc-dhcpv6-agentopt-delegate. >>> >>> - Ralph >>> >>>> >>>> Alex >>>> >>>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a écrit : >>>>> Hi Tomek, >>>>> >>>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt >>>>> documents a useful feature in order to have more automation >>>>> and also control routes aggregation instead of relying on >>>>> proprietary behaviors of each implementation. Of course, part >>>>> of these objectives can be achieved if routes are installed >>>>> manually or use an out of band mechanism to enforce routing >>>>> aggregation policies. Still, the proposal in >>>>> draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because the >>>>> DHCP server has the knowledge of the prefix assignments; and >>>>> therefore routes can be triggered with dhcpv6 . >>>>> >>>>> A way to progress with this document is to target the >>>>> Experimental track. Based on the experience that will be >>>>> gained in real deployments, the status can be revisited if >>>>> required. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org >>>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek >>>>>> Mrugalski Envoyé : lundi 19 août 2013 16:52 À : dhcwg Objet >>>>>> : [dhcwg] Anyone interested in continuing >>>>>> draft-ietf-dhc-dhcpv6- prefix-pool-opt? >>>>>> >>>>>> During Berlin meeting chairs asked if there is still >>>>>> interest in the prefix-pool-option. There was nobody >>>>>> interested in the work in the room. The unanimous consensus >>>>>> in the room was to drop it. I just wanted to confirm that >>>>>> on the list. >>>>>> >>>>>> If you are interested in this work, want to support it and >>>>>> participate in it, please let us know by replying to the >>>>>> mailing list. Otherwise we'll drop this work and mark that >>>>>> draft as a dead WG document. >>>>>> >>>>>> Please respond within 2 weeks (until Sep. 2nd). >>>>>> >>>>>> Bernie & Tomek >>>>>> _______________________________________________ dhcwg >>>>>> mailing list dhcwg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>> _______________________________________________ dhcwg mailing >>>>> list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ dhcwg mailing >>>> list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> >> > > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > > From tomasz.mrugalski@gmail.com Thu Aug 29 08:22:59 2013 Return-Path: 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 F1BF711E811B for ; Thu, 29 Aug 2013 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNyPhTHFSmJD for ; Thu, 29 Aug 2013 08:22:58 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 215B411E811A for ; Thu, 29 Aug 2013 08:22:57 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h14so323512eak.15 for ; Thu, 29 Aug 2013 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=jRoSX5ZrLWQsfVI94/+aiOz9rSWpm366sf/t4doRrqM=; b=QPqPt24E40TteB0VECwo7Tztr15fOsbNECE2q4G40AUMaaSbmz2uHgyydU5EEtuWVv dEccu8LrRKPQ9YSYsZs/nknlulOTDmBeUKCxoH8OUdOZd4CDIPELmIAO54OmDICDW9mS CHDhIwZvJ+9Et9z7o/a/RjKnR709TSmSMKNElUtQCHwu9iuUflFL18PI2ts9xeqwemaQ L0kpFDx4XQCEltLRdURNNwBTMoA9FZXfL3hFd6KjWZIV0SugIuJ6OeVjVeFJDaCBmHae G+SUwTMPf+9NG3FicK0Tg7BfYDxb9AglLSdq90ybdL7Oe1OAFAdMMZctVw6NXyAGGkEI Fc5Q== X-Received: by 10.14.218.197 with SMTP id k45mr5201713eep.32.1377789777115; Thu, 29 Aug 2013 08:22:57 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id r48sm46968281eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:22:56 -0700 (PDT) Message-ID: <521F674B.1020209@gmail.com> Date: Thu, 29 Aug 2013 17:22:51 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Updated WG milestones X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:22:59 -0000 The charter proposal that we discussed in Berlin (and on the list before and after) has been submitted to IESG. One of the concerns raised during IESG review was that our milestones are hopelessly outdated (the last milestone was for 2008). We have removed old milestones and put up the new ones we have received so far from authors. That list is not complete yet. Our changes are awaiting AD approval. We are still expecting some changes. If you are working on a draft and want a milestone related to it, please send your proposed milestones to the chairs. Bernie & Tomek From Ted.Lemon@nominum.com Thu Aug 29 10:18:57 2013 Return-Path: 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 787F221E804E for ; Thu, 29 Aug 2013 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF3lIWOWX3d6 for ; Thu, 29 Aug 2013 10:18:50 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65D21E80A1 for ; Thu, 29 Aug 2013 10:18:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUh+CdA9YP23LODs9YTViP+R7HfaaADNp@postini.com; Thu, 29 Aug 2013 10:18:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 834F61B82D4 for ; Thu, 29 Aug 2013 10:18:44 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 36678190070; Thu, 29 Aug 2013 10:18:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 10:18:36 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Updated WG milestones Thread-Index: AQHOpMu2Q6xgESezj0C+/HcWlxmzupms41SA Date: Thu, 29 Aug 2013 17:18:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077526C293@mbx-01.win.nominum.com> References: <521F674B.1020209@gmail.com> In-Reply-To: <521F674B.1020209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E69FD9789D2394BA546CD48512FF197@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] Updated WG milestones X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:18:57 -0000 On Aug 29, 2013, at 11:22 AM, Tomek Mrugalski = wrote: > The charter proposal that we discussed in Berlin (and on the list before > and after) has been submitted to IESG. FYI, the charter has been approved (with some tweaks) for external review, = which will involve a one-week last call on the IETF mailing list. People = in the working group who are interested in this should subscribe to the IET= F mailing list so that they can participate in the last call discussion. From internet-drafts@ietf.org Thu Aug 29 11:48:51 2013 Return-Path: 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 37DBB21E80A3; Thu, 29 Aug 2013 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+PUd3NvOsvm; Thu, 29 Aug 2013 11:48:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3E11E8131; Thu, 29 Aug 2013 11:48:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829184850.24988.76675.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2013 11:48:50 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 18:48:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Registering self-generated IPv6 Addresses in DNS using D= HCPv6 Author(s) : Sheng Jiang Gang Chen Suresh Krishnan Filename : draft-ietf-dhc-addr-registration-03.txt Pages : 8 Date : 2013-08-29 Abstract: In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated addresses in DNS through a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-addr-registration-03 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/ From iesg-secretary@ietf.org Fri Aug 30 09:53:02 2013 Return-Path: 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 EBFF221E808F; Fri, 30 Aug 2013 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPwW6BPFFuCT; Fri, 30 Aug 2013 09:53:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1586721F9FF1; Fri, 30 Aug 2013 09:53:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130830165300.16729.46895.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 09:53:00 -0700 Cc: dhc WG Subject: [dhcwg] WG Review: Dynamic Host Configuration (dhc) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:53:02 -0000 The Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-09. Dynamic Host Configuration (dhc) ------------------------------------------------ Current Status: Active WG Chairs: Bernie Volz Tomek Mrugalski Assigned Area Director: Ted Lemon Mailing list Address: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/ Charter: Proposed Updated DHC WG Charter (August 26, 2013) ------------------------------------------------- The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Failover, High Availability and Load Balancing - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Access Network Identifier - DNS registration for SLAAC Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop a replacement for OPTION_NTP_SERVER (RFC 5908). The DHC working group will develop this option, taking input from the NTP working group during the development process. Last call on this option will be done in the DHC working group. 3. Specify guidelines for creating new DHCPv6 options. 4. Develop documents that help explain operational considerations for the wider community. 5. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 6. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 7. Write analyses and interoperability reports on existing DHC documents, including base specs. 8. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those problems to address the interoperability problems. Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed