Le 2012-07-27 à 16:55, Tomek Mrugalski a écrit : > 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? 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. > >> (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. :-) 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. >> 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. Point 2 understood, and in my understanding sufficient a justification. > 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. Related to point 2 in my understanding, and understood too. > 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. With the above, I am now convinced that the container is worth adding to the 4rd specification. Thanks a lot. RD > > Cheers, > Tomek _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
