Subject: [mif] MIF new charter

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Oct 2010 23:50:53 +0300

Folks,

I have looked at the proposed new work items, and I think they make a 
lot of sense. But I did want to fine-tune the text a bit. Here is the 
suggested new charter and the diff to the current one:

http://www.arkko.com/ietf/mif/newcharter.txt
http://www.arkko.com/ietf/mif/charterdiff.html

Comments appreciated.

Jari

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 07:29:48 +0200

Jari,

In the dnsop WG there seemed to be some concerns regarding "split-DNS" terminology: http://www.ietf.org/mail-archive/web/dnsop/current/msg08455.html

Hence we perhaps should consider if some other term, such as "DNS server selection", would be more appropriate? The goal could then look like:

--
1) *DNS server selection* solution: a specification for describing a way for a
network to communicate to nodes information required to perform
advanced DNS server selection *in deployments using local namespaces*. The
specification shall describe the information to be delivered for nodes
and the protocol to be used for delivery.
--
And
--
Jan 2011   Initial WG draft on advanced DNS server selection solution
Nov 2011   Submit advanced DNS server selection solution to IESG for publication as a Proposed Standard RFC
--

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Jari Arkko
> Sent: 10. lokakuuta 2010 23:51
> To: mif
> Subject: [mif] MIF new charter
> 
> Folks,
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2010 09:13:18 +0300

Teemu,

My read of at least the first few e-mails in that thread was that the 
comments were more about having to define what the topic is and the 
general willingness (or not) to take on the work, not about terminology.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 08:36:41 -0700

> Hence we perhaps should consider if some other term, such as "DNS server selection", would be more appropriate? The goal could then look like:

We were really trying to get away from using the word "selection," with the implication that it has of choosing something and sticking with it.   It's not at all clear that there is "a network" that can "communicate to nodes information required to perform name server selection."   Indeed, I would strongly argue that it is quite clear that in many of the most realistic mif scenarios (e.g., 3G+WiFi), it is impossible that any outside agent could accurately know the answer to the question "which DNS server should I use?"

---

From: Scott Brim <[email-masked]>
Date: Mon, 11 Oct 2010 11:52:33 -0400

> Hence we perhaps should consider if some other term, such as "DNS server selection", would be more appropriate? The goal could then look like:

I don't think this captures the essence of the problem, which is not
that local namespace is being used but that multiple namespaces are
being used and can be accessed from different servers.

Scott

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Oct 2010 19:38:29 +0200

Le 11/10/2010 17:36, Ted Lemon a écrit :
> On Oct 10, 2010, at 10:29 PM,<[email-masked]>
> <[email-masked]>  wrote:
>> Hence we perhaps should consider if some other term, such as "DNS
>> server selection", would be more appropriate? The goal could then
>> look like:
>
> We were really trying to get away from using the word "selection,"
> with the implication that it has of choosing something and sticking
> with it.   It's not at all clear that there is "a network" that can
> "communicate to nodes information required to perform name server
> selection."   Indeed, I would strongly argue that it is quite clear
> that in many of the most realistic mif scenarios (e.g., 3G+WiFi), it
> is impossible that any outside agent could accurately know the
> answer to the question "which DNS server should I use?"

I agree, in my 3G+WiFi setting a Client node (Mobile IP MN) has the
choice of setting its DNS server among 3 choices: the one from the WiFi
network, the one from 3G+ network and finally the one in the same
network as the Home Agent.  These 3 DNS Servers and the respective DHCP
Servers will have a hard time co-ordinate to make suggestions to Client
to select from, being in very different networks, separated by firewalls.

One way to avoid "selection" would be to "prefer a DNS Server" depending
on the "default route preference"?

Alex

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 22:29:02 +0200

> > answer to the question "which DNS server should I use?"

I disagree. In that case in particular the (unmodified) WiFi accesses would most likely behave as they currently do (just "default") while the 3G network would say to handset "btw, I happen to know the IP addresses related to privatezones.of.operator.com". Hence the handset could send everything else to WiFi (as generally the preferred of those two accesses), but resolve just those particular accesses via DNS server in 3G.

In the very same style, the 3G access could say "btw, I happen to also know the path to the privatezones.of.operator.com" while WiFi would just be plain "default".

> to select from, being in very different networks, separated by

They don't need to coordinate at all.

Your 3G says:"Ask me operator.com names and send me data going to "2001:abba:cafe::/48. The rest you can put elsewhere, if you mind please-"

