On 24.07.2012 15:10, Rémi Després wrote: > 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? > (Doing so, of course, will not prejudge what the WG will decide > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
