Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

["Leaf Yeh" <[e-mail]>]

Updated - 7. Accepted. The text will turn to be 'DHCPv6 relay agent MAY
include this option in RELAY-FORW (12) message. DHCPv6 server MAY include
this option in the RELAY-REPL (13), LEASEQUERY-REPLY (15) and
LEASEQUERY-DATA (17) message. '


Best Regards,
Leaf


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Leaf yeh
Sent: Tuesday, August 28, 2012 9:22 PM
To: Tomek Mrugalski
Cc: dhcwg
Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

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 does not have to be renumbered.
c. RECONFIGURE sounds 1 of 3 main 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:[e-mail]]
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

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg