Subject: [mif] How to identify a host with multiple interfaces

From: "shshrosh" <[email-masked]>
Date: Sun, 18 Jan 2009 14:05:17 +0800

Hello, all

I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: "Kai Ju" <[email-masked]>
Date: Sun, 18 Jan 2009 14:29:42 +0800

Hi,

Glad to see your question, because it's a typical user case about multiple
interface.

As I know, when one interface of B has failed, the network should get
it, then ask B to change the IP flow from the failed interface to another.
At the same time, A should know all transformation to maintain their
communication from the network. I prefer the ANDSF to do this work.
If you still have other questions, please feel free to raise them, thanks.
2009/1/18 shshrosh <[email-masked]>

>  Hello, all
>
> I have a problem about multiple interface. Suppose host A communicates with
> host B, which has multiple interfaces. When one interface of B fails, A may
> switch to the address of another interface of B to maintain the
> communication. But how can A know the two addresses corresponde to the same
> host B?
>

---

From: "shshrosh" <[email-masked]>
Date: Sun, 18 Jan 2009 15:07:21 +0800

Hello KaiJu,

Thank you for your advice.
I know little about ANDSF. Is it a draft or an RFC?

发件人： Kai Ju 
发送时间： 2009-01-18  14:29:43 
收件人： shshrosh 
抄送： mif 
主题： Re: [mif] How to identify a host with multiple interfaces 
 
Hi,

Glad to see your question, because it's a typical user case about multiple interface. 

As I know, when one interface of B has failed, the network should get it, then ask B to change the IP flow from the failed interface to another. At the same time, A should know all transformation to maintain their communication from the network. I prefer the ANDSF to do this work.

Hello, all

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 09:30:08 +0200

Hi,
 
In my opinion the fallback (or movement) to use another interface of B
for the same session is not in mif scope, but it is more works for
shim6/hip/etc, right? Or even at application level to reconnect to
different address of B after one fails (the list of addresses
application learns e.g. from DNS).
 
Best regards,
 
    Teemu

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext shshrosh
	Sent: 18 January, 2009 08:05
	To: mif
	Subject: [mif] How to identify a host with multiple interfaces

	Hello, all
	 
	I have a problem about multiple interface. Suppose host A
communicates with host B, which has multiple interfaces. When one
interface of B fails, A may switch to the address of another interface
of B to maintain the communication. But how can A know the two addresses
corresponde to the same host B?

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 19 Jan 2009 15:42:22 +0800

Hi, Teemu

I agree your point here, fallback and movement to use another interface for
the same session will be not in the mif scope.

-Hui

2009/1/19 <[email-masked]>

>  Hi,
>
> In my opinion the fallback (or movement) to use another interface of B for
> the same session is not in mif scope, but it is more works for
> shim6/hip/etc, right? Or even at application level to reconnect to different
> address of B after one fails (the list of addresses application learns e.g.
> from DNS).
>
> Best regards,
>
>     Teemu
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *ext
> shshrosh
> *Sent:* 18 January, 2009 08:05
> *To:* mif
> *Subject:* [mif] How to identify a host with multiple interfaces
>
>   Hello, all
>

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 09:44:56 +0100

Hello,

ANDSF does not come from IETF world. Actually, ANDSF stands for "Access Network Discovery and Selection Function". This function has been introduced in 3GPP architecture in release 8 and aims at providing information/indication/recommendation/etc... to the multi-interface MN for discovery and selection of the "best" access. For details, please see 3GPP TS 23.402 http://www.3gpp.org/ftp/Specs/html-info/23402.htm (section 4.8.2.1)

Regards,
Pierrick
________________________________________
De : [email-masked] [mailto:[email-masked]] De la part de shshrosh
Envoyé : dimanche 18 janvier 2009 08:07
À : Kai Ju
Cc : mif
Objet : Re: [mif]How to identify a host with multiple interfaces

Hello KaiJu,

发件人： Kai Ju

---

From: "shshrosh" <[email-masked]>
Date: Mon, 19 Jan 2009 17:02:03 +0800

Thank you!

发件人： [email-masked] 
发送时间： 2009-01-19  16:45:04 
收件人： [email-masked]; [email-masked] 
抄送： [email-masked] 
主题： RE: [mif]How to identify a host with multiple interfaces 
 
Hello,

发件人： Kai Ju

---

From: "shshrosh" <[email-masked]>
Date: Mon, 19 Jan 2009 17:06:49 +0800

Hi, Hui Deng,

My main problem is not on the movement and fallback. My main point is the identification of a node with mulitple interface. So if other nodes get the identification, they know the interfaces corresponde to the same node.

发件人： Hui Deng 
发送时间： 2009-01-19  15:42:23 
收件人： teemu.savolainen 
抄送： shshrosh; mif 
主题： Re: [mif] How to identify a host with multiple interfaces 
Hi, Teemu

I agree your point here, fallback and movement to use another interface for the same session will be not in the mif scope.

-Hui

Hi,

In my opinion the fallback (or movement) to use another interface of B for the same session is not in mif scope, but it is more works for shim6/hip/etc, right? Or even at application level to reconnect to different address of B after one fails (the list of addresses application learns e.g. from DNS).

Best regards,

    Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext shshrosh
Sent: 18 January, 2009 08:05
To: mif
Subject: [mif] How to identify a host with multiple interfaces

Hello, all

---

From: <[email-masked]>
Date: Tue, 20 Jan 2009 10:32:53 +0100

Hello,
 
The issue is out of MIF scope but, anyway, I'd like to bring few comments:
 
Host A does not have to know anything about host B. If host the current interface of B goes down, the onus of selecting a new interface is on host B and not on host A. Then if host B is changing the interface, host B may steer a mobility protocol to maintain IP session continuity (there are a couple of protocol for that and it is out of MIF scope) but it is not host A which maintain session continuity on host B.
 
Regards,
Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : lundi 19 janvier 2009 08:42
À : [email-masked]
Cc : [email-masked]
Objet : Re: [mif] How to identify a host with multiple interfaces
 
Hi, Teemu

-Hui

Best regards,
 
    Teemu

---

From: Hui Deng <[email-masked]>
Date: Wed, 21 Jan 2009 23:07:04 +0800

---

From: Hui Deng <[email-masked]>
Date: Wed, 21 Jan 2009 23:09:17 +0800

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Jan 2009 01:13:44 +0200

I had no major objections. A couple of points, however:

> In this document, the multi-homed host does not forward any packet
> between its interfaces.  Therefore forwarding devices are out of
> scope of this document.
>   

You might consider adding a discussion about implications of weak/strong 
host model here.

> Some received configuration objects are
> specific to an interface such as the IP address and the link prefix.
> Others are typically considered by implementations as being global to
> the node, such as the routing information (default gateway), DNS
> servers IP addresses and address selection policies.
>   

How well has the distinction been defined, really? Its clear for some 
things, but is, e.g., clear for all DHCP options?

> A multi-homed host may have multiple routes to a destination.
> However, by default, it does not have any hint concerning which
> interface would be the best to use for that destination.  For
> example, as discussed in
> [I-D.savolainen-6man-fqdn-based-if-selection <http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I-D.savolainen-6man-fqdn-based-if-selection>] and
> [I-D.hui-ip-multiple-connections-ps <http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], a service provider might want
> to influence the routing table of the host connecting to its network.
> (TBD: expand)
>   
This section really makes two separate points. First, you do not know 
which interface to use for a particular packet. Second, service provider 
routing hints are simply yet another example of configuration data that 
needs to be reconciled between interfaces. It might be better to keep 
these problems separate.

> An address selection policy [RFC3484 <http://tools.ietf.org/html/rfc3484>] is used to choose the right
> source and destination address for a new connection.  It is
> implemented globally in the node IP stack.
>
> As discussed in [RFC4291 <http://tools.ietf.org/html/rfc4291>], a multi-homed host with IPv4 and IPv6
> connectivity might need to receive an update of its default address
> selection policy.  However, that policy is only valid within the
> context of the interface it received it from.  Each network on which
> the node is connected might have a different address policy to push
> to the connecting nodes" The received policies might be conflicting.
> There is currently no standard mechanism to determine what should be
> the behavior of the stack in such case.
>   

Again, there seems to be two issues. The first issue is having a policy 
that tells an application which addresses to use (and indirectly which 
interface to use). The second issue is that if the policy comes, e.g., 
via DHCP on a per-interface basis, then we again have to reconcile the 
different policies on a per-node basis.

My personal classification of problems in the multiple interface space 
includes the following:

1) Access selection, i.e., which network(s) to attach to using the 
physical interface(s) that the host has. Already covered in RFC 5113.

2) Split DNS: If a host is attached to a number of different interfaces, 
how does it resolve a FQDN if more than one interface has provided a DNS 
server address?

