Subject: Re: [Mif-arch-dt] Merge or prioritize

From: Margaret Wasserman <[email-masked]>
Date: Wed, 17 Apr 2013 09:42:08 -0400

Could we start using the mailing list for these discussions (which you can do by replying to this message)?  That way, our discussions will be archived.

Thanks,
Margaret

On Apr 17, 2013, at 4:18 AM, Hui Deng <[email-masked]> wrote:

> I don't have strong requirement for that specific route, but some other opeartor does, we may ignore them,
> for VPN case, it will push specific routes, ok, it depends on how large of provisioing domain , if it is just local provisioning domain, then it might push such routes to the host. in this case, DNS has RFC 6731 to solve that issue?
> 
> 2013/4/17 Marc Blanchet <[email-masked]>
> - you would need to push specific routes to the host. It may be pretty complicated/not scalable (read impossible) for a large provider to push a large number of routes related to his own specific services.
> - second, this does not help for name resolution. there are two dns servers, but each one may have specific names or not specific names but specific resource records. the routing you describe does not help this.
> 
> Marc.
> 
> Le 2013-04-17 à 09:43, Hui Deng <[email-masked]> a écrit :
> 
> > one thought
> >
> > 1) Suppose host got two configurations from two different provisioning domain, for example, both have a default route
> > 2) then finally host will list both of them in the routing table, but it will not merge them, just prioritize one default route than other based on metrics
> > Based on above
> > 1) host will mostly follow one prioritized provisioning domain, even it received two configurations from different provisioning domain.
> > 2) host could connect with the second domain based on specific route if configured
> > 3) follow which provisioing domain is equal to follow collapsed routing table.
> >
> > -Hui
> 
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 17 Apr 2013 22:29:33 +0800

yes, we should use this, thanks for Margaret's remindness. Based on Marc's comments, I think I should rephrase the 2nd item, not sure 3rd item need mention DNS.  1) Suppose host got two configurations from two different provisioning domain, for example, both have a default route
 2) then finally host will list both of them in the routing table, but it will not merge them, just prioritize one default route than other based on metrics
 Based on above
 1) host will mostly follow one prioritized provisioning domain, even it received two configurations from different provisioning domain.
 2) host could connect with the second domain based on specific route if configured which may only happen in the local provisioning domain
 3) follow which provisioing domain is equal to follow collapsed routing table. 
-Hui From: [email-masked]
Date: Wed, 17 Apr 2013 09:42:08 -0400
To: [email-masked]
Subject: Re: [Mif-arch-dt] Merge or prioritize

Could we start using the mailing list for these discussions (which you can do by replying to this message)?  That way, our discussions will be archived.
Thanks,Margaret
On Apr 17, 2013, at 4:18 AM, Hui Deng <[email-masked]> wrote:I don't have strong requirement for that specific route, but some other opeartor does, we may ignore them, for VPN case, it will push specific routes, ok, it depends on how large of provisioing domain , if it is just local provisioning domain, then it might push such routes to the host. in this case, DNS has RFC 6731 to solve that issue?

Marc.

> -Hui

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 15:05:31 +0000

Hui, this line of questioning assumes that the host will make a decision, likely with no information, on which bit of provisioning information to prefer.   In general, I think that this is what hosts do now, and it doesn't work.   It has been my opinion for a long time that in order to decide between provisioning domains, the host needs to try connecting using both provisioning domains, not choose one.   For protocols that support multi-path connections, it would make sense to attempt to establish a multi-path link using each provisioning domain as a path, and then actually use whichever paths succeed.

Of course, this model would be moderated by trustworthy information about specific routes and specific DNS zones, but the basic model would be "try everything," not "pick something."

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 17 Apr 2013 16:53:50 +0000

>> It has been my opinion for a long time that in order to decide between provisioning domains, the host needs to try connecting using both provisioning domains, not choose one.

I think while this is one of the ways the host could behave, it would not be necessarily applicable to all scenarios/hosts. 

For example, if the host is connected simultaneously to costly 3G network and free Wi-Fi network (and e.g. 3G connection must be maintained for some cellular specific services), it would not necessarily make sense even in the basic case to use all the available connections instead of using just Wi-Fi.

