Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
"Bernie Volz (volz)" <volz@cisco.com> Sun, 08 April 2012 21:26 UTC
Return-Path: <volz@cisco.com>
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 3EF9721F8450 for <dhcwg@ietfa.amsl.com>; Sun, 8 Apr 2012 14:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level:
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 jwEQAm9NGsJ6 for <dhcwg@ietfa.amsl.com>; Sun, 8 Apr 2012 14:26:49 -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 1813021F844E for <dhcwg@ietf.org>; Sun, 8 Apr 2012 14:26:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7356; q=dns/txt; s=iport; t=1333920409; x=1335130009; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KLvlR+/+Sjde8zK+v9FPf3uWsp1mhpT65Iwanorw4F4=; b=Nc/FC95SgMhTtlv6mRILp77rj/MHRkidBOWll5MhNCuKRUggErzbdH1x Jl2EbFpGTg6CtD91V+5s/n1JRkm2Pt/zDiRgjOZWDuiTPU9vdOLxu3z5Y dJv3IL5J7ZhZqdIc4O/RzkfHg1c2LXjMZSc3CncK1m98ltxpbBEonMdTg U=;
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="69976479"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Apr 2012 21:26:48 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q38LQm9i013410; Sun, 8 Apr 2012 21:26:48 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 16:26:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 08 Apr 2012 16:26:47 -0500
Message-ID: <D9B5773329187548A0189ED6503667890BCAFBE2@XMB-RCD-101.cisco.com>
In-Reply-To: <4F81BA73.4000400@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
Thread-Index: Ac0Vo1FUC+sddg0sScatsbgk57mmYgAKSwPA
References: <D9B5773329187548A0189ED6503667890B9F42CB@XMB-RCD-101.cisco.com> <4F81BA73.4000400@gmail.com>
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg@ietf.org, Ole Troan <ot@cisco.com>
X-OriginalArrivalTime: 08 Apr 2012 21:26:48.0509 (UTC) FILETIME=[4E5286D0:01CD15CE]
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2012 21:26:50 -0000
Tomek: Regarding 0, no. This work would be folded into 3315bis but it should proceed separately. Primarily because it is needed "now" and the 3315bis work will probably be at a much slower pace. Regarding the other issues, NA/PD are primary target. TA isn't renewed so it has fewer issues. But, we will look to improving the situation for multiple IA options. And, can consider others that are in various stages of being proposed. I am not sure we can cover all cases as I'm sure anything we conclude might have to be revisited in the future when a new type comes along. This work is really related to 6204bis and the fact that the cable market needs the router behavior to be clarified. Thanks for your other points and we'll review and incorporate or comment on the list as appropriate. I have not reviewed the extensive list in details - I just wanted to send out a note to make the 'scope' of the work a bit clearer. I will add that for: >11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? No. If the text implies that it will need to be cleaned up. Once you RELEASE that's it. What it was supposed to communicate is that the client can RELEASE the IA_NA, for example, and then do a RENEW with the IA_PD and the IA_NA to get a different address. This is not renewing the existing address. It isn't really clear why a client would release one lease type but not the other, so this case is probably not likely. The more likely cases is that the client finds a DAD conflict or other issue with the address and much DECLINE it ... and rather than having to go back to Solicit, this allows the client the ability to RENEW the IA_PD and include the IA_NA to get a new address (that hopefully won't have the DAD or other conflict). Note that in this RENEW, the IA_NA would not have an IA_ADDR option (or if it does, it would be the unspecified address). - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Sunday, April 08, 2012 12:19 PM To: dhcwg@ietf.org; Ole Troan Cc: Bernie Volz (volz) Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item On 12-04-05 19:25, Bernie Volz (volz) wrote: > I kindly request that we adopt this document as a DHC WG work item. I do support this work and its adoption. I also have couple of comments: 0. Would it be reasonable to name this work 3315bis? 1. I assume this work will also cover all combinations of IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors should take a closer look at it. (I'm sorry I can't offer any better comments here. I haven't read host-gen-id yet). 2. stateful-issues draft is a very useful work. Once adopted it should also look at CGA issues - my understanding is that it basically degrades DHCP into registration service, compared to normal assignment service. I haven't read CGA drafts recently, so again this is only a pointer to something that should be looked at. It is possible that there's nothing to do in that matter. 3. Abstract could be reworded: "the ne options for Prefix Delegation options for DHCPv6 into DHCPv6" part is repetitive. The same is true for first paragraph of Introduction section. 4. Text refer to different IA options as IA_. I think it would look better without the underscore. If that is not clear, perhaps it could be clarified that "IA option" means any of IA_NA, IA_TA or IA_PD. 5. Section 3.1 states that client MUST ignore IAs with status code NoAddrAvail. That doesn't help much. What about other status codes? IA_PD may be returned with NoPrefixAvail. Much better would be to say that client MUST ignore IAs with status code other than Success. We should also add that client SHOULD rate advertise without assigned IAs lower than other advertises, but exact advertise rating algorithm is up to client imlementors. For example, I would implement a client that accepts advertise with preference=5 and all IAs assigned rather than one with preference=10, but without IA_NA or IA_PD assigned. 6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail, NoPrefixAvail and NotOnLink) should appear within IA options. It would be better to not explicitely limit to those 3 status code, but say all non-success status codes to maintain forward compatibility. Something like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success status codes" will do. BTW you missed UnspecFail code that is already defined and could be used, so the text as it is does not cover all situations from day 1. 7. It should be clarified that status codes are specified per instance of an option, not per option type. Think about client that sends 3 IA_NA options. It can receive 2 addresses and NoAddrAvail in the third instance. That could be either due to pool depletion (unlikely) or server policy that allow server to assign no more than 2 addresses per client (likely). 8. Proposed replacement errata in section 3.2 should clarify that such proposed action should be taken on each IA being answered. 9. Section 3.3 could mention relation between T1/T2 and information refresh option (RFC4242). The reasonable clarification would be that client MAY request other options in ORO when sending RENEW or REBIND. 10. Allowing PD to be confirmed with CONFIRM could be tricky. In many deployment scenarios routing is configured separately for each delegated prefix and server can't really say "yeah, I've never assigned you that one, but it should be valid on your link.". I don't object allowing IA_PD in CONFRIM, but it should be accompanied with a clause that server MUST include IA_PD response only if it is certain that delegated prefix is really valid. This will complicate things. What is client sends CONFIRM with IA_NA and IA_PD and server can confirm that address is on-link, but is not sure about prefix? There's no such status as IdontKnow. Different IA combinations should be given more thought. 11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? If that is the case, I strongly object. Once client released a lease, it has no further claims to released address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST, not RENEW. Also. Section 3.5 title mentions DECLINE, but there is nothing about DECLINE in the text. Authors probably forgot adding a sentence that DECLINE may be sent at any time when client owns a lease. 12. A question about proposed operation in section 3.6. What if there are two servers. Imagines a case with 2 servers: one that provides addresses and second one that provides prefixes. Client requests IA_NA and IA_PD. What should client do? 13. In 3rd paragraph in section 3.6 it would be better to say non-success status codes rather than NoAddrsAvail (or at least NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail). 14. Section 3.7 is the most unfortunate. I understand the reasons that led authors to that decision, so I sadly accept it. Despite my comments, I strongly support this work and it adoption. It is great that we will get this thing clarified. Greetings to all woods dwellers, Tomek
- [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6… Ted Lemon
- [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-iss… Bernie Volz (volz)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Kim Kinnear
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Daryl Tanner
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Dedecker Hans
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Timothy Winters
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Tina TSOU
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Chris Donley
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Hans Liu
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Tomek Mrugalski
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Tomek Mrugalski
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… STARK, BARBARA H
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bud Millwood
- [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-d… Ted Lemon
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Weil, Jason
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Tomek Mrugalski
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Ted Lemon
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Leaf yeh
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Ted Lemon