3) Configuration reconciliation: how do we merge and use DHCP and other 
configuration information in a node, when the information is received on 
a per-interface basis?

4) Routing: If a host is attached to a number of different interfaces, 
where does a particular IP packet go?

5) Address selection: If a host is attached to a number of different 
interfaces, which addresses should be used for a particular application 
flow?

6) Tunnel multihoming: If a host is attached to a number of different 
interfaces and runs some kind of a tunneling or mobility back to a home 
agent, which interface and addresses should be used for a particular 
packet? Already covered in existing MEXT WG work items.

7) Is there a way for the host and the network to communicate about 
their policies regarding all of the above?

My understanding is that the proposed BOF would be looking at problems 
2, 3, 4, 5, and 7. The others are covered elsewhere.

Jari

---

From: Peny Yang <[email-masked]>
Date: Thu, 22 Jan 2009 10:06:31 +0800

Please check my lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <[email-masked]> wrote:
> Again, there seems to be two issues. The first issue is having a policy that
> tells an application which addresses to use (and indirectly which interface
> to use). The second issue is that if the policy comes, e.g., via DHCP on a
> per-interface basis, then we again have to reconcile the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues. Another point in my mind may
be a possible issue. When a peer tries to initiate flows with MIF
node, we need some way to let the peer know the policies and follow
the policies of MIF node.