IMO, a problem MPD shall solve is to provide a mechanism for networks to enable hosts to know that there are multiple domains, to know which pieces of config are associated with which PD. With such knowledge available, the host can make a host-specific decision, driven by host-specific policy/user preferences/etc.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 17 Apr 2013 13:03:57 -0400

> IMO, a problem MPD shall solve is to provide a mechanism for networks
> to enable hosts to know that there are multiple domains, to know which
> pieces of config are associated with which PD. With such knowledge
> available, the host can make a host-specific decision, driven by host-
> specific policy/user preferences/etc.
> 

I agree with this view. This is what we were trying to highlight as
functionalities required in the MIF API on
http://www.ietf.org/id/draft-seite-mif-cm-01.txt.

Of course, the draft was written before this whole MIF architecture
discussion and with the MIF API in mind, so multiple parts don't
necessarily apply here and are probably out of date. However, it was an
attempt to solve the very issue of providing the host the right
information to take the right decision.

> From: [email-masked] [mailto:mif-arch-dt-
> [email-masked]] On Behalf Of Dmitry Anipko
> Sent: Wednesday, April 17, 2013 12:54 PM
> To: Ted Lemon; Hui Deng
> >> It has been my opinion for a long time that in order to decide
> between provisioning domains, the host needs to try connecting using
> both provisioning domains, not choose one.
> 
> I think while this is one of the ways the host could behave, it would
> not be necessarily applicable to all scenarios/hosts.
> 
> For example, if the host is connected simultaneously to costly 3G
> network and free Wi-Fi network (and e.g. 3G connection must be
> maintained for some cellular specific services), it would not
> necessarily make sense even in the basic case to use all the available
> connections instead of using just Wi-Fi.
> 
> IMO, a problem MPD shall solve is to provide a mechanism for networks
> to enable hosts to know that there are multiple domains, to know which
> pieces of config are associated with which PD. With such knowledge
> available, the host can make a host-specific decision, driven by host-
> specific policy/user preferences/etc.
> 
> Hui, this line of questioning assumes that the host will make a
> decision, likely with no information, on which bit of provisioning
> information to prefer.   In general, I think that this is what hosts
do
> now, and it doesn't work.   It has been my opinion for a long time
that
> in order to decide between provisioning domains, the host needs to try
> connecting using both provisioning domains, not choose one.   For
> protocols that support multi-path connections, it would make sense to
> attempt to establish a multi-path link using each provisioning domain
> as a path, and then actually use whichever paths succeed.
> 
> Of course, this model would be moderated by trustworthy information
> about specific routes and specific DNS zones, but the basic model
would
> be "try everything," not "pick something."
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 18:35:18 +0000

> For example, if the host is connected simultaneously to costly 3G network and free Wi-Fi network (and e.g. 3G connection must be maintained for some cellular specific services), it would not necess…

Sure.   However, if the 3G connection is not costly, it's probably better to try both, possibly giving WiFi a headstart so that it wins a fair race.   Otherwise you get Wifi-based intentional or unintentional DoS attacks.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 18:38:06 +0000

> IMO, a problem MPD shall solve is to provide a mechanism for networks to enable hosts to know that there are multiple domains, to know which pieces of config are associated with which PD. With such…

I should say, by the way, that I agree with this.   I just want to emphasize that the strategy is probably some combination of heuristic discovery, local configuration and network-supplied configuration, and that heuristic discovery is likely the best starting point in a lot of cases.   But I don't think we have to say that—the mechanisms we describe in the architecture should simply enable implementors to go in that direction if it turns out that I am right. :)

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 08:53:38 +0000

Hi Ted/Dmitry,

