Subject: [mif] Small nit on route option draft

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 01:13:03 +0000

I would like to ask that you reverse the prefix length and metric fields in the option.  The reason for this is that the prefix length and prefix look like they are going to become a common encoding (they are also used in a proposed source address configuration option). They are essentially a single value, expressed as two fields. I have asked the source address draft authors to group the prefix length and prefix together; I think it makes sense to do the same thing here.   This will speed adoption of both drafts, I think. 

In order for this to be useful, of course, it would be necessary for you to adopt the variable length format for the prefix that is used in that draft.  The draft is called draft-ietf-6man-address-select-opt-01. 

I do apologize for interjecting this so late in the process, but I think it's a substantial win to use the same format for the same data across different options.

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 14 Nov 2011 10:39:07 +0800

On 11-11-14 09:13, Ted Lemon wrote:
> I would like to ask that you reverse the prefix length and metric
> fields in the option.  The reason for this is that the prefix length
> and prefix look like they are going to become a common encoding
> (they are also used in a proposed source address configuration
> option). They are essentially a single value, expressed as two
> fields. I have asked the source address draft authors to group the
> prefix length and prefix together; I think it makes sense to do the
> same thing here. This will speed adoption of both drafts, I think.
>
> In order for this to be useful, of course, it would be necessary for
> you to adopt the variable length format for the prefix that is used
> in that draft.  The draft is called
> draft-ietf-6man-address-select-opt-01.

Reordering fields to have prefix length immediately followed by prefix
is very much ok. I'll do that. However, I'm a bit hesitant about having
prefix encoded as variable length. I admit that I haven't read
address-select-opt yet, some maybe there is a text somewhere that
justifies variable length format.

I have 3 objections regarding variable length format.

1. It is against DHC WG item regarding option guidelines, at least that 
is how I understand the text. See draft-ietf-dhc-option-guidelines-07, 
section 5. If I'm reading option-guidelines wrong, perhaps it could use 
more explicit wording? Also, if we decide to go with variable length, we 
should consider updating option-guidelines to remain consistent.

2. What about similarity to existing and widely deployed option, i.e. 
IAPREFIX? See RFC3633, section 10. IAPREFIX encodes prefix as 16 
octects, regardless of the actual prefix length. Please do note that 
validation of such options correctness is trivial. Option has to have at 
least X octets, otherwise it is truncated. With variable length format 
it is not so simple anymore. I admit that it's not that complicated 
either, so I can live with that. I never heard anyone complaining about 
this format. Of course that doesn't mean that there are no such 
complaints. Perhaps I'm ignorant and just never heard them.

3. The case in 6man-addr-select-opt is a bit different. I haven't read 
that draft yet, but according to the description, prefix-len field
and its relation to length of the actual prefix field is a bit strange. 
Length is rounded up to the next quad octet boundary. This makes the 
prefix field to have length 0,4,8,12 or 16 octets. For example, for 
prefix lenth 33 bits you send 8 bytes of prefix. If we choose to go with 
variable lengths, perhaps more convenient would to round up to the next 
octet boundary? 33 bits prefix would be stored as 40 bits (5 octets)?

These are very strong arguments against variable length approach. 
Personally, I would prefer fixed fields, but I won't insist on it.

On a related note if we choose to go with variable format, 
draft-mdt-softwire-map-dhcp-option-01 has to be updated as well. That 
draft also conveys IPv4 prefix. If we go variable, we should probably do 
that for both v4 and v6. That in turn makes the option validation even 
nastier as there would be 2 variable length fields.

> I do apologize for interjecting this so late in the process, but I
> think it's a substantial win to use the same format for the same
> data across different options.
No problem at all. I appreciate any feedback we can get on this.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 05:39:37 +0000

I replied to Tomek's original message, but neglected to cc: the list.   This is my reply to his reply.   I will forward my original reply as well—I apologize for the omission.

On Nov 14, 2011, at 11:17 AM, "Tomek Mrugalski" <[email-masked]> wrote:
> Of course, it a guideline, not a rule. Still, it would be useful to have a consistent guideline that is followed. Perhaps we could add a section to option-guidelines regarding recommended prefix format? Will you send a request about this to David or do you want me to do that?

I am thinking it might be worth writing a document that just describes all the known data formats used by DHCPv6 options.   Because so many options were defined at the time the DHCPv4 spec went out, we don't have as much of a problem with consistency, but with DHCPv6 I think we are treading a dangerous path.

