Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Leaf yeh <leaf.y.yeh@huawei.com> Tue, 28 August 2012 13:22 UTC
Return-Path: <leaf.y.yeh@huawei.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 5240621F8497 for <dhcwg@ietfa.amsl.com>; Tue, 28 Aug 2012 06:22:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN0KFGyu4OhQ for <dhcwg@ietfa.amsl.com>; Tue, 28 Aug 2012 06:22:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6321F8466 for <dhcwg@ietf.org>; Tue, 28 Aug 2012 06:22:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJC22855; Tue, 28 Aug 2012 13:22:38 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 14:21:57 +0100
Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 21:22:09 +0800
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Tue, 28 Aug 2012 21:22:04 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Thread-Index: AQHNgiXnOAnjjw7Zjk+PytbTkNCew5duyIKQ
Date: Tue, 28 Aug 2012 13:22:03 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C467217@SZXEML510-MBS.china.huawei.com>
References: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C44F9B5@SZXEML510-MBS.china.huawei.com> <5037C726.2070406@gmail.com>
In-Reply-To: <5037C726.2070406@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
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: Tue, 28 Aug 2012 13:22:42 -0000
Hi Tomek, Your comment looks always thorough. I will find more time to review all the below comments for the update of draft (OPTION_PREFIX_POOL) to ver.-09. The following are my feedback to some of your comments on the text of the draft: Tomek - Multiple prefix pools seem to be allowed (section 6, paragraph 7 suggests that). It may be useful to note that multiple prefix pools must not overlap. 1. Accepted. The replaced text in Section 6 will be "Note that these prefix pools does not overlay, the delegated prefix is only from one prefix pool." Tomek - There are many normative looking words (must, shall etc.) that are not capitalized. 2. Accepted. In fact, I will capitalize all of the 'must, should and may' in the draft. Tomek - In its current form it allows server to make strange things like make the pool active when responding to RELEASE or saying that the pool is released when assigning a prefix in response to REQUEST. Yes, when the administrator of the server turn on the setting to support route aggregation on the relay, the server may add the aggregation route through the OPTION_PREFIX_POOL in the RELAY-REPL message of the REPLY to the RELEASE when the released PD prefix is not the last PD prefix in the pool; when the administrator of the server turn off the setting to support route aggregation on the relay, the server may withdraw the aggregation route in response to REQUEST of PD. Tomek - That draft was written in BBF networks in mind, but it can be used in a general case as well. A statement to point that out should be added. I believe the draft (OPTION_PREFIX_POOL) has already used the language of IETF, just referred to BBF TR-177 in the introduction, it may emphasize the case when the PE router acts as DHCPv6 relay. Tomek - Section 1: This is really a nit-pick style comment "The DHCPv6 protocol". I always have problem how to write it. Adding protocol after DHCP is redundant, as P in DHCP stands for protocol. On the other hand, removing "protocol" would make it less readable by people who don't know what DHCP acronym stands for. I think it probably should stay as it is. It could be either as you want. Tomek - Section 1, second paragraph. You mentiond RRs without defining that acronym. Although it is later explained in section 2, it would be good to replace its first use with "Requesting Router (RR)". The 1st paragraph has the text of '... the Requesting Routers (RR) acting as the DHCPv6 Clients'. Tomek - Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460] specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent)". While requestor is typically the relay agent, it doesn't have to be. It may be a separate entity as well. I would replace "i.e." with "typically". 3. Accepted. The text will turn to be '..., typically a DHCPv6 relay agent,...'. Tomek - Section 1, the last paragraph. "The automatic mechanisms described in this document depends". It should be "mechanism depends" or "mechanisms depend". 4. Thanks for your carefulness. Accepted. Tomek - Section 2, Requestor definition. RFC5007 defines requestor as a note that sends leasequery messages. While it is typically a router, it doesn't have to be one. Requestor may be a separate tool that can be run on hosts or routers alike. 5. Accepted. The text will turn to be ' Requestor: A node defined in [RFC5007] that acts as the leasequery client. ' Tomek - Section 4. ipv6-prefix should be of variable length. In most cases the prefix used here will be /56 or even shorter. That will result in at least 9 bytes being zeros. BTW This approach will be recommended in the next version of draft-ietf-dhc-option-guidelines. 6. Accepted. The text will turn to be as follows: 'option-length: 2 + length of ipv6-prefix (in Octets) pfx-pool-len: Length for the prefix pool in bits ... ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero.' Tomek - Section 4. It is customary to include list of messages that MAY/MUST NOT include that option. Something like "Server MAY include this option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO option in RELAY-FORW. It MUST NOT appear in any messages sent by clients. It MAY/MUST NOT appear in LEASEQUERY message.". 7. Accepted. The text will turn to be ' DHCPv6 server MAY include this option in the RELAY-FORW (12), RELAY-REPL (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message. ' Tomek - Section 4. "If the administrative policy on the server does not permit to support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'." Wouldn't it be better to just not include OPTION_PREFIX_POOL? The server needs include OPTION_PREFIX_POOL per the request in ORO from the relay to withdraw the aggregation route. Tomek - Section 5, second paragraph. "The relay agent should include the Interface ID option". Is this normative language? I think it is, so it should be "SHOULD". Same as the one above. Accepted. Tomek - Section 5. Consider the following scenario: There are X requesting routers behind a relay. Server is configured to allow route aggregation, so pool option is sent. Then administrator decides to stop using aggregation, so he turns it off. When X+1 client comes in, the server does not send PREFIX_POOL anymore, so according to paragraph 4 in section 5, relay must withdraw the associated route. How are the first X clients reachable? I suppose the relay must keep routes to them anyway and the one received in PREFIX_POOL is an additional one, not a replacement, right? a. When X+1 client comes in, the server still send OPTION_PREFIX_POOL per the ORO from the reply to withdraw the aggregation route. If the relay lose the message from the server by accident, then it could use the 'aging' (self-healing) mechanism to withdraw the aggregation route. b. The first X clients are still reachable per the PD process, because the PE router still have the specified route for each active PD customer prefix. c. Yes, the aggregation route per the OPTION_PREFIX_POOL is the additional route entry in the routing table of the PE router. Tomek - Section 6, paragraph 2. "After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the PD". What does PD mean in this context? I think you meant "relay-forward messages that encapsulate messages with IA_PD options". It's awfully lot of words, but I'm not sure how to say it simpler. 8 . PD means DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]. It is definitely my fault that you can't read it. How about to change the text to be '... in the relay-forward messages of the DHCPv6-PD'. Accepted. Tomek - Section 6, paragraph 6. "When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool may change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease.". I think once administrator disables it, the server should always set status to released. The "if at least one..." part in not necessary. The original text has the meaning that when the sever is set to support the route aggregation on the relay, the status of the prefix pool is 'Active' if at least one delegated prefix within the prefix pool has the valid lease.' Right? Tomek - Section 6, paragraph 6. Why does the server have to send RECONFIGURE? So the relay can re-learn RR prefixes once aggregation has been disabled? It is related to my question about RR remembering (or not) the specific routes. Anyway, it would be less intrusive to say that relay must use leasequery to learn existing delegations than forcing all clients to do reconfigure, especially that for clients nothing will change. Also, keep in mind that RRs may not support reconfigure as it is an optional feature. a. The server send the RECONFIGURE when the status of the prefix pool changed after the administrator's setting. Yes, the relay get the chance to re-learn the status of the prefix pool. b. The RR might not be renumbered. c. RECONFIGURE sounds 1 of 3 configuration processes defined both in RFC3315/3633. If the RR may not support to immediately response RECONFIGURE (though I can't image it), we still can rely on the regular RENEW, right? Tomek - Section 7. Security consideration should also reference section 15 of RFC3633. 9 . Accepted. The text will turn to be 'Security issues related DHCPv6 are described in section 23 of [RFC3315] and section 15 of [RFC3633].' Tomek - Questions: 1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is split into /56 prefixes. Someone tries to reach a customer that is currently offline. What is PE supposed to do with those packets? Respond with ICMP type=1 code=0 (no route to destination)? PE router will act as the same as the usual after the packet arrive it when the customer network is unreachable. Tomek - Questions: 2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The admnistrative policy does not allow route aggregation, so OPTION_PREFIX_POOL has status set to release. Is PE allowed to aggregate both routes anyway and announce 2001:db8:1:8000::/63? Perhaps allowing such behaviour could be defined as status code = 2. I don't know if controlling this is a good idea, so feel free to ignore this suggestion. If administrative policy does not allow route aggregation, the PE router will act as the same as the usual. It will announce 2001:db8:1:8000::/63 in this case if the routing protocol is enabled on its network-facing interface. I don't believe we need more status code here. The other of your comments will be replied soon. Best Regards, Leaf -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Saturday, August 25, 2012 2:26 AM To: dhcwg Cc: Leaf yeh Subject: Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 On 30.07.2012 03:35, Leaf yeh wrote: > Dear DHC folks, > > The draft (ver.-08) & the proposed (OPTION_PREFIX_POOL) on the > agenda of IETF84 DHC session > (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ), is waiting > for your review and comments. Hi, You've asked for it, so here are my comments. Although there are many things mentioned below, I think the draft is a good idea. It is in a good shape and I support it. None of the things mentioned below are show-stoppers, and most can be easily fixed. I will send out separate mail to respond to adoption call. Generic comments: - Multiple prefix pools seem to be allowed (section 6, paragraph 7 suggests that). It may be useful to note that multiple prefix pools must not overlap. - There are many normative looking words (must, shall etc.) that are not capitalized. - Have you considered defining new leasequery query type: QUERY_BY_PREFIX_POOL? Server could return all leases that belong to specified prefix pool. I think it would be easier to implement one new query type than modifying the code for existing 3 query types. - Since your option affects how existing query types in leasequery work, the front page of the draft should have "updates RFC5007, 5460 (if approved)" clause. - I think I have commented on this before, but I can't find it anywhere, so I'll restate my concerns again. This is basically a signalling protocol on top of normal exchange. In its current form it allows server to make strange things like make the pool active when responding to RELEASE or saying that the pool is released when assigning a prefix in response to REQUEST. - That draft was written in BBF networks in mind, but it can be used in a general case as well. A statement to point that out should be added. Comments specific to the text: - Section 1: This is really a nit-pick style comment "The DHCPv6 protocol". I always have problem how to write it. Adding protocol after DHCP is redundant, as P in DHCP stands for protocol. On the other hand, removing "protocol" would make it less readable by people who don't know what DHCP acronym stands for. I think it probably should stay as it is. - Section 1, second paragraph. You mentiond RRs without defining that acronym. Although it is later explained in section 2, it would be good to replace its first use with "Requesting Router (RR)". - Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460] specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent)". While requestor is typically the relay agent, it doesn't have to be. It may be a separate entity as well. I would replace "i.e." with "typically". - Section 1, the last paragraph. "The automatic mechanisms described in this document depends". It should be "mechanism depends" or "mechanisms depend". - Section 2, Requestor definition. RFC5007 defines requestor as a note that sends leasequery messages. While it is typically a router, it doesn't have to be one. Requestor may be a separate tool that can be run on hosts or routers alike. - Section 4. ipv6-prefix should be of variable length. In most cases the prefix used here will be /56 or even shorter. That will result in at least 9 bytes being zeros. BTW This approach will be recommended in the next version of draft-ietf-dhc-option-guidelines. - Section 4. It is customary to include list of messages that MAY/MUST NOT include that option. Something like "Server MAY include this option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO option in RELAY-FORW. It MUST NOT appear in any messages sent by clients. It MAY/MUST NOT appear in LEASEQUERY message.". - Section 4. "If the administrative policy on the server does not permit to support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'." Wouldn't it be better to just not include OPTION_PREFIX_POOL? - Section 5, second paragraph. "The relay agent should include the Interface ID option". Is this normative language? I think it is, so it should be "SHOULD". - Section 5. Consider the following scenario: There are X requesting routers behind a relay. Server is configured to allow route aggregation, so pool option is sent. Then administrator decides to stop using aggregation, so he turns it off. When X+1 client comes in, the server does not send PREFIX_POOL anymore, so according to paragraph 4 in section 5, relay must withdraw the associated route. How are the first X clients reachable? I suppose the relay must keep routes to them anyway and the one received in PREFIX_POOL is an additional one, not a replacement, right? - Section 5. The last paragraph about leasequery should probably be moved to a separate section "Leasequery requestor behavior". - Section 6, paragraph 2. "After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the PD". What does PD mean in this context? I think you meant "relay-forward messages that encapsulate messages with IA_PD options". It's awfully lot of words, but I'm not sure how to say it simpler. - Section 6, paragraph 6. "When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool may change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease.". I think once administrator disables it, the server should always set status to released. The "if at least one..." part in not necessary. - Section 6, paragraph 6. Why does the server have to send RECONFIGURE? So the relay can re-learn RR prefixes once aggregation has been disabled? It is related to my question about RR remembering (or not) the specific routes. Anyway, it would be less intrusive to say that relay must use leasequery to learn existing delegations than forcing all clients to do reconfigure, especially that for clients nothing will change. Also, keep in mind that RRs may not support reconfigure as it is an optional feature. - Section 6, last 2 paragraphs. I would move discussion about leasequery to a separate sub-section. - Section 6, last paragraph. Why repeating prefix pool in every client-data option? It will all contain the same value. It would be more reasonable to send it back only one or even not send it at all if requestor sent prefix pool option. If requestor did that, are there any cases where server could send back the prefix pool option with different values than the requestor asked for? I don't think so. - Section 7. Security consideration should also reference section 15 of RFC3633. Questions: 1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is split into /56 prefixes. Someone tries to reach a customer that is currently offline. What is PE supposed to do with those packets? Respond with ICMP type=1 code=0 (no route to destination)? 2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The admnistrative policy does not allow route aggregation, so OPTION_PREFIX_POOL has status set to release. Is PE allowed to aggregate both routes anyway and announce 2001:db8:1:8000::/63? Perhaps allowing such behaviour could be defined as status code = 2. I don't know if controlling this is a good idea, so feel free to ignore this suggestion. Ok, that's it. Sorry for sending such long and boring mail. I hope you find at least some of those comments useful. Again, despite numerous comments, I really support it. Tomek