Subject: [dhcwg] draft-ietf-softwire-map-dhcp-01

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 6 Nov 2012 20:49:37 +0000

Hi:

While I can't really comment much on map, I can suggest that the authors revisit the formatting of the options. So, here goes ... (Outlook might mess up the diagrams?)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        OPTION_MAP_RULE        |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  prefix6-len  |     ea-len    |  prefix4-len  |  rule-flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        rule-ipv4-prefix                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       rule-ipv6-prefix                        |
     |                       (variable length)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                     sub-options (variable length)             .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Could this be reworked as:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        OPTION_MAP_RULE        |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | prefix6-length|                                               |
     +-+-+-+-+-+-+-+-+          rule-ipv6-prefix                     |
     |                           (16 octets)                         |
     |                                                               |
     |                                                               |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |     ea-len    |  prefix4-len  |rule-ipv4-prfx |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            rule-ipv4-prefix (contd)           |  rule-flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                     sub-options (variable length)             .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Keep the prefix-length/prefix together and like it was defined in IAPREFIX.
- Keep the subnet-length/subnet together (you can put the length after if you prefer that, but I don't think we have anything that is a good convention for this).
- Use fixed length fields UNLESS compressed format is *really* required or think the savings is worth it. You could make the rule-ipv6-prefix variable length (but then why not also the rule-ipv4-prefix)?

The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (same arguments). It should definitely be consistent!

Refine OPTION_MAP_PORTPARAMS to:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     OPTION_MAP_PORTPARAMS     |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    offset     |    PSID-len   |            PSID               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The text can say that offset and PSID-len are restricted to specific ranges. If you ever need something different, a new option can be added instead of using the "reserved bits".

Also, it would be really helpful if, in the cases were suboptions can exist, these are identified. While I can understand you might want new ones in the future, that's OK. What options exists today?

And, are these really suboptions or encapsulated options? In other words, is this an option space unique to this option or is this other DHCPv6 options (such as the other options defined in this document). I think we've usually used 'encapsulated' to mean the DHCPv6 option space and 'sub-options' to mean a new option space?

Perhaps the examples will help, but I'm unclear what suboptions go into OPTION_MAP vs OPTION_MAP_RULE / OPTION_MAP_DMR? There is some information in Section 6, DHCPv6 Server Behavior. Perhaps if I knew MAP well, this would be obvious?

Might be nice to rename section 4.1 from "MAP Option" to "MAP Flags Option" as that is what it is called in much of text?

As Tomasz is working on both this draft and the guidelines drafts, perhaps some of this would be useful to reflect in the guidelines? Using standard building blocks (such as prefix-length + prefix (either compressed or not)) would go a long way to make encoding/decoding structured options easier. Splitting these fields, as was proposed in the draft, is just making life for all much more complicated. And, compressing/variable-length vs fixed length should also be evaluated carefully. Extracting data from a fixed structure is a lot easier and less error prone than from a variable one. Yes, bits over the wire do matter (especially for low-level functionality such as DHCP because we'd not like to require fragmentation support), but would a boot level device really need MAP-T?

I am not at the IETF meeting the week and sending it to the list as that were it should go anyway.

- Bernie

---

From: Leaf yeh <[email-masked]>
Date: Thu, 8 Nov 2012 08:43:08 +0000

Bernie - The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (same arguments). It should definitely be consistent!

This sounds logic to me, rule6-prefix (rule-ipv6-prefix) or rule4-prefix (rule-ipv4-prefix) could be, either variable length or fixed length, in the same manner. Supposed Tomek will reply on this point.

Bernie - Also, it would be really helpful if, in the cases were suboptions can exist, these are identified. While I can understand you might want new ones in the future, that's OK. What options exists today? And, are these really suboptions or encapsulated options? In other words, is this an option space unique to this option or is this other DHCPv6 options (such as the other options defined in this document). I think we've usually used 'encapsulated' to mean the DHCPv6 option space and 'sub-options' to mean a new option space?

a. It seems to me Port Parameters option (OPTION_MAP_PORTPARAMS) is not necessary to be the sub-option of Rule option (OPTION_MAP_RULE). They might be in the same level. I believe the parameters of OFFSET, PSID-len and PSID could be independent from the Rule options. The OFFSET have a default value (= 4) defined in section 5.1.3 of draft (MAP), https://datatracker.ietf.org/doc/draft-ietf-softwire-map/?include_text=1 . The operator could select the uniform value for all Rules, if it is not 4. The PSID-len and PSID sounds to design for the non-mapping mechanism, which make the configuration of CE's port set independently from the mapping Rules. I doubt the FMR, except for the BMR which is also responsible for the CE's parameter configuration, need the PSID-len and PSID. The OFFSET might deserver a separate option.

b. I don't think it is necessary to define sub-options space in the DMR option (OPTION_MAP_DMR), and even in the Rule option. 

c. The function of MAP option (OPTION_MAP) sounds only for the grouping of Rule options. I guess it also can be used for the grouping of Rule options and Port Parameter option. However, someone may still ask whether it is necessary to have a container option for the all the MAP parameters, why not just let it be in the DHCPv6 message.

d. The FLAG (E or T) could also be independent from the OPTION_MAP. Suppose we only except CE in one MAP domain now, and I doubt the CE would like to select Encapsulation and Translation mode for the different MAP domains in the future. If necessary, the FLAG (E or T) might deserver a separate option, but it really sounds to me a factory (or manual) setting on the CE.

I agree to simplify the nesting structure of the options defined in this draft, then make the understanding & life easier. :-)

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2012 4:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Wojciech Dec (wdec); Leaf yeh
Subject: draft-ietf-softwire-map-dhcp-01

Hi:

      0                   1                   2                   3

      0                   1                   2                   3

      0                   1                   2                   3

- Bernie

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 08 Nov 2012 07:16:43 -0500

On 12-11-06 15:49, Bernie Volz (volz) wrote:
> While I can't really comment much on map, I can suggest that the authors revisit the formatting of the options. 
The story behind MAP option is that it is a companion document. It
delivers whatever is needed by the base MAP spec. That spec used to
fluctuate quite a bit, so things were coming and going away. That's why
we didn't pay close attention to the option layout. Luckily, MAP spec
seems to have stabilized recently, so it's a good time to revisit option
formats. Another reason for not doing it so far was time constraint - I
have limited bandwidth for IETF activities and decided to focus on v6
failover stuff.

Having said that, I agree with almost all your comments and will
implement them.

> Could this be reworked as:
Compressed prefix is what Ted suggested. It has its merits, especially
if there are many mapping rules. I'll ask about WG preference for fixed
vs compressed formats and see how it goes. In general, conditional
formatting is something we prefer to avoid. For v4 prefixes the possible
savings are minimal - likely 0 or just 1 for /24 prefix. I don't think
larger (/16) will ever be reasonably used. Even if they were - that's a
saving of mere 2 bytes. So it isn't worth the hassle.

In my opinion we have 2 possible choices here:
- compressed v6 + fixed v4.
- fixed v6 + fixed v4

> The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (same arguments). It should definitely be consistent!
Agree. Will update MAP_DMR if the group recommends fixed approach.
> Refine OPTION_MAP_PORTPARAMS to:
Ok, will do that.
> Also, it would be really helpful if, in the cases were suboptions can exist, these are identified. While I can understand you might want new ones in the future, that's OK. What options exists today?
Currently MAP option can contain MAP_RULE and MAP_DMR options. MAP Rule
may also contain MAP_PORTPARAMS. I will clarify the text.
But the suboptions is also for future compatibility. Judging from my
previous experience with Softwires, there are 15 new drafts around the
corner, just waiting to add something new clever and marginally
different from what is available today. But your point still stands - I
will go over the draft and add lists of allowed suboptions.

I think it will also be helpful to write the examples section, perhaps
not for each option separately, but rather how all those options are
used together.
> And, are these really suboptions or encapsulated options? In other words, is this an option space unique to this option or is this other DHCPv6 options (such as the other options defined in this do…
Excellent point. Bernie, where have you been when requesting suboptions
draft was presented? :)
> Perhaps the examples will help, but I'm unclear what suboptions go into OPTION_MAP vs OPTION_MAP_RULE / OPTION_MAP_DMR? There is some information in Section 6, DHCPv6 Server Behavior. Perhaps if I…
There used to be a section about it. Do you think putting it back in the
draft would help?
http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02#section-4.1
Note that this particular version is outdated, so it would require a
refresh.
> Might be nice to rename section 4.1 from "MAP Option" to "MAP Flags Option" as that is what it is called in much of text?
Agreed.
> As Tomasz is working on both this draft and the guidelines drafts,
Correction: Tomasz is pretending to be working on both :) I was spending
most of my time on v6 failover. Fortunately, the hard part - the design
- is now completed. There's still a lot of work to do there and I hope
to get many comments on it, but it will likely to be less time consuming
from now on.
>  perhaps some of this would be useful to reflect in the guidelines? Using standard building blocks (such as prefix-length + prefix (either compressed or not)) would go a long way to make encoding/decoding structured options easier. Splitting these fields, as was proposed in the draft, is just making life for all much more complicated. 
There's a new section planned about prefixes in option guidelines.
> And, compressing/variable-length vs fixed length should also be evaluated carefully. Extracting data from a fixed structure is a lot easier and less error prone than from a variable one. Yes, bits over the wire do matter (especially for low-level functionality such as DHCP because we'd not 
Agree. There's a slide about it with a question about WG preference in
the option guidelines presentation that I plan to show today.
> like to require fragmentation support), but would a boot level device really need MAP-T?
Definitely. Fragmentation is something that is required by 3315 (sort
of. It is explicitly mentioned, but without normative language). But I
would be surprised if there is a any implementation that is properly
prepared for that.
> I am not at the IETF meeting the week and sending it to the list as that were it should go anyway.
Thanks a lot, Bernie. That's exactly the kind of comments I was hoping
to get.

Tomek

p.s.
Sorry for html post, but otherwise the option formats get garbled.