I think we are in agreement, the problem of selection is complex and may depend on lot of criteria such as user preferences, local information (e.g quality of the link), guidance from the network (e.g. selection policies), characteristics of the interfaces, and so on. Juan-Carlos reminded couple of drafts discussing "connection management". Now, I don't think we could define "The strategy" as it will depend on network capabilities, e.g. if the network can provide guidance or not, if multi-path connections is supported or not... and sometimes, there is no other possibility than heuristic discovery, you're right. So, I think that a first step would be to clarify assumptions for network architecture scenarios.

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> De la part de Ted Lemon
> Envoyé : mercredi 17 avril 2013 20:38
> À : Dmitry Anipko
> Cc : [email-masked]; [email-masked]; Hui Deng
> Objet : Re: [mif-arch-dt] [Mif-arch-dt] Merge or prioritize
> 
> I should say, by the way, that I agree with this.   I just want to
> emphasize that the strategy is probably some combination of heuristic
> discovery, local configuration and network-supplied configuration, and
> that heuristic discovery is likely the best starting point in a lot of
> cases.  But I don't think we have to say that-the mechanisms we
> describe in the architecture should simply enable implementors to go in
> that direction if it turns out that I am right. :)
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Cao,Zhen" <[email-masked]>
Date: Thu, 18 Apr 2013 18:37:52 +0800

Hi Ted and all ,
I got a question, do we need to discuss the scenarios and problems for a
CPE or routers that have multiple PDs? These cases could be different from
the host in that they also have inner domains.

Thanks,
zhen

On Wed, Apr 17, 2013 at 11:05 PM, Ted Lemon <[email-masked]> wrote:

> Hui, this line of questioning assumes that the host will make a decision,
> likely with no information, on which bit of provisioning information to
> prefer.   In general, I think that this is what hosts do now, and it
> doesn't work.   It has been my opinion for a long time that in order to
> decide between provisioning domains, the host needs to try connecting using
> both provisioning domains, not choose one.   For protocols that support
> multi-path connections, it would make sense to attempt to establish a
> multi-path link using each provisioning domain as a path, and then actually
> use whichever paths succeed.
>
> Of course, this model would be moderated by trustworthy information about
> specific routes and specific DNS zones, but the basic model would be "try
> everything," not "pick something."
>

---

From: "Dapeng Liu" <[email-masked]>
Date: Thu, 18 Apr 2013 18:40:11 +0800

My opinion is that we should make agreement on the scenario and then focus
on the concrete problem that we want to solve.
	
Dapeng Liu
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, April 18, 2013 4:54 PM
To: Ted Lemon; Dmitry Anipko
Cc: [email-masked]; [email-masked]; Hui Deng
Subject: Re: [mif-arch-dt] [Mif-arch-dt] Merge or prioritize

Hi Ted/Dmitry,

I think we are in agreement, the problem of selection is complex and may
depend on lot of criteria such as user preferences, local information (e.g
quality of the link), guidance from the network (e.g. selection policies),
characteristics of the interfaces, and so on. Juan-Carlos reminded couple of
drafts discussing "connection management". Now, I don't think we could
define "The strategy" as it will depend on network capabilities, e.g. if the
network can provide guidance or not, if multi-path connections is supported
or not... and sometimes, there is no other possibility than heuristic
discovery, you're right. So, I think that a first step would be to clarify
assumptions for network architecture scenarios.

Pierrick

> Cc : [email-masked]; [email-masked]; Hui Deng Objet : Re: 
> [mif-arch-dt] [Mif-arch-dt] Merge or prioritize
> 
> describe in the architecture should simply enable implementors to go 
> in that direction if it turns out that I am right. :)
> 

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.

https://w

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 16:25:57 +0300

> IMO, a problem MPD shall solve is to provide a mechanism for networks to enable hosts to know that there are multiple domains, to know which pieces of config are associated with which PD. With such…

Exactly my thoughts.

I further assume an MPD is a logical concept in a sense that a single administrated network can have severals MPDs with partly overlapping information. An example from cellular/wireless domain: MPD1 has DNS_server_a & prefix_a_with_mobility and MPD2 has again DNS_server_a but prefix_b_without_mobility. 

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 16:35:15 +0300

Exactly my thoughts.

- Jouni

---

From: Dave Thaler <[email-masked]>
Date: Thu, 18 Apr 2013 13:50:39 +0000

Resending to archive...

Hui Deng wrote:

> 1) Suppose host got two configurations from two different provisioning

> domain, for example, both have a default route

> 2) then finally host will list both of them in the routing table, but

> it will not merge them,