> It's not an issue, just something we could probably take into consideration. With fixed length, it's trivial. With variable length, it's very easy. Ok, so we discussed that and decided that validation is not a concern.

Cool.

> I'd like to review it, but the reality is that I will probably add it to endless list of draft that I'm supposed to read... I'm co-authoring 6 drafts currently and for some reason I usually end up being the most active co-author.

I feel your pain.   I can say personally that I really appreciate all the work you're doing.   If you don't have time to read this draft, it's okay—I think we have sufficient review.

> That's understandable. It was developed at break neck pace around 2 or 3 weeks ago. It will be presented today in Softwires, at 13:00.

Clever.

> So I suppose your message is clear - go with variable length prefix. Ok, I'll update all drafts I'm working on.

Thanks.   And as you suggested, cut the prefix on byte boundaries.

> You responded directly to me. Perhaps you wanted to reply with cc: to mif?

Argh.   Sorry about that.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 05:41:04 +0000

I accidentally failed to include mif in this reply; here's the reply, as mentioned previously.

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: November 14, 2011 10:55:59 AM GMT+08:00
To: Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mif] Small nit on route option draft

On Nov 14, 2011, at 10:39 AM, "Tomek Mrugalski" <[email-masked]<mailto:[email-masked]>> wrote:

1. It is against DHC WG item regarding option guidelines, at least that is how I understand the text. See draft-ietf-dhc-option-guidelines-07, section 5. If I'm reading option-guidelines wrong, perhaps it could use more explicit wording? Also, if we decide to go with variable length, we should consider updating option-guidelines to remain consistent.

This is not a valid objection. The option guidelines draft is informational, so can't be normative. It is also not an RFC, because it hasn't passed WGLC or been reviewed by the IETF. So please do not use this document as if it were normative.

2. What about similarity to existing and widely deployed option, i.e. IAPREFIX? See RFC3633, section 10. IAPREFIX encodes prefix as 16 octects, regardless of the actual prefix length.

This is true, and unfortunate. The reason, I thing, is that Ralph wasn't expecting to see a lot of these prefixes, and hence didn't consider space to be an issue. But it is an issue with the route option and also with the address selection option.

Please do note that validation of such options correctness is trivial. Option has to have at least X octets, otherwise it is truncated. With variable length format it is not so simple anymore. I admit that it's not that complicated either, so I can live with that. I never heard anyone complaining about this format. Of course that doesn't mean that there are no such complaints. Perhaps I'm ignorant and just never heard them.

I think this is simply because it's not an issue with PD. I really don't think validating the variable-length prefix is an issue.

3. The case in 6man-addr-select-opt is a bit different. I haven't read that draft yet, but according to the description, prefix-len field
and its relation to length of the actual prefix field is a bit strange. Length is rounded up to the next quad octet boundary. This makes the prefix field to have length 0,4,8,12 or 16 octets. For example, for prefix lenth 33 bits you send 8 bytes of prefix. If we choose to go with variable lengths, perhaps more convenient would to round up to the next octet boundary? 33 bits prefix would be stored as 40 bits (5 octets)?

Yes, I agree. I will mention this to the authors.  BTW, the authors are looking for more review, so it would be very helpful if you reviewed the draft.

On a related note if we choose to go with variable format, draft-mdt-softwire-map-dhcp-option-01 has to be updated as well. That draft also conveys IPv4 prefix. If we go variable, we should probably do that for both v4 and v6. That in turn makes the option validation even nastier as there would be 2 variable length fields.

It's completely different. In IPv4, the maximum waste is 3 bytes. In IPv6, the /typical/ waste will be 8 bytes.   But I agree that the document needs to be updated to group prefix length with prefix and use the variable length prefix format for IPv6. Thanks for bringing this document to my attention–it had slipped under my radar.  :)

Thanks!

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 06:21:01 +0000

> On a related note if we choose to go with variable format, draft-mdt-softwire-map-dhcp-option-01 has to be updated as well. That draft also conveys IPv4 prefix. If we go variable, we should probabl…

BTW, my previous comment about efficiency assumes that you're only sending one IPv4 prefix.   However, there is a DHCPv4 option that sends prefixes the way you describe: RFC3442, the Classless Static Routes option.   I'm pretty sure you already knew that, but I thought I'd mention it here for completeness.

I still don't think you need to do prefix compression for this particular option.   I don't think it's likely that we're going to see a profusion of IPv4 prefixes in DHCPv6 options; the reason I raised the concern about IPv6 prefixes is that I suspect we will see a profusion of those, and indeed the route option and address selection option are evidence of that.