Your WiFi says:"I'm legacy router, I don't know this new stuff. I just learned about IPv6."

Your DSMIP6 HA says: 1) "Nothing to see here, I don't know anything special, please use some other DNS server with less latency" or 2) "I know some details of secret.corporate.com, ask me if you dare ". And it can also say:"I'm your default router, please download all Youtube & Bittorrent via me", or "Please send only data going to "2001:cafe:abba::/48 via me, other preferably by using your CoA"

Also 3G, WiFi, and DSMIP6 may all say:"In case of no other DNS servers, you can "default" me as well".

> One way to avoid "selection" would be to "prefer a DNS Server"
> depending on the "default route preference"?

In the case the default DNS servers don't have any priority amongst themselves, one might want to prefer the one with lowest latency or otherwise cheapest (WiFi maybe - or in case of VPN then maybe DNS server behind VPN...)

Best regards,

Teemu

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 22:33:52 +0200

> being used and can be accessed from different servers.

I agree, but how to spell it out? Add ".. perform advanced DNS server selection at name resolution request granularity in scenarios involving multiple namespaces.."?

Teemu

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 22:46:05 +0200

And to make this more concrete, I will bring with me to Beijing some running code on Nokia N900 that demonstrates the DNS server selection and the DHCPv6 route options in action while using 3G and Wifi accesses in parallel (provided the local 3GPP networks allow IPv6 roaming, which I was told it/they should, but let's see).

Teemu

> ext [email-masked]
> Sent: 11. lokakuuta 2010 23:29
> To: [email-masked]; [email-masked]
> Subject: Re: [mif] MIF new charter
> 
> I disagree. In that case in particular the (unmodified) WiFi accesses
> would most likely behave as they currently do (just "default") while
> the 3G network would say to handset "btw, I happen to know the IP
> addresses related to privatezones.of.operator.com". Hence the handset
> could send everything else to WiFi (as generally the preferred of those
> two accesses), but resolve just those particular accesses via DNS
> server in 3G.
> 
> In the very same style, the 3G access could say "btw, I happen to also
> know the path to the privatezones.of.operator.com" while WiFi would
> just be plain "default".
> 
> Your 3G says:"Ask me operator.com names and send me data going to
> "2001:abba:cafe::/48. The rest you can put elsewhere, if you mind
> please-"
> 
> Your DSMIP6 HA says: 1) "Nothing to see here, I don't know anything
> special, please use some other DNS server with less latency" or 2) "I
> know some details of secret.corporate.com, ask me if you dare ". And it
> can also say:"I'm your default router, please download all Youtube &
> Bittorrent via me", or "Please send only data going to
> "2001:cafe:abba::/48 via me, other preferably by using your CoA"
> 
> In the case the default DNS servers don't have any priority amongst
> themselves, one might want to prefer the one with lowest latency or
> otherwise cheapest (WiFi maybe - or in case of VPN then maybe DNS
> server behind VPN...)
> 
> 
> Best regards,
> 
> Teemu
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 13:34:04 -0700

> I disagree. In that case in particular the (unmodified) WiFi accesses would most likely behave as they currently do (just "default") while the 3G network would say to handset "btw, I happen to know…

Hm.   I think we are actually disagreeing on a side issue, now that I think about it a bit more thoroughly.   I agree with your proposed change to the charter.   I don't agree with you on this side issue, but perhaps we should leave that debate for after the charter has been ratified.   The term "server selection" is in the proposed new charter, and while I don't love it, I think we can leave discussion of that point for later.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2010 09:17:58 +0300

All,

I have added Teemu's modified text and added a clarification that the 
API will be defined as abstract API. The latest charter version can be 
seen here:

However, I have also received a question in IAB review that I was unable 
to answer. The question is, why is RFC 4191 insufficient for what the 
second work item (DHCP-based delivery of specific routes) attempts to do?

Jari

---

From: Scott Brim <[email-masked]>
Date: Tue, 12 Oct 2010 08:26:44 -0400

On 10/11/2010 16:33 EDT, [email-masked] wrote:
> I agree, but how to spell it out? Add ".. perform advanced DNS
> server selection at name resolution request granularity in scenarios involving
> multiple namespaces.."?
> 
> Teemu

Teemu: Actually I like that wording.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Oct 2010 10:32:36 +0200

Le 12/10/2010 08:17, Jari Arkko a écrit :
> All,
>
> I have added Teemu's modified text and added a clarification that
> the API will be defined as abstract API. The latest charter version
> can be seen here:
>
> However, I have also received a question in IAB review that I was
> unable to answer. The question is, why is RFC 4191 insufficient for
> what the second work item (DHCP-based delivery of specific routes)
> attempts to do?