Putting both (or more generally all routes received from each) in the routing table and using routing logic is a way to merge them.

>  just prioritize one default route than other based on metrics

Not necessarily, no.   Routing logic does not require prioritizing one strictly over the other.

If the metrics are equal, they may both be used for different destinations.

See RFC 2991 (among various other RFCs).

> 1) host will mostly follow one prioritized provisioning domain, even it received two configurations from different provisioning domain.

Assuming by "mostly" you mean "sometimes, based on configuration" or "often, based on the configurations that most typically occur in practice" then sure, but that doesn't change the fact that merging is done in reality.

> 2) host could connect with the second domain based on specific route

> if configured

Or using the default route if equal cost.

> 3) follow which provisioing domain is equal to follow collapsed routing table.

Didn't understand that.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: Wednesday, April 17, 2013 7:30 AM
To: [email-masked]; [email-masked]
Subject: Re: [mif-arch-dt] [Mif-arch-dt] Merge or prioritize

yes, we should use this, thanks for Margaret's remindness.

Based on Marc's comments, I think I should rephrase the 2nd item, not sure 3rd item need mention DNS.

-Hui
________________________________
From: [email-masked]<mailto:[email-masked]>
Date: Wed, 17 Apr 2013 09:42:08 -0400
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Mif-arch-dt] Merge or prioritize

Thanks,
Margaret

On Apr 17, 2013, at 4:18 AM, Hui Deng <[email-masked]<mailto:[email-masked]>> wrote:

2013/4/17 Marc Blanchet <[email-masked]<mailto:[email-masked]>>

Marc.

> -Hui

_______________________________________________ mif-arch-dt mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: Hui Deng <[email-masked]>
Date: Thu, 18 Apr 2013 22:08:36 +0800

I will made a new thread to discuss scenario to include your mobility case, -Hui 
 > From: [email-masked]
> Date: Thu, 18 Apr 2013 16:35:15 +0300
> To: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]

---

From: Hui Deng <[email-masked]>
Date: Thu, 18 Apr 2013 22:13:59 +0800

thanks for join mailing list. inline please ==>

 
Putting both (or more generally all routes received from each) in the routing table and using routing logic is a way to merge them.
==> hope it is a wording matter, because two routing merge into one, then we call that merge, if they are still two, then I call it prioritize. 
Not necessarily, no.   Routing logic does not require prioritizing one strictly over the other.
If the metrics are equal, they may both be used for different destinations.
See RFC 2991 (among various other RFCs).
==> good point, this is a special case we need to consider  
Assuming by "mostly" you mean "sometimes, based on configuration" or "often, based on the configurations that most typically occur in practice" then sure, but that doesn't change the fact that merging is done in reality.
 ==> I mean later case, same as above, the two configuration still exisit, so shall we still call that merge? 

Or using the default route if equal cost.
 ==> equal cost should be considered. 
> 3) follow which provisioing domain is equal to follow collapsed routing table.
 
Didn't understand that.
==> here collapsed routing table means put all routing table into one final table,  then to select which provisioning domain means select which routing routing table. -Hui

---

From: Dave Thaler <[email-masked]>
Date: Thu, 18 Apr 2013 14:18:28 +0000

To me, "merge" means "use pieces of each, perhaps simultaneously".
So route sets are merged today into a combined routing table.
And DNS server addresses are also merged today in implementations.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: Thursday, April 18, 2013 7:14 AM
To: [email-masked]
Subject: Re: [mif-arch-dt] [Mif-arch-dt] Merge or prioritize

thanks for join mailing list.

inline please ==>

> 3) follow which provisioing domain is equal to follow collapsed routing table.

Didn't understand that.
==> here collapsed routing table means put all routing table into one final table,  then to select which provisioning domain means select which routing routing table.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 18 Apr 2013 22:26:17 +0800

I am assuming that here we don't consider operator's walled gardern service, today 3G is still connected, but that is based on circuit switch for voip, not for IP packet connection and today for small try packet in 3G/LTE, that won't be expensive. -Hui
 > From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Wed, 17 Apr 2013 16:53:50 +0000
> CC: [email-masked]; [email-masked]

---