> 1) Access selection, i.e., which network(s) to attach to using the physical
> interface(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different interfaces, how
> does it resolve a FQDN if more than one interface has provided a DNS server
> address?
>
> configuration information in a node, when the information is received on a
> per-interface basis?
>
> 4) Routing: If a host is attached to a number of different interfaces, where
> does a particular IP packet go?
>
> agent, which interface and addresses should be used for a particular packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate about their
> policies regarding all of the above?
[Peny] For 7, maybe we could make the way for host/PEER/network to
communicate their policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
communicate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
[Peny] Some other points I have been thinking of:
1) MIF for IPv4 or IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
internet is not available (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny

---

From: <[email-masked]>
Date: Thu, 22 Jan 2009 10:14:49 +0100

Please see inline comment.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Peny
> Yang
> Envoyé : jeudi 22 janvier 2009 03:07
> À : Jari Arkko
> Cc : mif
> Objet : Re: [mif] draft-blanchet
> 
> Hi, Jari:
> 
> Please check my lines:
> 
> that
> physical
> how
> a
> packet?

IMHO, MIF management should be independent from mobility protocol. Actually, multi-interface management can be described in 4 steps:

1. Initiation: management of events which are expected to start multi-interface management process (detection of new access network, loss of interface, user launch an application, etc....)
2. Decision: The terminal selects the "best" interface to use.
3. Preparation - e.g. acquisition of IP address on selected interface, AAA, and so on.
4. Mobility execution - IP session continuity with MIP or derived

IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or may not, steer mobility protocol (step 4). If so, mobility protocol runs as specified in RFCs (3775, 5213,...), without interaction with MIF mechanisms.

Comments are welcome.

Regards,
Pierrick

---

From: Kevin Chin <[email-masked]>
Date: Wed, 21 Jan 2009 19:32:06 -0800

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 22 Jan 2009 14:22:26 -0800

One question at the end of the email

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari
> Arkko
> Sent: Wednesday, January 21, 2009 3:14 PM
> To: mif; Marc Blanchet
> Subject: [mif] draft-blanchet
> 
> I have comments on
> http://tools.ietf.org/html/draft-blanchet-mif-problem-statement
> 
> > [I-D.savolainen-6man-fqdn-based-if-selection
> <http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I-
> D.savolainen-6man-fqdn-based-if-selection>] and
> > [I-D.hui-ip-multiple-connections-ps <http://tools.ietf.org/html/draft-
> blanchet-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], a
> service provider might want

How is it 4 different from 6? My understanding is 6 already covers how routing is performed as you indicated. Or is the intention of 4 to provide hints to e.g. MIPv6 extensions so that a certain interface/CoA is registered for a given IP flow?

Thanks
Gerardo

---

From: Tao Sun <[email-masked]>
Date: Fri, 23 Jan 2009 15:05:54 +0800

---

From: Tao Sun <[email-masked]>
Date: Fri, 23 Jan 2009 15:16:11 +0800

---

From: Tao Sun <[email-masked]>
Date: Fri, 23 Jan 2009 15:19:28 +0800

---

From: Tao Sun <[email-masked]>
Date: Fri, 23 Jan 2009 15:25:32 +0800

---

From: Tao Sun <[email-masked]>
Date: Fri, 23 Jan 2009 15:38:13 +0800

---

From: Kai Ju <[email-masked]>
Date: Fri, 23 Jan 2009 18:50:25 +0800

---

From: Kevin Chin <[email-masked]>
Date: Fri, 23 Jan 2009 10:20:19 -0800

---

From: Hui Deng <[email-masked]>
Date: Mon, 26 Jan 2009 23:33:31 +0800

Hi, Kevin,

I feel that you give two good advice here,
Please allow me more clarification inline below:

2009/1/24 Kevin Chin [email-masked]

> "communicate their policies among host/peer/network" seems to imply more
> message intensive transfer of state from MS.
> Privacy concerns are also legitimate if network needs information from MS
> to support MIF.
>
Are you saying that sending information from MS to network is a kind of
disclose privacy concern? can you help to elaborate more on that?

>
> "policy conflict when >1 operator/network" can not optimize for device
> specific policies, there are trade-offs between "monetary cost" and
> speed/access/convenience.
>
I could fee that it will be hard if there is policy confliction.but we can
do sth in some scale.
for what you said here, convenience and cost can't be achieved
simultaneously, what do you
mean about "monetary cost" here?

thanks for your explanation.

-Hui

>
> thanks
>
>
> On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <[email-masked]> wrote:
>
>> Hi, Kevin,
>>
>> I tend to agree with you here that the terminal may not need to upstream
>> the capability to the network. but do you see any proposal here doing that?
>>
>> but sometime, MS made some decision on the interface and route, but what
>> happen if network congested, how to handle that? just waiting for the fall
>> back.
>>
>> For confliction of policy, I guess that it could be categorized by two
>> case,
>> one operator, then it should be avoided by offline arrangement,
>> for two ISPs,  FIFO still work there, cause no problem for user's traffic.
>>
>> thanks for the discussion.
>>
>> -Tao
>>
>>
>> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <[email-masked]> wrote:
>>
>>>
>>>
>>>  Very interesting topic.
>>> I assume MIF is optional "should" v. "must" w.r.t policies from the
>>> network (e.g. guidance not directive).
>>> The MS may have lots of policies which can make an informed decision.
>>>
>>> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF.
>>> This would imply MS pushing characteristics up to the network so the
>>> network can push device-specific directives down.
>>>  It should not be the case that the device needs to push capabilties
>>> upstream for the network to provide MIF-based guidance.
>>>
>>> Furthermore there may be different networks on each interface
>>> necessitating conflict resolution protocols, let alone issues that occur
>>> sporadically (e.g. WiFI portal, network roaming policies, access-based
>>> policy) ....
>>>
>>> Can't device based provisioning with (optional) input from network
>>> address most of the stated issues?
>>>
>>> thanks-
>>> Kevin
>>>
>>>   On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <[email-masked]>wrote:
>>>
>>>> Hi, Jari:
>>>>
>>>> Please check my lines:
>>>>
>>>> 2, 3,

---

From: Kevin Chin <[email-masked]>
Date: Mon, 26 Jan 2009 16:12:46 -0800

1) "Are you saying that sending information from MS to network is a kind of
disclose privacy concern? can you help to elaborate more on that?"

