Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01

From: Tomasz Mrugalski <[email-masked]>
Date: Tue, 10 May 2011 00:04:01 +0200

On 19.04.2011 21:18, Ted Lemon wrote:
> We had a last call on this prior to the Prague meeting, and there was
> work done off list, but no responses on-list.   If you support this
> work, please indicate that you support it.   If you oppose the work,
> please provide suggestions, comments, or reasons why it's entirely a
> bad idea.
I read and support this draft.

I know that it's way past dead-line, so feel free to ignore my comments.

Here are my comments. If it is not too late, you could consider them:

1. Section 1:
"single aggregatable route/prefix has to represents one customer"
=> remove "has to" or change represents to represent.

2. Section 4.1
"The requesting router MUST NOT assign the excluded prefix to any of its
downstream interfaces.". Is this implicit suggestion that assigning
excluded prefix to upstream interface is ok? That would be against
RFC3633, Section 12.1 that forbids that. This is probably ok, but then
"updates: 3633" should be added to the preamble (and possibly a simple
clarification). However, if the excluded prefix is handled in some
different way (like SLAAC), then it is ok in current form.

3. Section 4.2
"The OPTION_PD_EXCLUDE option MUST be located before the possible Status
Code option in the IAprefix-options field." Why forcing to use specific
order? DHCPv6 does not impose any restrictions regarding sequence, in
which options appear in a message or within other options. There's good
reason for that - implementations may keep the options in structures
other than simple lists or vector, like hash tables. Enforcing any
specific order would be troublesome in that case. I propose to remove
this sentence.

4. Section 5.1
My understanding was that requesting router is supposed to include
PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet,
there is only Solicit message mentioned in the first sentence of 5.1.
Remaining message types should probably be mentioned as well.

5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is
located in IA_PD (not in the message options field), but draft says that
requesting router should request PD_EXCLUDE in ORO placed in message
options field. Wouldn't it be more appropriate to put second instance of
ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may
consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its
suggestions, if you that they are reasonable.

Hope that helps,
Tomek Mrugalski
ISC

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 May 2011 00:24:52 -0400

> I know that it's way past dead-line, so feel free to ignore my comments.

These are good comments.   I would like to see them addressed, if the authors would be so kind.

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 May 2011 09:16:19 +0200

Tomek,

thanks for good comments!

> => remove "has to" or change represents to represent.

agree.

> different way (like SLAAC), then it is ok in current form.

we are basically trying to say that the excluded prefix is not delegated to the requesting router.
that means the requesting router has no 'ownership' of that prefix and cannot assign it to any interface.
obviously the delegating router can advertise that prefix in an RA and then the requesting router can use SLAAC to configure an address out of the prefix. do you think this needs clarification, if so suggested text?

> specific order would be troublesome in that case. I propose to remove

I tend to agree, what do my co-authors think?
can't remember why we put this in the first place...

> Remaining message types should probably be mentioned as well.

what about:

If the requesting router implements the solution described in Section 4.1
then the requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option in DHCP messages
as described in section 22.7 of RFC3315.

> suggestions, if you that they are reasonable.

good point, I wasn't aware of this. I also think including the ORO at the correct option 'scope' is better.
any objections to that?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2011 08:19:34 -0400

> good point, I wasn't aware of this. I also think including the ORO at the correct option 'scope' is better.

I think this is a question implementors might want to think about.   The functioning of the ORO in situations like this is untrod ground, and it might not do what you expect.

---

From: Stephen Jacob <[email-masked]>
Date: Wed, 11 May 2011 11:41:58 -0700

> specific order would be troublesome in that case. I propose to remove

I very much agree with Tomek. I would prefer that no draft impose option
ordering constraints.

It sounds like Ole agrees, which is great. :)

> suggestions, if you that they are reasonable.

That would seem to make more sense.

It sounds like Ole agrees with this too, so I trust it'll be worked
out. :)

I have only one additional comment on this draft. It is not critical,
and I know I'm commenting on this awfully late in the game...

It is not wrong as-is, but I think it is a bit strange/confusing that
OPTION_PD_EXCLUDE (in 4.2. Prefix Exclude Option) is defined in such
a way that the "IPv6 subnet ID" is a suffix appended to the
'OPTION_IAPREFIX prefix-length', except maybe not ust a suffix because
it has to be octet-aligned so it might include some of the bits of
'OPTION_IAPREFIX prefix-length'.

I misunderstood the definition in section 4.2 until I read the
example at the end.