From: Hui Deng <[email-masked]>
Date: Thu, 18 Apr 2013 22:29:16 +0800

one correction, for Voice, not VoIP -Hui
 From: [email-masked]
To: [email-masked]
Date: Thu, 18 Apr 2013 22:26:17 +0800
Subject: Re: [mif-arch-dt] [Mif-arch-dt] Merge or prioritize

I am assuming that here we don't consider operator's walled gardern service, today 3G is still connected, but that is based on circuit switch for voip, not for IP packet connection
 
and today for small try packet in 3G/LTE, that won't be expensive.
 
-Hui

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Apr 2013 14:37:21 +0000

On Apr 18, 2013, at 6:37 AM, "Cao,Zhen" <[email-masked]<mailto:[email-masked]>> wrote:
I got a question, do we need to discuss the scenarios and problems for a CPE or routers that have multiple PDs? These cases could be different from the host in that they also have inner domains.

I think we do.   For instance because they are providing services for hosts that therefore have multiple provisioning domains.   So we need to talk about how they communicate that information to the hosts, at a minimum.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Apr 2013 15:10:28 +0000

> Putting both (or more generally all routes received from each) in the routing table and using routing logic is a way to merge them.

How would routing logic help?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Apr 2013 15:12:24 +0000

On Apr 18, 2013, at 10:18 AM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:
To me, “merge” means “use pieces of each, perhaps simultaneously”.
So route sets are merged today into a combined routing table.
And DNS server addresses are also merged today in implementations.

Yes.   And this has been a highly successful experiment.   (At least in the sense of showing the problems that occur when you do this... :)

---

From: Aaron Yi DING <[email-masked]>
Date: Wed, 24 Apr 2013 10:13:06 +0300

Dear all,

As discussed during our meeting after Zhen's presentation

Dave Thaler: for existing "testing" techniques see discussion in Happy 
Eyeballs, and also in 
http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03

There is a comprehensive one from Teemu, Jouni and UH
http://www.cs.helsinki.fi/group/wibra/icc12.html

pdf and brief all included for reference.

-- Aaron

---

From: Hui Deng <[email-masked]>
Date: Fri, 26 Apr 2013 22:25:07 +0800

Hello all Thanks a lot for Dmitry, Pierrick, Ding, Marc for their kind help to write the minutes. enclosed are minutes and infomormation element list. Based on the teleconf and some offline conformation, Let's move forward with the following arrangement.: 1) Everybody try to help to contribute the discussion on information element, during the minutes, you can see some reference which Ted has explained how to write them. if possible, please send your discussion to Margaret and Hui by May 10th. 2) MIF PS RFC could be considered to be updated if there is further valid scenario/example coming in, Marc is volunteer to watch it. 3) if you can, please help to propose a definition of MPvD 4) We are going to use PvD to represent Provisioning Domain, MPvD to represent Multiple Provisioining Domain 5) Next teleconf: May 13th, (Monday), Same time, Feel free to share your comments,thanks a lot for your volunteer. Best regards,
 -Margaret & Hui Date: Wed, 24 Apr 2013 10:13:06 +0300
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: [mif-arch-dt] MIF Arch testing techniques

  
    Dear all,

    Dave Thaler: for existing "testing" techniques see discussion in
    Happy Eyeballs, and also in http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03

    -- Aaron

---

From: "Cao Zhen \(CZ\)" <[email-masked]>
Date: Sun, 28 Apr 2013 12:04:44 +0800

Hi Aaron and Dave

Thanks for the pointers to these work. The draft quoted is an expired one, and I went through it. Based on my understanding, it’s more about how to learn the NAT64 prefix, not much about network connectivity test?

The link on how Windows tests connectivity is more related,  shared by Dave http://technet.microsoft.com/en-us/library/ee126135(v=WS.10).aspx

Best regards,

Zhen 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aaron Yi DING
Sent: Wednesday, April 24, 2013 3:13 PM
To: [email-masked]
Cc: Zhen Cao; Dave Thaler
Subject: [mif-arch-dt] MIF Arch testing techniques

Dear all,

Dave Thaler: for existing "testing" techniques see discussion in Happy Eyeballs, and also in http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03

-- Aaron