Subject: [Softwires] DHCPv6 section of the 4rd draft

From: Rémi Després <[email-masked]>
Date: Tue, 24 Jul 2012 15:10:54 +0200

Hi, Tomek,

Since you are the known DHCP expert in Softwire concerning stateless solutions, could you kindly review section 4.8 of the 4rd-03 draft, and comment on the ML its use of DHCPv6?
(Doing so, of course, will not prejudge what the WG will decide concerning MAP-T+E vs 4rd.)

In particular, the map-dhcp draft which will soon be a WG document has a container which isn't present in 4rd. 
Would it be recommend to add one (and if yes for which reason(s))?

Thanks
RD

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 27 Jul 2012 16:55:10 +0200

> Hi, Tomek,
Hi Remi. hi all,

> Since you are the known DHCP expert in Softwire concerning stateless
Thank you for your kind words. I just know DHCPv6 a bit, but I
definitely don't consider myself an expert in stateless solutions.

> solutions, could you kindly review section 4.8 of the 4rd-03 draft,
> and comment on the ML its use of DHCPv6?
I must admit that I haven't read 4rd draft in a long time.
Unfortunately, I won't be able to review it before DHC meeting.
Actually, it makes sense to do the 4rd review after DHC WG meeting. MAP
options are going to be presented there, so I will hopefully be able to
take advantage of other comments from DHC WG as MAP and 4rd options are
quite similar.

I haven't read 4rd-03 yet, just briefly looked at Section 4.8. Having
said that, I've got a question to 4rd authors. I see there are
significant similarities between MAP and 4rd options. Would you consider
merging them a viable option? If all other MAP-4rd unification attempts
fail, perhaps at least provisioning method could be common?

> concerning MAP-T+E vs 4rd.)
You definitely overestimate my capabilities. I have very serious doubts
that the whole WG would make a decision based on my comments. :-)

> In particular, the map-dhcp draft which will soon be a WG document
> has a container which isn't present in 4rd. Would it be recommend to
> add one (and if yes for which reason(s))?
Here are some arguments why I think such a container make sense:
1. Some parameters may apply to all rules. Currently there is only one
such parameter defined (transport mode), but others may appear once MAP
evolves.
2. Easier client-server interaction. With a single container, client
just signals support for MAP by requesting MAP_FLAGS option in ORO and
server responds with MAP_FLAGS option with whatever sub-options are
appropriate for a given client. Without container, client would be
expected to request several options (MAP_FLAGS, MAP_RULE, ...) in ORO.
But how is server is supposed to behave if a (misimplemented) client
requests only MAP_FLAGS for example? Or only asks for basic rules? Such
approach makes sanity checking and error recovery more difficult.
3. Multiple MAP domains. Sometimes there are discussions about multiple
MAP domains. I haven't followed it closely, so I don't know if the
latest conclusion is that they make sense or not. However, even if MAP
authors (and the whole Softwires WG in general) decides that they are
not valid, there may be cases when one server will provide more than one
domain anyway. Look at discussion in homenet and the problem with
multiple provisioning domains (like th concept of having a single home
router connected to multiple ISPs). Put it simply, a container option
makes multiple domains doable, if we ever decide that such a thing is
useful.
4. It's easier for clients that don't support MAP. That is really a
minor point, but clients that don't support MAP will complain about just
a single unknown option, not many. Sure, in a perfect world, client is
not expected to receive an option that it never requested. But there are
people who configure their servers to force some options, regardless
requested or not.
5. There's no actual bandwidth waste with container. There would be a
minimal overhead of 4 octets if it was just a container. However, since
MAP and 4rd both require an option with some information, there's no waste.
6. Forward compatibility. Let's assume that 4rd is standardized. What
would you do if the next day after its publication someone comes with
cool new idea for improvement or optimization that requires passing
extra parameter to client? You would have to define a new option and it
wouldn't work with old implementations. With a container, you have at
least some chances to make it work. One may say that this is a weak
argument, as old implementations will not know what to do with an
unknown option. However, many implementations handle contents of the
option be calling external script. So extending support for such extra
sub-option would require updating just a script, not the whole client
software.

If you take those arguments one by one, each of them can be considered
not important enough to warrant such a container, but if you add them
all up, it is just much easier do go with a container. At least that is
my opinion on that subject.

Cheers,
Tomek

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Jul 2012 18:10:25 +0200

Le 2012-07-27 à 16:55, Tomek Mrugalski a écrit :

> merging them a viable option?

> If all other MAP-4rd unification attempts

Well, the WG objective before the Paris meeting was clearly to have only one standard, MAP-T, MAP-E or 4rd.

4rd has been carefully designed satisfy requirements of both MAP-T and MAP-E in a single design, and abundantly checked concerning this objective. With it, operators don't need to make a choice, and get operational advantages of T and E. (This is clearly challenged by some participants, but so far without arguments that have been convincing.)

If IETF would prefer 3 forwarding variants instead of one, right, the provisioning method should at least be aligned.

> that the whole WG would make a decision based on my comments. :-)

Just meaning that by working a little on 4rd, you shouldn't be considered by anyone as unfaithful to a group for which you did important work.

> approach makes sanity checking and error recovery more difficult.

Point 2 understood, and in my understanding sufficient a justification.

> sub-option would require updating just a script, not the whole client

Related to point 2 in my understanding, and understood too.

> my opinion on that subject.

With the above, I am now convinced that the container is worth adding to the 4rd specification.
Thanks a lot.

RD