Re: [Softwires] Random comments about DHCP discussion

[Ole Troan <[e-mail]>]

Tomek,

> Here are some random comments about draft-ietf-softwire-map-dhcp-04
> draft:
> 
> 1. These are the original reasons for using MAP (now Softwire46)
> container:
> http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html
> 
> They can be summarized as: It was impossible to get a clear confirmation
> that only a single MAP domain will ever be configured on a given
> network. MAP design was fluctuating. Also, it is unclear what use cases
> may come out of Homenet, especially with regards to multiple
> provisioning domains. Keeping the S46 options in a separate container
> give us more likelihood of future compatibility with whatever may come
> our way (from Homenet, from MIF and multiple provisioning domains or
> somewhere else).
> 
> As I said before, none of the arguments on its own is strong enough to
> warrant a container, but taking them all together they are convincing
> enough (in my personal option, with my dhc chair hat off) to go with a
> container. Having said all that, I do not object removing the container.

the MAP specification explicitly allows for a MAP CE to belong to multiple MAP domains.

> 2. I brought the question on how to request sub-options in DHCPv6. It
> was discussed couple meetings ago in DHC session. The draft was named
> http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt.
> The answer I got for the question "how to request sub-options in
> DHCPv6?" from DHC was "use regular, top level ORO".

I think there should be a goal in designing this DHCP option _NOT_ to require sub-option ORO requests.
also see the discussion on "unified" CPE. if we require this I don't see the point of having
a single DHCP option.

> 3. If you look at the evolution of map-dhcp draft, it is somewhat
> worrying. There used to be an enum field that clearly specified the mode
> (at that time it was only MAP-E or MAP-T, but it was trivial to extend
> the enum list to cover other cases). That was removed as requested. Now
> the argument is being made that the CPE does not know which mode it
> should run. Even more, options are being split to provide the capability
> to differentiate between modes.

right. if I understood Mark's email correctly, I think he made the point that there shouldn't be modes.
a unified CPE supports all. now, if we want to include mechanisms that we have consensus on
not putting on standards track in "unified", that I'm unsure about.

> 4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways.
> The first and more obvious one is to draw conclusions from contents of
> ORO. The other one that is less common, but equally valid is to make the
> client send an option (note the difference: send an actual option, not
> option code in ORO). See rapid-commit option for example. If you choose
> to do that, I encourage you to read draft-ietf-dhc-option-guidelines,
> section 5.2 for a nice discussion how to use such an option. That's
> point is made with my dhc chair hat on.

I think it should be a design goal, that the DHCPv6 option can be "static" and the same
for all clients.

MAP/LW46 has lots of capabilities. hub and spoke, mesh, shared IPv4 address,
full IPv4 address, IPv4 prefix, contiguous or non-contiguous port spaces,
encapsulation or translation, embedded address bits, or 1:1...
I don't think negotiating these capabilities individually via DHCP is at all a good idea.
a general CPE confirming with the MAP/LW46 specifications must implement all features.
in a controlled environment, e.g. where the SP controls both CPE, BR and provisioning, a CPE
might only implement a subset. that's not something we need to cover in the specs though.

> 5. Ian insisted on having a way to communicate that a certain CPE is
> able to support only EA-len 0. I suppose you could make the same
> argument about trimming down other capabilities in an arbitrary way to
> have a subset of MAP/lw4over6/whatever-else-you-want to make its
> implementation simpler. Perhaps it would be useful to have the
> capability to communicate CPE capability? Although not very popular, it
> is possible for clients to send options they are requesting from the
> server with values used as hints. See 4th paragraph in section 17.1.1 of
> RFC3315 for details. Classic example is a client that sends IA_NA option
> with IAADDRESS in it with preferred and valid lifetimes set to values
> the client would like to get. That gives the server the information
> about client's preference. However, it should be clear that those values
> are hints only. Server is certainly allowed to ignore them completely.
> On a practical side, support for such capability is available, but
> rather uncommon in existing implementations.

as stated above, I think we've lost if we end up with capabilities negotiations.

cheers,
Ole