Re: [Softwires] Random comments about DHCP discussion

["Rajiv Asati (rajiva)" <[e-mail]>]

If one needs to ensure clean v6 routing summarization (per PE, in case of a BGP-free core), then one domain (per PE) is not realistic at all, nor optimal (from routing standpoint).   

Sure, one can design MAP with just one domain and take the hit on v6 routing summarization. We just choose not to do it that way. It is a trade-off. We have had quite a discussion on this.  

The network needs to be designed for v6 and transition technology like MAP should be added on top, not the other way around, IMO.

Cheers,
Rajiv

Sent from my Phone

On Aug 4, 2013, at 5:53 AM, "Townsley.net" <[e-mail]> wrote:

> 
> Some deployments work fine with one or two rules (Satoru-San can confirm). Others need more. If you reach 100s you *might* be designing things wrong (a classic starting point begins with folks assigning one map domain per BNG or DSlam until they realize that's optimizing at the wrong place). I'd be happy to chat with you off list about that. 
> 
> Not to suggest for a second that MAP would break with 100s of rules, or that there are not good reasons to operate in that mode. 10000s should be fine too, as it is all just dialing between 1:1 and 1:n tunnel state aggregation. 
> 
> One and only one rule as we did in 6rd would be wrong for MAP, this is for certain. 
> 
> - Mark
> 
> (Thumbtyped)
> 
> On 30 juil. 2013, at 22:16, "Rajiv Asati (rajiva)" <[e-mail]> wrote:
> 
>> Tomek,
>> 
>>> 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.
>> 
>> I can confirm that a single MAP domain is not found to be sufficient in the network for the deployment we have been involved in. 
>> 
>> We are talking about of 100s of domains in the network. 
>> 
>> Cheers,
>> Rajiv
>> 
>> Sent from my Phone
>> 
>> On Jul 30, 2013, at 7:44 AM, "Tomek Mrugalski" <[e-mail]> wrote:
>> 
>>> 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.
>>> 
>>> 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".
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Hope that helps,
>>> Tomek
>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires