Subject: Re: [Softwires] Random comments about DHCP discussion

From: "Townsley.net" <[email-masked]>
Date: Sun, 4 Aug 2013 11:53:07 +0200

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)" <[email-masked]> 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" <[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 4 Aug 2013 11:53:25 +0000

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

---

From: Simon Perreault <[email-masked]>
Date: Sun, 04 Aug 2013 18:11:08 +0200

Le 2013-08-04 11:53, Townsley.net a écrit :
> [...]

>> We are talking about of 100s of domains in the network.

You two seem to be talking about different things. Mark seems to be 
saying that multiple FRULEs is necessary, while Rajiv seems to be 
concerned with multiple BRULEs.

So far it has been clear that multiple FRULEs are necessary. The 
question (multiple MAP domains) refers to multiple BRULEs. If we want 
multiple BRULEs, then we need to be able to associate FRULEs with the 
corresponding BRULE. One way to do that would be to create a container 
option, another would be to tag them with identifiers. Both alternatives 
are not very attractive.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 Aug 2013 11:07:58 +0200

guys,

> You two seem to be talking about different things. Mark seems to be saying that multiple FRULEs is necessary, while Rajiv seems to be concerned with multiple BRULEs.
> 
> So far it has been clear that multiple FRULEs are necessary. The question (multiple MAP domains) refers to multiple BRULEs. If we want multiple BRULEs, then we need to be able to associate FRULEs with the corresponding BRULE. One way to do that would be to create a container option, another would be to tag them with identifiers. Both alternatives are not very attractive.

do we need to reopen this debate? this issue has been discussed previously and the MAP base document has passed WGLC.
MAP does support multiple rules, and multiple domains.

it would be unfortunate if the DHCP provisioning mechanism would not support multiple domains.

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 5 Aug 2013 20:00:16 +0000

I agree with Ole. 

Whether a given network deployment needs multiple domains (per CPE or per
network) should be left for the operator to decide. Protocol should
accommodate that.

Cheers,
Rajiv

-----Original Message-----
From: Ole Troan <[email-masked]>
Date: Monday, August 5, 2013 5:07 AM
To: Simon Perreault <[email-masked]>
Cc: Softwires-wg list <[email-masked]>
Subject: Re: [Softwires] Random comments about DHCP discussion

>do we need to reopen this debate? this issue has been discussed
>previously and the MAP base document has passed WGLC.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Aug 2013 10:18:57 +0200

> it would be unfortunate if the DHCP provisioning mechanism would not support multiple domains.

Agreed, and it would be similar for multiple LW4o6 domains, or both a 
MAP and a LW4o6 domain on the same connection.

I just wanted to ensure we were all discussing the same thing.

Simon