It also seems like a strange way to define option data. Does anything
else use this way of declaring a sub-prefix?

It would seem to me to have two pros:

	1) It saves some number of bytes of option space.
	2) It ensures that the OPTION_PD_EXCLUDE prefix is contained
	   in the OPTION_IAPREFIX prefix[*].

	   [*] except if octet-alignment requires replication of
	       the final few bits of the OPTION_IAPREFIX prefix,
	       in which case those could be incorrectly included
	       as different bit values, presumably, so it doesn't
	       really even guarantee #2, does it?

It would seem to have 2 cons:

	1) It is hard to understand.
	2) I think implementors may implement it incorrectly, causing
	   interoperability issues.

Given that pro #2 is a weak assurance and pro #1 only means saving a
few bytes (how much does that really matter? I would say not at all),
I think the cons significantly outweigh the pros.

I would suggest that OPTION_PD_EXCLUDE ought to include the full
prefix to exclude.

A downside is that clients (Requesting Routers) will need to validate
the value they receive to ensure that OPTION_PD_EXCLUDE is a subset
of OPTION_IAPREFIX (but they already ought to do some validation due
to the issue I raised in the subscript of pro #2, and that validation
is harder to get right than a simple "is this prefix contained in
this other prefix" comparison; something that one can probably do
with existing library code).

If a client fails to validate, that's its problem, and it will
probably be ok anyway if we make it a MUST for the server that
OPTION_PD_EXCLUDE be a subset of OPTION_IAPREFIX.

For the server implementor, the up-side is not having to write custom
code to handle this special kind of field type, and it means we don't
create an option whose value is defined based on the value of another
option (a situation which I also dislike).

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 May 2011 00:48:29 +0300

Hi,

On May 11, 2011, at 9:41 PM, Stephen Jacob wrote:

[snip]

> 	       really even guarantee #2, does it?

I don't get the issue you are seeing here. Could you give an example of an incorrect case?

> I would suggest that OPTION_PD_EXCLUDE ought to include the full

I.e. back to formatting we still had in draft-korhonen-dhc-pd-exclude-01.. until it got changed because of the concerns raised that are here listed as pros 1) and 2). I am OK going back to old encoding.

- Jouni

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 May 2011 23:14:46 +0300

Hi,

> thanks for good comments!

+1

>> => remove "has to" or change represents to represent.

Will change to:

"single aggregatable route/prefix has to represent one customer"

> obviously the delegating router can advertise that prefix in an RA and then
> the requesting router can use SLAAC to configure an address out of the prefix.
> do you think this needs clarification, if so suggested text?
> 
>> 3. Section 4.2

I put this there for some reason. Now I have been trying to remember what
was the original reason.. without success. Therefore, if I cannot even
remember it anymore there is no reason to have the MUST there. Ok to remove
the sentence.

> as described in section 22.7 of RFC3315.

Ole's text looks good to me.

> correct option 'scope' is better.

I have no strong opinion here. However, options that are used and what we
also define have a flat option number space, thus scoping does not bring
much advantage as we are not defining a sub-option per se. I see no
compelling reason to change the current text/behavior.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 May 2011 10:00:49 +0200

> I don't get the issue you are seeing here. Could you give an example of an incorrect case?

no, I think that's a misunderstanding there is no replication of the bits from IAPREFIX.
sounds like an argument for making that text clearer though.

> I.e. back to formatting we still had in draft-korhonen-dhc-pd-exclude-01.. until it got changed because of the concerns raised that are here listed as pros 1) and 2). I am OK going back to old enco…

I think the current coding is very elegant. I don't care so much about saving the few bytes. but avoiding having redundant information in the option saves on both lots of text describing the corner cases (e.g. the exclude isn't part of the iaprefix and so on), and it saves on implementations having to do all those checks. as an example of what we would get into. what should an implementation do if it gets a exclude prefix that isn't part of the ia_prefix? send a Decline option (which is very specific to address assignment, and would have to be redefined).

cheers,
Ole

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 12 May 2011 11:12:49 -0700

On Thu, May 12, 2011 at 10:00:49AM +0200, Ole Troan wrote:
> no, I think that's a misunderstanding there is no replication of the
> bits from IAPREFIX.  sounds like an argument for making that text
> clearer though.

See below. I believe I misunderstood.