One aspect of this question is DHCP vs RA.

RFC 4191 uses Router Advertisements to communicate routes to Hosts,
whereas work item 2 would require DHCP.

There are many reasons which could motivate DHCP instead of RA for this
case - is this the question.

Another aspect of the question is the default route: rfc4191 doesn't
provide a default route, whereas work item 2 "provision client nodes
with small amount of static routing information (e.g. regarding
first-hop selection)" can be read as providing a default route too.

Another aspect of the question is "selection" vs "preference": rfc4191
adds "preference" to a route whereas the work item 2 does not mention
"preference" and its "selection" could be read as to select a route as
typically  is done with longest-prefix match.

I am not sure what does IAB mean when questioning rfc4191 vs work item 2.

Alex

> Jari
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 13 Oct 2010 14:53:45 +0300

Hi,

On Oct 12, 2010, at 9:17 AM, Jari Arkko wrote:

> All,
> 
> I have added Teemu's modified text and added a clarification that the API will be defined as abstract API. The latest charter version can be seen here:
> 
> However, I have also received a question in IAB review that I was unable to answer. The question is, why is RFC 4191 insufficient for what the second work item (DHCP-based delivery of specific routes) attempts to do?

I am myself more of a RFC4191 advocate but.. The thing I have not been able to "reproduce" in a clean way with RAs is directing routes to other next hops (routers) than where the RA originated when there is only one source for more specific route information. I.e. the mif case where the host accepts more specific routes only through one interface. If the host sees RAs from multiple routers on the same link, then directing of routes becomes easier to achieve but harder to manage and the setup looses flexibility unless routers somehow agree on more specific route information between each other. Things like "I am not your default router but I want these specific routes" are easily done using RFC4191 even when multiple interfaces are present.

- Jouni

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 14 Oct 2010 15:14:41 +0200

Hi Jari, All,

allow me to provide  a couple of answers to that question (ones that were
also given/discussed at the MIF WG meeting).