My assumption was the MS would pass on NAI, ISIM, or other mechanism which
can be used as index into database. This same information can be used to
track presence and location. Not a concern for your current Mobile Operator
but when there are 2 or more parties involved, it should not assume network
information can be freely shared across organizations. Some users may not
want certain hosts to be accessed over a certain network -- e.g. sports
scores during working hours...

 2) "I could fee that it will be hard if there is policy confliction.but we
can do sth in some scale.
for what you said here, convenience and cost can't be achieved
simultaneously, what do you
mean about "monetary cost" here?"

Assume I have WLAN and Cellular data interfaces. Further assume WLAN is free
and where cellular data is not.
A user may want to use WLAN even though non-optimal routing. There are also
counter-examples of cost v. convenience.
The best path is not always fastest or shortest path -- monetary cost may be
a factor.

thanks

On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng <[email-masked]> wrote:

>>> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <[email-masked]>wrote:
>>>
>>>>
>>>>

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 11:17:10 +0100

Hi Kevin,

As you stated, the user may prefer, depending on the application, access with lowest cost even if loosing QoS. I definitely agree but it's just an example and there are plenty of others criteria that may come into play.

I also agree with your first statement. Some actors may want for information/policy to not be disclosed. In addition to your example, an operator may not want to disclose its selection policies or network load information (assuming load is part of the selection criteria).

Anyway, if these considerations are very interesting and fundamentals, I'm not sure they are in the scope of MIF and IETF. But, maybe I'm missing something; are you proposing to work on access selection problem?

Actually, now I'm confused about the scope of MIF. Hui, can you clarify MIF's scope? Do you have hints for a charter? What about Jari's proposal?

Regards,
Pierrick

> De : [email-masked] [mailto:[email-masked]] De la part de
> Kevin Chin
> Envoyé : mardi 27 janvier 2009 01:13
> À : Hui Deng
> Cc : mif
> 1) "Are you saying that sending information from MS to network is a kind
> of disclose privacy concern? can you help to elaborate more on that?"
> 
> track presence and location. Not a concern for your current Mobile
> Operator but when there are 2 or more parties involved, it should not
> assume network information can be freely shared across organizations. Some
> users may not want certain hosts to be accessed over a certain network --
> e.g. sports scores during working hours...
> 
> Assume I have WLAN and Cellular data interfaces. Further assume WLAN is
> free and where cellular data is not.
> A user may want to use WLAN even though non-optimal routing. There are
> also counter-examples of cost v. convenience.
> The best path is not always fastest or shortest path -- monetary cost may
> be a factor.
> 
> thanks
> Can't device based provisioning with (optional) input from network address
> most of the stated issues?
> 
> thanks-
> Kevin
> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <[email-masked]> wrote:
> Hi, Jari:
> 
> Please check my lines:
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 28 Jan 2009 00:10:02 +0800

Hi, Kevin,

I guess that you raise one basic requirement which MIF should be takeing
care with, one is not disclose user privacy information and should think
the different policy on other links.

Secondly, we should allow user could select cost other than better
optimal routing. MIF does allow the host do that, what mif would like to do
is to offer the other(better) choice for them.

These two points you raised are not conflicted with current mif's intention
but good remindness for our work.
many thanks for your comments.

-Hui

2009/1/27 Kevin Chin <[email-masked]>

>  2) "I could fee that it will be hard if there is policy confliction.but
> we can do sth in some scale.

---

From: Hui Deng <[email-masked]>
Date: Wed, 28 Jan 2009 00:17:19 +0800

Hi, Pierrick,

You made the two points Kevin raised more clear from the ISP's point of
view.
I couldn't agree with you any more on it. As you said here, those are not in
the scope of current MIF's proposal. for network discovery and selection,
RFC 5113 already did a clear analysis on it which we could refer on it.

For yoru question about what mif's scope at the moment, Jari already made
the comments on
http://www.ietf.org/mail-archive/web/mif/current/msg00050.html
As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we should narrow
down our scope based on current PS drafts:
http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt
http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt
http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt

Thanks again.
Best regards,

-Hui

2009/1/27 <[email-masked]>