> > I.e. back to formatting we still had in
> > draft-korhonen-dhc-pd-exclude-01.. until it got changed because of
> > the concerns raised that are here listed as pros 1) and 2). I am OK
> > going back to old encoding.
> 
> I think the current coding is very elegant. I don't care so much about
> saving the few bytes. but avoiding having redundant information in the
> option saves on both lots of text describing the corner cases (e.g.
> the exclude isn't part of the iaprefix and so on), and it saves on
> implementations having to do all those checks. as an example of what
> we would get into. what should an implementation do if it gets a
> exclude prefix that isn't part of the ia_prefix? send a Decline option
> (which is very specific to address assignment, and would have to be
> redefined).

I may have misunderstood. I interpreted it as saying (in the bit about
octet-alignment) that if you had:

	Prefix:          abcd:ff00::/24
	Exclude prefix:  abcd:ff11::/16

the value in the OPTION_PD_EXCLUDE prefix field would have to be 0xff11,
thus reproducing a minimum number of bits of IAPREFIX to byte-align the
additional bits specific to the exclude prefix.

I now think what it is saying is that the OPTION_PD_EXCLUDE prefix field
would be 0x1100 (left-shifted to the nearest octet boundary; padded)
which eliminates my concern about pro #2 not being reliable.

Elegant and simple is great. Elegant and confusing is not. My fear is
two-fold:

(i) It will be hard to understand and thus people will implement it
incorrectly either through not understanding what they were meant to
do or from coding errors in the implementation.

(ii) It means that a server implementing the option has to define a
new option format with a rather strange new relationship between the
fields 'prefix-len' and 'IPv6 subnet ID'.

The first can probably be addressed by adding text to clarify. It is
possible that I should have figured out what it really meant on the
first reading, but if I did so then I think it is not unreasonable
to extrapolate that others might.

I'm still not happy about (ii), but if the consensus is that the
advantages afforded by it outweigh my concerns, fair enough.

Regards,
Stephen

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 May 2011 22:17:15 +0300

Stephen,

> 	Exclude prefix:  abcd:ff11::/16

You cannot exclude a shorter prefix than you delegate. Based on the above example you would actually be excluding abcd:ff11::/32. That would result to a subnet-id 0x11 and consume one octet.

- Jouni

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 12 May 2011 12:25:45 -0700

On Thu, May 12, 2011 at 10:17:15PM +0300, jouni korhonen wrote:
> You cannot exclude a shorter prefix than you delegate. Based on the
> above example you would actually be excluding abcd:ff11::/32. That
> would result to a subnet-id 0x11 and consume one octet.

Oops! I meant /32. Typo.

Regards,
Stephen

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2011 14:31:42 -0400

> I think the current coding is very elegant. I don't care so much about saving the few bytes. but avoiding having redundant information in the option saves on both lots of text describing the corner…

Strictly speaking, if the server sends a mask that doesn't work, that's a configuration error.   It's easily corrected by fixing the configuration.   There's no need for the client to do anything special, because the configuration isn't going to work, and human intervention is going to be required.   Defining the extension in such a way that a configuration error is impossible is certainly better than having to deal with misconfiguration.   However, I think SJ's concern is a valid one.

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 May 2011 13:09:43 +0200

> Strictly speaking, if the server sends a mask that doesn't work, that's a configuration error.   It's easily corrected by fixing the configuration.   There's no need for the client to do anything s…

the idea behind the option was to encode it like:

ia_prefix option:      2001:db8::/48
exclude subnet option:          0001 /64

giving the complete excluded prefix: 2001:db8 + 0001 => 2001:db8:0001::/64

the alternative would be:
ia_prefix option:      2001:db8::/48
exclude subnet option: 2001:db8:0001::/64

at least a check that the excluded prefix is a subnet of prefix has to be done in this case.

I do agree with SJ's concern though, we apparently haven't been able to describe the what I thought of as a simple concatenation very well.
can we do another try at better text for the current encoding, or does the working group prefer the explicit coding in option 2?

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Mon, 16 May 2011 14:59:49 +0300

Hi,

>> would result to a subnet-id 0x11 and consume one octet.

I still see no other issue here except maybe my not too clear text how the subnet-id gets extracted. The text can always be made clearer, though.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 May 2011 09:14:25 -0400

> can we do another try at better text for the current encoding, or does the working group prefer the explicit coding in option 2?

The text is written in the passive voice, and is descriptive rather than prescriptive.   I would suggest trying to figure out a way to say "to make a PD_EXCLUDE option, do ..." and "to use a PD_EXCLUDE option, do ..."   It might be helpful to express it as bit arithmetic.   Start from a piece of code that does it, and try to describe what the code does.   I agree with SJ that as written, the description is going to be difficult to understand.