RFC4191 is deemed insufficient when:
- The operator wants to know that the client is actually capable of using
route information advertised (ie enact different behaviour for clients that
do, vs those that don't)
- Pass a different route to specific clients on a multi-access segment.
- Operational practices do not make it attractive or possible to manage
advertised route info on directly attached edge routers (possibly 10000s),

Regards,
Woj.

On 12 October 2010 08:17, Jari Arkko <[email-masked]> wrote:

> All,
>
> I have added Teemu's modified text and added a clarification that the API
> will be defined as abstract API. The latest charter version can be seen
> here:
>
>
> However, I have also received a question in IAB review that I was unable to
> answer. The question is, why is RFC 4191 insufficient for what the second
> work item (DHCP-based delivery of specific routes) attempts to do?
>
>
> Jari
>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 15 Oct 2010 01:19:15 +0300

Hi Woj,

These are good points and obviously valid for DSL/cable deployments. However, for cellular mif use cases the situation is rather different and RFC4191 would fit very well.

- Jouni

On Oct 14, 2010, at 4:14 PM, Wojciech Dec wrote:

> Hi Jari, All,
> 
> allow me to provide  a couple of answers to that question (ones that were also given/discussed at the MIF WG meeting).
> 
> - The operator wants to know that the client is actually capable of using route information advertised (ie enact different behaviour for clients that do, vs those that don't)
> - Operational practices do not make it attractive or possible to manage advertised route info on directly attached edge routers (possibly 10000s),
> 
> Regards,
> Woj.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Oct 2010 15:58:25 -0700 (PDT)

Hi all,
  My comments in line.

Regards,

Behcet

> Hi Woj,
> 
> These are good points and obviously valid for DSL/cable  deployments. However, 
>for cellular mif use cases the situation is rather  different and RFC4191 would 
>fit very well.

{behcet]

>From MIF host (which is assumed to be multi-homed in the real sense of having 
more than one physical interfaces) point of view the differences between RFC 
4191 and DHCP approach are less obvious. 

I agree that RFC 4191 would fit OK. However it has the disadvantage of being 
distributed, i.e. the operator has to configure every AR versus
DHCP one which has the advantage of being centralized, requiring only one server 
to be upgraded to support this feature.

We also can argue that DHCP approach can handle multi-homed cases better than 
RFC 4191 by giving better routes considering availability of these interfaces.

Another advantage for DHCP approach is its extensibility e.g. for QoS, etc.

>route information advertised (ie enact different  behaviour for clients that do, 
>vs those that don't)
>will be defined as abstract API. The latest charter  version can be seen here:
> > 
> > 
>answer. The question  is, why is RFC 4191 insufficient for what the second work 
>item (DHCP-based  delivery of specific routes) attempts to do?
> > 
> > 
> >  Jari

---

From: jouni korhonen <[email-masked]>
Date: Fri, 15 Oct 2010 09:43:33 +0300

> to be upgraded to support this feature.

In cellular systems (e.g. in 3GPP) the originator of the RA is as centralized as their DHCPv6 servers will be. WLANs are different but I don't count them as 'cellular' systems. WiMAX I do not know but probably ANS-GW can be regarded rather centralized node..

> RFC 4191 by giving better routes considering availability of these interfaces.

There are few differences that actually matter when we step out of the DSL/Cable deployments and look at the cellular deployments. First, the host cannot express its support for RFC4191 (as Woj pointed out). Second, RFC4191 cannot be used in a nice way to point specific routes to other routers than itself. Doable but implicitly (I could probably demo it in Beijing).

Other concerns do not really apply as in cellular the end host is directly attached to the router, RA must be sent to the host anyway and the lifetime of the prefix is faith shared with the lifetime of the underlying access link.

> Another advantage for DHCP approach is its extensibility e.g. for QoS, etc.

Cellular systems tend to have other means for QoS etc.. Both protocols are extensible per se, however getting new innovation adopted and actually deployed in RA space is just a way harder task.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Oct 2010 09:11:54 -0700 (PDT)

> In  cellular systems (e.g. in 3GPP) the originator of the RA is as centralized 
>as  their DHCPv6 servers will be.

[behcet] Maybe where you live this is the case but not where I live :-).
It depends very much on many factors such as geography, population, etc.

 >WLANs are different but I don't count them as  'cellular' systems. WiMAX I do 
not know >but probably ANS-GW can be regarded  rather centralized node..

[behcet] You mean ASN-GW? ASN-GWs are like S-GWs, they are access network 
gateways so much more distributed geographically.

> There are few  differences that actually matter when we step out of the 
>DSL/Cable deployments  and look at the cellular deployments. First, the host 
>cannot express its support  for RFC4191 (as Woj pointed out). Second, RFC4191 
>cannot be used in a nice way  to point specific routes to other routers than 
>itself. Doable but implicitly (I  could probably demo it in Beijing).
> 

[Behcet]

Agreed, good point!

> Other concerns do not really apply as  in cellular the end host is directly 
>attached to the router, RA must be sent to  the host anyway and the lifetime of 
>the prefix is faith shared with the lifetime  of the underlying access link.
> 

[behcet]

Sure. Agreed.
> Cellular systems tend to  have other means for QoS etc.. Both protocols are 
>extensible per se, however  getting new innovation adopted and actually deployed 
>in RA space is just a way  harder task.
> 

[behcet]

So you are agreeing with me. Great.

Regards,

Behcet

---

From: Jouni <[email-masked]>
Date: Fri, 15 Oct 2010 19:23:45 +0300

> So you are agreeing with me. Great.

I think I only said both DHCP and RA are extensible as protocols.

- Jouni

---

From: Jouni <[email-masked]>
Date: Fri, 15 Oct 2010 19:52:00 +0300

> It depends very much on many factors such as geography, population, etc.

In cellular archs like 3GPP using GTP that was my assumption here (should have stated that) the DHCP server is in the gateway (PGW/GGSN) which is also the originator of the RA.

- jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Oct 2010 13:37:22 -0700 (PDT)

----- Original Message ----
> From: Jouni <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Wojciech Dec <[email-masked]>; [email-masked]
> Sent: Fri, October 15, 2010 11:52:00 AM
> In cellular archs like 3GPP using GTP that was my assumption here  (should have 
>stated that) the DHCP server is in the gateway (PGW/GGSN) which is  also the 
>originator of the RA.
> 

I am not sure. If you look at RFC 5844, there is DHCP Relay at the MAG (which is 
where S-GW would be) and there is a centralized DHCP server.
For GTP, I think better model is to have DHCP Relay at the AR and have a central 
DHCP server.

In WiMAX, they have DHCP Proxy at ASN-GW but DHCP Proxy needs to be fed by a 
central server like AAA.

Cheers,

Behcet

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2010 12:46:50 +0300

Yet another version of the charter is available here:

Jari