> Hi Kevin,
>
>
> As you stated, the user may prefer, depending on the application, access
> with lowest cost even if loosing QoS. I definitely agree but it's just an
> example and there are plenty of others criteria that may come into play.
>
> I also agree with your first statement. Some actors may want for
> information/policy to not be disclosed. In addition to your example, an
> operator may not want to disclose its selection policies or network load
> information (assuming load is part of the selection criteria).
>
> Anyway, if these considerations are very interesting and fundamentals, I'm
> not sure they are in the scope of MIF and IETF. But, maybe I'm missing
> something; are you proposing to work on access selection problem?
>
> Actually, now I'm confused about the scope of MIF. Hui, can you clarify
> MIF's scope? Do you have hints for a charter? What about Jari's proposal?
>
> Regards,
> Pierrick
>
> >
> > > to use). The second issue is that if the policy comes, e.g., via DHCP
> on
> > a
> 2,
> > 3,

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 17:23:08 +0100

Thanks for clarification.

De : Hui Deng [mailto:[email-masked]] 
Envoyé : mardi 27 janvier 2009 17:17
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]; [email-masked]
Objet : Re: [mif] draft-blanchet
 
Hi, Pierrick,
 
You made the two points Kevin raised more clear from the ISP's point of view.
I couldn't agree with you any more on it. As you said here, those are not in the scope of current MIF's proposal. for network discovery and selection, RFC 5113 already did a clear analysis on it which we could refer on it.
 
For yoru question about what mif's scope at the moment, Jari already made the comments on
http://www.ietf.org/mail-archive/web/mif/current/msg00050.html
As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we should narrow down our scope based on current PS drafts:
http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt
http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt
http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt

Thanks again.
Best regards,
 
-Hui

Regards,
Pierrick

---

From: Peny Yang <[email-masked]>
Date: Sun, 1 Feb 2009 14:34:43 +0800

Hi, Pierrick:

Check my lines please:

> IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or may not, steer mobility protocol (step 4). If so, mobility protocol runs as specified in RFCs (3775, 5213,...), without interac…

[Peny] Basically, I don't think we need to modify the MIP protocols.
And, I also think MIF should be independent from the MIP protocols. In
last email, I mean the harmonization between MIP stacks and MIF.
In the case you mentioned above, in step 3, MIF may need to instruct
the registration of MIP stack. Some local interfaces may help.
In the meanwhile, if the registration of MIP fails, MIF function may
need to change the policies.
Lastly, MIP protocol may help the policy delivery, although it does
not have to do that.

Some other ideas?

BRG
Peny

---

From: Peny Yang <[email-masked]>
Date: Sun, 1 Feb 2009 14:44:44 +0800

Hi, Tao:

Please check my lines below:

On Fri, Jan 23, 2009 at 3:25 PM, Tao Sun <[email-masked]> wrote:

> ==> let peer know the MIF node, it will break IP model of Internet
> or have to be involved in mobility protocol, so I would recommend MIF not
> working on that.
[Peny]  Sorry, I don't get your point here. What do you mean on "let
peer know the MIF node"? If peer would like to set up a session with
MIF node, it must at least know the address of MIF node. Did I miss
something here?

> ==> it is possible to allow network to communiate the policy,
> but it will be diffcult to allow host and node to communicate with each
> other about policy, right?
[Peny] The peer does not have to communicate with MIF node for
policies. It can consult with the network to get the policies.

> ==> I agree Pierrick's point here.
[Peny] Please check my mail to Pierrick.

> ==> I guess that user should judge and decide how to handle this case.
> what do you think?
[Peny] Yeah. It's one of the possible solutions. IMHO, at least in the
policies, such kind of cases  should be covered. Otherwise, if some
applications try to select such kind of interfaces and can not get
connected, the user experience will be decreased greatly.

BRG
Peny

---

From: Peny Yang <[email-masked]>
Date: Sun, 1 Feb 2009 15:46:10 +0800

Hi, Kevin:

> message intensive transfer of state from MS.
[Peny] So far, I still can not judge how intensive the message
exchange is, when peer want to know some policies of MS. Basically, if
MS want one kind of sessions (like VoIP) go through one interface,
when the peer tries to set up this session, the peer at least should
know which interface of MS should be contacted.

BRG
Peny

>>>> > on a