Re: [dhcwg] Review of the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01

[tianxiang li <[e-mail]>]

Hi Marcin,

Thank you for your review and comments. Please see inline.

Regards,
Tianxiang

2015-11-03 9:04 GMT+08:00 Marcin Siodelski <[e-mail]>:

> Hello,
>
> I have read the version -01 of the document. It is important to clarify
> the behavior of the requesting/delegating router behavior with respect
> to prefix-length hints.
>
> A couple of comments below.
>
> The document is structured in a way that makes it hard to match the
> issues with the solutions for them. For example: section 3.1 focuses on
> issues in handling prefix length hint in case of the Solicit. It doesn't
> provide a solution, though. The solution is provided in section 4.1,
> i.e. a couple of sections down the road. This makes me scroll back and
> forth to find out "how did they deal with this problem?". I'd suggest
> that the issue and the solution is provided in the same section. See how
> RFC7550 is structured.
>

[TX] Yes, it would be better to put the problem statement and solution
together for each message, like in RFC7550. I will change the document
structure in the next version.

>
> Abstract
>
> "DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
>    prefix-length hint value in the IA_PD option to indicate a preference
>    for the size of the prefix to be delegated..."
>
> According to the terminology used in RFC3633, the "client" is referred
> to as "requesting router". Admittedly, when we merged the RFC3633 into
> the RFC3633 into RFC3315bis we unified the terminology and we also refer
> to the node having a function of requesting router as a client. However,
> since this document refers to the RFC3633, it would be better to use the
> original terminology in the abstract and then mention that further in
> this document whenever the "client" term is used it refers to the
> requesting router. On the other hand, if the document will not be
> incorporated into the RFC3315bis, perhaps it is simply better to stick
> to requesting router/delegating router terminology.

[TX] Agreed, will change "client" and "server" to "requesting router" and
"delegating router" respectively, to keep text unified with RFC3633.


> 3.1.  Creation of Solicit Message by the Client
>  "The Solicit message allows a client to ask servers for addresses and
>    configuration parameters."
>
> It is a bit odd that addresses are specifically mentioned in the context
> of this draft, which discusses the issues pertaining to prefix delegation.
>

[TX] Will change this text to"The Solicit message allows requesting routers
to ask delegating routers for prefixes and other configuration parameters."

>
> 4.1. Creation of Solicit Message by the Client
>
> " When the client wants the same prefix back from the server, it should
>    include the prefix value in the "IPv6 prefix" field of the IA_PD
>    Prefix option, and the length of the prefix in the "prefix-length"
>    field.  This is an indication to the server that the client wants the
>    same prefix back."
>
> At this point there is a possibility that the lease that the client
> remembers and which it includes in the hint is not available anymore.
> Perhaps it has been allocated to another requesting router. Therefore
> the server considerations in 4.2. could be a bit more specific what to
> do in such case. The section 4.2. currently says that the server should
> try to provide a prefix of a specific length, regardless of the prefix
> recorded from previous interactions. In fact, if the requesting router
> is sending a non-zero prefix as a hint the server could try to allocate
> this prefix in the first place. If it is unavailable, it should use the
> prefix length hint and use that to allocate a different prefix.
>
> [TX] Here I think the text could be changed to:
If the requesting router includes just a prefix-length hint (zero prefix
value, and non zero prefix-length value), the delegating router should try
to honor the prefix-length hint.

If the requesting router includes a non-zero prefix and its prefix-length
value, the server should first try to provide the requested prefix. If the
prefix is unavailable, then the server should try to provide a prefix
matching the requested prefix-length value.


> 4.3. Receipt of Advertise Message by the Client
>
> This text should be revised against the RFC7550. The text currently
> recommends that the client, unsatisfied with prefixes provided, should
> do Solicit but use the IA_NAs with available addresses. First of all,
> this section discusses Advertise message processing when the server
> hasn't committed addresses for the client, so technically the client
> can't use them until it does Request-Reply.

Also, doing Request-Reply (and then Renew) for IA_NAs and Solicit for
> IA_PDs at the same time,
> requires two state machines on the client side.

[TX] I think having two state machines is something that RFC7550 tries to
avoid. So here maybe the text should be: If the client also Solicited for
IA_NAs, the client should accept the IA_NA addresses and continue to
request for the desired IA_PD prefix during Renew/Rebind as specified in
[RFC7550].

Another option would be to not discuss this issue here, since it's already
mentioned in RFC7550.


> The RFC7550 solves those issues already by allowing to accept some
> bindings and continue
> requesting other bindings in the Renew/Rebind. This section should
> probably refer to RFC7550 to describe the case when the client doesn't
> get the prefixes it is satisfied with.


> 4.4. Creation of Renew/Rebind Message by the Client
>
> The client willing to obtain another prefix would typically include a
> different IA_PD (with different IAID). The IA_PD may contain no prefix
> option or it may contain a prefix option with a prefix-length hint.
> Again, see RFC7550. Using the same IA_PD to renew existing prefix and
> request another one is probably not a good idea.
>
[TX]Changing the IAID is a way of requesting for a new prefix, but it
requires stable storage of the requesting router device, since rebooting
the device would cause it to use the original IAID on the IA_PD, and then
it might get back the original prefix, if the original prefix hadn't been
released or expired.

I think maybe both solutions could be listed in the text, and discuss which
one could be used during what situation?

>
> Marcin
>
>
>
>
>