Subject: [mif] Charter proposal

From: Hui Deng <[email-masked]>
Date: Tue, 3 Feb 2009 17:22:03 +0800

Hi, all

Please feel free to help to comments our charter proposal.

Background and Motivation
   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".

   But the IETF RFCs only allow one default network connection.
   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously
active.

   A multi-homed host receives node configuration information from each
   of its access networks.  Some configuration objects are global to the
   node, some are local to the interface.  Various issues arise when
   multiple configuration objects that are global to the node are
   received on the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 proposed
   default address selection for IPv6 could be a refernce to this work.

Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:

 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS
query

 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose best
   interface.Thus a host would need to be provided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o 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. A standard mechanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)

The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.

The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.

Many thanks for your comments

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 03 Feb 2009 10:40:48 +0100

Hi Hui,

thanks for writing this up

see some comments below...

>    But the IETF RFCs only allow one default network connection.
this is a bit too assertive for my taste...

>    default address selection for IPv6 could be a refernce to this work.
I think you need to explicitly state whether the scope for this work is 
IPv4, IPv6 or both

>   A mechanism is needed for selecting the right DNS service for the 
> DNS query
>  

Isnt' this assuming a solution? I mean, i could think that we don't need 
to select the right DNS service, but gather as much information as 
possible and then let the host to select the right RR of all the replies 
it got.

In v4, is there any relation with NAT traversal techniques? I mean, if 
you are referring to private addresses
>    for interface selection(Proposed Standard)
Is this for v4 or v6 or both?

For IPv6, Isn't this already done in RFC4191?

what additional work since RFC4191 are you proposing?

>    an update of its default address selection policy.

Isn't this a bit premature? i mean, we don't even have a mean to 
dynamically update the policy table yet...

Besides, it may make sense to allow the people that are working in the 
dynamic updates of the policy table to do this work as well

Regards, marcelo

>   However, that policy
> ------------------------------------------------------------------------
>

---

From: Ruri Hiromi <[email-masked]>
Date: Tue, 3 Feb 2009 18:54:13 +0900

Hi,

I just want to know about these things are out of scope or not at mif.

o How to specify interface and bundles address prefix?
o Is there some specific Address Assignment policy?
o Is there a possibility of bundle applications with interface and  
address prefix?
o How to carry out multidimensional classification/separation/control  
in one device?
o Description of the total system/architecture? or we want to have an  
aspect of technique/parts here?

Regards,

On 2009/02/03, at 18:22, Hui Deng wrote:

>    leads to difficulties when multiple connections are  
> simultaneously active.
>
>    o a multi-homed host with IPv4 and IPv6 connectivity might need  
> to receive
>    Each network on which the node is connected might have a  
> different address

-------------------------------
Ruri Hiromi
Intec NetCore, Inc. / Keio university
[email-masked]

---

From: Peny Yang <[email-masked]>
Date: Tue, 3 Feb 2009 18:45:59 +0800

Hi, Hui:

>    leads to difficulties when multiple connections are simultaneously
[Peny] Well, IMHO, in RFC1122, only when node has no route cache entry
for the destination host address of flows, it will choose the default.

>    default address selection for IPv6 could be a refernce to this work.
[Peny] Just for clarification, Is IPv6 assumed to be the major
consideration of MIF? Maybe we could define the scope of v4/v6 here.

> Proposed Work:
[Peny] This makes sense.

>    for interface selection(Proposed Standard)
[Peny] Here is a little ambiguous. Do you mean to choose the best
default interface of the node? Or choose the best interfaces for
different applications/flows in the node?

>    the behavior of the host in such case.(Proposed Standard)
[Peny] I support. The harmonization of multiple policies is useful.

BRG
Peny

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Feb 2009 09:44:55 -0800 (PST)

Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I think that especially more mobile hosts with multiple interfaces joining the networks (simultaneously) is likely increase the need for IPv6 so more attention to IPv6 is probably needed.

Regards,

Behcet

________________________________
From: Hui Deng <[email-masked]>
To: mif <[email-masked]>
Sent: Tuesday, February 3, 2009 3:22:03 AM
Subject: [mif] Charter proposal

Hi, all

   leads to difficulties when multiple connections are simultaneously active. 

Proposed Work:
-------------

 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS query

 Address Selection Policy:
   o 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. A standard mechanism is needed to determine what should be 
   the behavior of the host in such case.(Proposed Standard)

-Hui

---

From: Yonggeun Hong <[email-masked]>
Date: Wed, 4 Feb 2009 11:52:18 +0900

Hi, Hui.

Thanks for your efforts.

It's well described and written.

See inline comments.

2009/2/3 Hui Deng <[email-masked]>

>    virtual).  For example, a node may be connected to a wired Ethernet
 I think that "physical and/or logical" expression is more appropriate.

>    default address selection for IPv6 could be a refernce to this work.
May I ask is it needed to make conceptual models for MIF?
Even though weak host model and strong hotel is described in RFC1122,
is it enough to describe MIF environment?

And I would like to ask how about study motivations and scenarios for MIF as
a separate topic.
In MEXT WG, there is a similar draft.

http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03
I think that motivations and scenarios for MIF may be different to those of
MEXT, so I ask that.

Best regards.

Yong-Geun.

---

From: Yonggeun Hong <[email-masked]>
Date: Wed, 4 Feb 2009 13:31:58 +0900

Hi, all.

I have same opinion.

Although MIF is not directly related to only IPv6,
I think that it is better to focus on IPv6 because;

1. Multiple interfaces needs multiple IP addresses which are assigned to
each interfaces
  if multiple interfaces are simultaneously used. So large number of IPv6
address are more proper.

2. As shown in proposed charter, MIF will be complementary to the exist IETF
working group such as
  MEXT and 6MAN. These working groups handle IPv6 and we must consider the
collaboration with
  these working groups.

It is only my opinion and it must be clarified before going ahead.

Best regards.

Yong-Geun.

2009/2/4 Behcet Sarikaya <[email-masked]>

> I agree with others on IPv4/IPv6 support. It should be clarified. I think
> that especially more mobile hosts with multiple interfaces joining the
> networks (simultaneously) is likely increase the need for IPv6 so more
> attention to IPv6 is probably needed.
>
> Regards,
>
> Behcet
>
>  ------------------------------
> *From:* Hui Deng <[email-masked]>
> *To:* mif <[email-masked]>
> *Sent:* Tuesday, February 3, 2009 3:22:03 AM
> *Subject:* [mif] Charter proposal
>
> Hi, all
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 16:08:55 +0800

Hi, Marcelo,

Thanks for your comments, reply inline below.

2009/2/3 marcelo bagnulo braun <[email-masked]>

> this is a bit too assertive for my taste...

==> thanks for your remindness, we would better to change more smooth words
after.

> I think you need to explicitly state whether the scope for this work is

==> Ok, we will explicitly say that we will cover both.

> Isnt' this assuming a solution? I mean, i could think that we don't need to
> select the right DNS service, but gather as much information as possible and
> then let the host to select the right RR of all the replies it got.

==> maybe we can remove the last sentence which you are ok, teemu?

>
> In v4, is there any relation with NAT traversal techniques? I mean, if you
> are referring to private addresses

==> Even if it is the private address, we are not stick to any nat traversal
traversal techniques.
current charter are targeting the simplest way to do it.

>> Is this for v4 or v6 or both?
==> will reword make it explicitly say both IPv4/IPv6.

> what additional work since RFC4191 are you proposing?

RFC 4191 already specify to extend RA to communicate the prefernce and
specific routing prefix, it doesn't cover a full fledges information for a
routing and also not include for DHCP support.

> dynamically update the policy table yet...

I can see some work already done here, especially inside the connection
manager of Mobile OSs.

> dynamic updates of the policy table to do this work as well

We are welcome people who has done this work could join MIF work.

thanks again
Best regards,

-Hui

---

From: <[email-masked]>
Date: Wed, 4 Feb 2009 09:23:42 +0100

Hi,

That's true. I'm ok to remove the last sentece.

Gathering RR information from all DNS servers would cause more traffic to be sent (possibly triggering activation of radio), and would reveal to all DNS servers what names the host is trying to resolve. Thus sounds less efficient for me, but I will take a note of this for the next version.

Best regards,

    Teemu

 Proposed Work:
-------------

Isnt' this assuming a solution? I mean, i could think that we don't need to select the right DNS service, but gather as much information as possible and then let the host to select the right RR of all the replies it got.
==> maybe we can remove the last sentence which you are ok, teemu?

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 16:26:16 +0800

hi, Ruri,

reply inline.

2009/2/3 Ruri Hiromi <[email-masked]>

> I just want to know about these things are out of scope or not at mif.

==> Thanks for your query here.

> o How to specify interface and bundles address prefix?

==> Basically, we are targeting the connection manager work, this question
match it.

> o Is there some specific Address Assignment policy?

==> it has to do some address assignment policy to make source address
selection really happen, Marc may has more idea on this.

>
> o Is there a possibility of bundle applications with interface and address
> prefix?

==>Connection manager already did this.

>
> o How to carry out multidimensional classification/separation/control in
> one device?

==> This seems more complicated in the current work.

> aspect of technique/parts here?

==> Basically we are not going to work out final connection manager
archtiecture and system
it could be done in other standard body, here is more protocol oritented.

Thanks and regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 17:06:00 +0800

Hi, Peny,

Thanks for your comments, reply inline.
2009/2/3 Peny Yang <[email-masked]>

> for the destination host address of flows, it will choose the default.

==> you said it here.

> consideration of MIF? Maybe we could define the scope of v4/v6 here.

==> Thanks, we will clarify that we are going to support both of them
explicitly

> >   A mechanism is needed for selecting the right DNS service for the DNS

==> thanks

> different applications/flows in the node?

==> You are right, we should reword to make it more explicitly that to
support multiple
interface simultaneously other than only default route.

> [Peny] I support. The harmonization of multiple policies is useful.

==> thanks

Best regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 17:20:50 +0800

Hi, Behcet,

Thanks for your remindness that IPv4/IPv6 support should be explicitly
stated.
As you said here, IPv6 address is more urgent for the mobile host.

Thanks again.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 17:43:05 +0800

Hi, Yonggeun,

Reply inline,
2009/2/4 Yonggeun Hong <[email-masked]>

>   if multiple interfaces are simultaneously used. So large number of IPv6
==> agree here.

>
> 2. As shown in proposed charter, MIF will be complementary to the exist
> IETF working group such as  MEXT and 6MAN. These working groups handle IPv6
> and we must consider the collaboration with  these working groups.
>
==> Agree agin.

> It is only my opinion and it must be clarified before going ahead.
==> Sure, we will also cover IPv4 as well here,

thanks

-Hui

---

From: <[email-masked]>
Date: Wed, 4 Feb 2009 10:50:34 +0100

Hi Hui,
 
Thanks for this proposal. I've just two comments on the charter:
 
1.	I agree with Peny regarding item " Routing of multiple interfaces". The text seems to only deal with update of the default route; it should be clarified that the issue is the selection of the best route among several interfaces simultaneously active.
2.	regarding item " Address Selection Policy". I agree that host behaviour face to conflicting policy is a key issue. But before dealing with conflict, don't you think the charter should deal first with policy transport mechanism, policy format, ...?
 
Regards,
Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : mercredi 4 février 2009 10:06
À : Peny Yang
Cc : mif
Objet : Re: [mif] Charter proposal
 
Hi, Peny,

	
	[Peny] Just for clarification, Is IPv6 assumed to be the major
	consideration of MIF? Maybe we could define the scope of v4/v6 here.
==> Thanks, we will clarify that we are going to support both of them explicitly

	[Peny] This makes sense.
==> thanks 

==> You are right, we should reword to make it more explicitly that to support multiple 

Best regards,
 
-Hui

	
	BRG
	Peny

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 17:51:27 +0800

Hi, Yonggeun

Thanks for your comments, reply inline below,
2009/2/4 Yonggeun Hong <[email-masked]>

>  I think that "physical and/or logical" expression is more appropriate.
Virtual interface means more related Internet, logical interface seems more
like other standard body's word.

> is it enough to describe MIF environment?
current charter follow basic strong model and weak model, it will not
totally change it,
just a small enhancement based on it.

>
> And I would like to ask how about study motivations and scenarios for MIF
> as a separate topic.
Let's see if more people would like to have it.

thanks again.

-Hui

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 11:04:17 +0100

Hui Deng escribió:
>     I think you need to explicitly state whether the scope for this
>     work is IPv4, IPv6 or both 
>

so the scope is both protocols, right?
>     Isnt' this assuming a solution? I mean, i could think that we
>     don't need to select the right DNS service, but gather as much
>     information as possible and then let the host to select the right
>     RR of all the replies it got.
>

well, i guess you need to change the last sentence for al alternative 
wording, that expresses what you are trying to solve

>  
>
>
>     In v4, is there any relation with NAT traversal techniques? I
>     mean, if you are referring to private addresses 
>
> ==> Even if it is the private address, we are not stick to any nat 
> traversal traversal techniques.

but how are you planning to support the IPv4 case? I mean, in IPv6 you 
can extend ND, what do you plan to do for IPv4?
> specific routing prefix,
right

> it doesn't cover a full fledges information for a routing

don't know what you mean by full fledged, but the next step on this is 
for the host to participate in the routing protocol, so it will have all 
the routing information (note that some protoclols support passive mode, 
i.e. only listen to protocol and not send any information, to provision 
hosts with richer routing information

So, are you proposing to do soemthing in between RFC4191 and a full 
routing protocol? If so, what would be the the motivations for it?

> and also not include for DHCP support.
>  
So are you proposing to provide routing information through DHCP?
If so, please state so, cause it is far from obvious from the current 
charter imho
> I can see some work already done here, especially inside the 
> connection manager of Mobile OSs.
>  

No, i mean that in the ietf people are just defining the policy 
distribution mechanisms

>
>
>     Besides, it may make sense to allow the people that are working in
>     the dynamic updates of the policy table to do this work as well
>
well, this is being done in 6man wg afacit

regards, marcelo

> thanks again
> Best regards,
>  
> -Hui
>
>
>
>     Regards, marcelo
>
>
>          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
>         [email-masked] <mailto:[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 23:03:52 +0800

Hi, Pierrick,

Excuse me for a little bit late.
For the first point, thanks for your correction, will revise it asap.

For the second one, I do agree with you that policy transport mechanism
This is very key for both operator and host implementers, and there are
already multiple implemented ways to do it, we do need standardize that. But
I think for Bof proposal, in the early stage, we should only focus on very
narrow point. After assuming WG could be formed, we could work on that soon
by recharter. what do you think?

There are already some people having experience working on source address
selection policy.
they are interested in bring this work here shortly, we will appreciate that
work right from the starting here.

thanks again

-Hui

2009/2/4 <[email-masked]>

>    1. I agree with Peny regarding item " Routing of multiple interfaces".
>    The text seems to only deal with update of the default route; it should be
>    clarified that the issue is the selection of the best route among several
>    interfaces simultaneously active.
>    2. regarding item " Address Selection Policy". I agree that host
>    behaviour face to conflicting policy is a key issue. But before dealing with
>    conflict, don't you think the charter should deal first with policy
>    transport mechanism, policy format, …?
>
>
>
> Regards,
>
> Pierrick
>
>
> *De :* [email-masked] [mailto:[email-masked]] *De la part de*Hui Deng
> *Envoyé :* mercredi 4 février 2009 10:06
> *À :* Peny Yang
> *Cc :* mif
> *Objet :* Re: [mif] Charter proposal
>
>
>
> Hi, Peny,
>
>
>

---

From: <[email-masked]>
Date: Wed, 4 Feb 2009 16:13:49 +0100

De : Hui Deng [mailto:[email-masked]] 
Envoyé : mercredi 4 février 2009 16:04
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]; [email-masked]
Objet : Re: [mif] Charter proposal
 
Hi, Pierrick,

For the second one, I do agree with you that policy transport mechanism
This is very key for both operator and host implementers, and there are already multiple implemented ways to do it, we do need standardize that. But I think for Bof proposal, in the early stage, we should only focus on very narrow point. After assuming WG could be formed, we could work on that soon by recharter. what do you think?
 
Ok, I understand. That makes sense to limit the scope for the sake of clarification.

There are already some people having experience working on source address selection policy.
they are interested in bring this work here shortly, we will appreciate that work right from the starting here.
 
thanks again
 
-Hui

 
 
Regards,
Pierrick

 
Hi, Peny,

	

	[Peny] This makes sense.
==> thanks 

 
Best regards,
 
-Hui

	
	BRG
	Peny

---

From: Hui Deng <[email-masked]>
Date: Wed, 4 Feb 2009 23:31:39 +0800

inline please,

2009/2/4 marcelo bagnulo braun <[email-masked]>

> so the scope is both protocols, right?

==> yes, you are right.

> wording, that expresses what you are trying to solve

==> thanks for your suggestion, Teemu agreed already, let's make it
tentative simple.

> but how are you planning to support the IPv4 case? I mean, in IPv6 you can
> extend ND, what do you plan to do for IPv4?

==> We have multiple choices here, DHCP at the moment or other candidate
protocols (for future such as a new protocol, http, or andsf protocol in
3GPP network)

> don't know what you mean by full fledged, but the next step on this is for
> the host to participate in the routing protocol, so it will have all the
> routing information (note that some protoclols support passive mode, i.e.
> only listen to protocol and not send any information, to provision hosts
> with richer routing information

There are could be metrics information, or other routing parameters which is
needed, but not covered in the rfc 4191. For the passive model, I guess
policy should be conformed somewhere in the network side.

>
>
> So, are you proposing to do soemthing in between RFC4191 and a full routing
> protocol? If so, what would be the the motivations for it?
>

isn't that a solution related? do we need specify clear solution space in
the current charter?

> No, i mean that in the ietf people are just defining the policy

Ok

> well, this is being done in 6man wg afacit

I hope Marc could help to clarify it a little more after he finish his
release today.

thanks again

-Hui

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Feb 2009 13:08:28 -0800 (PST)

Hi Hui,
  Please consider to add the word unicast into the scope limiting parts of the charter.

Regards,

Behcet

________________________________
From: Hui Deng <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: mif <[email-masked]>
Sent: Wednesday, February 4, 2009 3:20:50 AM
Subject: Re: [mif] Charter proposal

Hi, Behcet, 

Thanks for your remindness that IPv4/IPv6 support should be explicitly stated.
As you said here, IPv6 address is more urgent for the mobile host.

Thanks again.

-Hui

Hi Hui,

Regards,

Behcet

Hi, all

Proposed Work:
-------------

 Split DNS:

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 5 Feb 2009 11:50:28 +0800

done in one place,
thanks

-hui

2009/2/5 Behcet Sarikaya <[email-masked]>

> *To:* Behcet Sarikaya <[email-masked]>
> *Cc:* mif <[email-masked]>
> *Sent:* Wednesday, February 4, 2009 3:20:50 AM
> *Subject:* Re: [mif] Charter proposal
>
> Hi, Behcet,
>

---

From: Yonggeun Hong <[email-masked]>
Date: Thu, 5 Feb 2009 18:22:44 +0900

Hi, Hui.
Inline please.

2009/2/4 Hui Deng <[email-masked]>

> like other standard body's word.
 => I think that it is not important issue but IMHO I am more familiar with
"logical" expression in IETF.
      And in RFC 1122, 1.3.3 Terminology section describes that;
      Physical network interface
            This is a physical interface to a connected network and has a
(possibly unique) link-layer address. Multiple physical network

             interfaces on a single host may share the same link-layer
address, but the address must be unique for different hosts on the
             same physical network.
      Logical [network] interface
            We define a logical [network] interface to be a logical path,
distinguished by a unique IP address, to a connected network. See
            Section 3.3.4.

     Best Regards.

     Yong-Geun.

>>  I think that motivations and scenarios for MIF may be different to those
>> of MEXT, so I ask that.
>>

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 00:04:09 +0800

Hi, Marcelo,

inline below,
2009/2/5 marcelo bagnulo braun <[email-masked]>

>>        RFC 4191 already specify to extend RA to communicate the
>>        prefernce and specific routing prefix,
>>
>>    right
>>
>>
>>
>>    don't know what you mean by full fledged, but the next step on
>>    this is for the host to participate in the routing protocol, so it
>>    will have all the routing information (note that some protoclols
>>    support passive mode, i.e. only listen to protocol and not send
>>    any information, to provision hosts with richer routing information
>>
>> There are could be metrics information, or other routing parameters which
>> is needed, but not covered in the rfc 4191. For the passive model, I guess
> You have still not answered my question.
>
> Currently you have two options available to convey route information from
> the router to the host:
> - RFC4191
> - IGPs

Couldn't DHCP be used for convey route information?

>
> You are proposing to define a new one.
> My question is why. What are the features that you need that are not
> provided by the two existent options

In mobile communication, policy is not always stay together with router, or
operator's policy server. some mobile OSs do implement another way to do it.

>
> I think it is important to understand this in order to figure out if this
> item is needed or not
>
>>
>>    So, are you proposing to do soemthing in between RFC4191 and a
>>    full routing protocol? If so, what would be the the motivations
>>    for it?
>>
>>
>>    If so, please state so, cause it is far from obvious from the
>>    current charter imho
> No, but this if this is what you have in mind, i would suggest to include
> it in the charter, so people understnad what you mean.
> I mean, i would have thought that you would use some routing protocol
> rather than dhcp
> regards, marcelo

Ok, I will update it in the next version, keep this point

thanks for the discussion

-Hui

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 00:08:49 +0800

Hi, Yong-geun,

inline reply,

2009/2/5 Yonggeun Hong <[email-masked]>

>> Virtual interface means more related Internet, logical
>> interface seems more like other standard body's word.
>>
I agree if RFC 1122 has already made it, I will update it based on your
suggestion.
thanks for your help to clarify it.

-Hui

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Feb 2009 17:12:35 +0100

Hui Deng escribió:
> Hi, Marcelo,
>  
> inline below,
> 2009/2/5 marcelo bagnulo braun <[email-masked] 
> <mailto:[email-masked]>>
>
>     Hui Deng escribió:
>
>         There are could be metrics information, or other routing
>         parameters which is needed, but not covered in the rfc 4191.
>         For the passive model, I guess policy should be conformed
>         somewhere in the network side.
>
>     Currently you have two options available to convey route
>     information from the router to the host:
>     - RFC4191
>     - IGPs
>

these are the currently used techniques afaict, today we don't use dhcp 
for that, right?
>     My question is why. What are the features that you need that are
>     not provided by the two existent options
>
> In mobile communication, policy is not always stay together with router,
i am not sure i understand this
I mean, whichever box is running the policy can send the RADV with the 
policy information, or the IGP msgs, it doesn't have to be a router.

> or operator's policy server. some mobile OSs do implement another way 
> to do it.
>  
so, would this be a mobile specific issue?

regards, marcelo

>
>     I think it is important to understand this in order to figure out
>     if this item is needed or not
>
>          
>         isn't that a solution related? do we need specify clear
>         solution space in the current charter?
>          
>
>
>     No, but this if this is what you have in mind, i would suggest to
>     include it in the charter, so people understnad what you mean.
>     I mean, i would have thought that you would use some routing
>     protocol rather than dhcp
>     regards, marcelo
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 18:39:03 +0100

Hui Deng escribió:
> There are could be metrics information, or other routing parameters 
> which is needed, but not covered in the rfc 4191. For the passive 
> model, I guess policy should be conformed somewhere in the network side.

Currently you have two options available to convey route information 
from the router to the host:
- RFC4191
- IGPs

I think it is important to understand this in order to figure out if 
this item is needed or not

> isn't that a solution related? do we need specify clear solution space 
> in the current charter?
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 00:40:34 +0800

2009/2/6 marcelo bagnulo braun <[email-masked]>

> Hui Deng escribió:
>
>> Hi, Marcelo,
>>  inline below,
>> 2009/2/5 marcelo bagnulo braun <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>>    Hui Deng escribió:
>>
> these are the currently used techniques afaict, today we don't use dhcp for
> that, right?

current specification hasn't been fully fledged , again use this word:)

> policy information, or the IGP msgs, it doesn't have to be a router.

can that message could be transmited over multi-hops?

>
>
> or operator's policy server. some mobile OSs do implement another way to do
>> it.
>>
>>

No, this is what we said before, when mobile come to the internet, the model
has some change.:), go to bed now.

thanks

-Hui

>>                         So are you proposing to provide routing
>> information through
>>        DHCP?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Feb 2009 17:48:01 +0100

Hui Deng escribió:
>
>
> 2009/2/6 marcelo bagnulo braun <[email-masked] 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>
>            Hui Deng escribió:
>
>     these are the currently used techniques afaict, today we don't use
>     dhcp for that, right? 
>
current specs are the ones that are fully defined.

>     I mean, whichever box is running the policy can send the RADV with
>     the policy information, or the IGP msgs, it doesn't have to be a
>     router. 
>
ok, so the main requirements that is not satisfied by the current 
solutions is that it must be multihop?
If so, it should explicitly mentioned
Now, for a multihop case, the server cannot be a next hop, of coruse
So, the server needs to be aware of the multiple next hops that are 
available to the host. This means that the server needs to be aware of 
the topology and the position of the host in the topology

>  
>
>
>
>         or operator's policy server. some mobile OSs do implement
>         another way to do it.
>          
>
> No, this is what we said before, when mobile come to the internet, the 
> model has some change.:), go to bed now.
so, i am lost (again)....

are you proposing to bring to the internet the techniques current mobile 
OSes do in the mobile world?

regards, marcelo

>                                 So are you proposing to provide
>         routing information through
>                DHCP?

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 23:20:01 +0800

inline please

> Hui Deng escribió:
>
>>
>>
>> 2009/2/6 marcelo bagnulo braun <[email-masked] <mailto:
>> [email-masked]>>
>>
>>    Hui Deng escribió:
>>
>>        Hi, Marcelo,
>>         inline below,

both RFC 3442 and RFC 2132 are not fully specified in this direction.

> ok, so the main requirements that is not satisfied by the current solutions
> is that it must be multihop?
> available to the host. This means that the server needs to be aware of the
> topology and the position of the host in the topology

Previous reply already state the current solution cann't meet some scenario.
For multihop, at the moment, we are not going to touch it, so will not state
it at the current charter. But anyhow, some policy come from multiple policy
far, and network topology is well structured, they can do some level design.

> so, i am lost (again)....

Historically, PC's application depends on socket, but when mobile has
multiple interface,
something will change, application, multiple interface and socket will have
a different way to do it.

> OSes do in the mobile world?

Mobile is a normal host when it go to the Internet. it's OS also handle
Internet protocol.

Thanks for the discussion.

-Hui

---

From: Qin Wu <[email-masked]>
Date: Mon, 09 Feb 2009 15:00:22 +0800

Hi,hui:
few comments on the charter scope.
Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF?
Shall we consider the case in which one node with multiple interfaces connects to one access network?
If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF?

-Qin
  ----- Original Message ----- 
  From: Hui Deng 
  To: mif 
  Sent: Tuesday, February 03, 2009 5:22 PM
  Subject: [mif] Charter proposal

  Hi, all

  Proposed Work:
  -------------

   Split DNS:

  -Hui

------------------------------------------------------------------------------

---

From: Jacni Qin <[email-masked]>
Date: Mon, 9 Feb 2009 21:35:48 +0800

hi Wu,

> connects to one access network?

what's the difference between "multiple access network" and "one access
network" that you concern? Could you please state it more clearly?

> If one node owns only one interface, but can be allocated with more than
> one address(e.g., multple IPv6 address), whether this node can be viewed as
> a multi-homed host? How to understand this multi-homed host in MIF?
>

I don't believe that.:-)

regards,

Jacni

> *Sent:* Tuesday, February 03, 2009 5:22 PM

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Feb 2009 09:48:24 +0800

Hi, Jacni:
Thank for your concern. Please see the replies below.
-Qin
  ----- Original Message ----- 
  From: Jacni Qin 
  To: Qin Wu 
  Cc: Hui Deng ; mif 
  Sent: Monday, February 09, 2009 9:35 PM
  Subject: Re: [mif] Charter proposal

  hi Wu,

    Hi,hui:

  what's the difference between "multiple access network" and "one access network" that you concern? Could you please state it more clearly?
  [Qin]: One access network can be further divided into multiple subnets. Each subnet in the same access network supports the same access technology.When the node with two interfaces attaches to two access links in one access network, it means the node with two interfaces connects to two subnets in the same access network and each subnet serves one interface.Is it a real scenario MIF needs to consider?
  Regarding the multiple access networks, What I understand is the node with two interfaces connects two different type of access network, each access network support one type of access technology.
  In a word, multiple access network can be divided into multiple hetergeneous access networks and multiple homogeneous access networks, also multiple homogeneous access networks can be viewed as one access network, is it true?

  I don't believe that.:-)
  [Qin] Thank for your point. could you elaborate it in details?:) Actually I have difficulty to understand the exact meaning of multi-homed?

  regards,

  Jacni

    -Qin
      ----- Original Message ----- 
      From: Hui Deng 
      To: mif 
      Sent: Tuesday, February 03, 2009 5:22 PM
      Subject: [mif] Charter proposal

      Hi, all

      Proposed Work:
      -------------

       Split DNS:

      -Hui

--------------------------------------------------------------------------

---

From: Hui Deng <[email-masked]>
Date: Wed, 11 Feb 2009 22:42:18 +0800

Hi, Qin,

We don't have such strict policy on multiple access network,
mobile with multiple same modem card is allowed.

we will clarify the term in our new charter proposal, basically, one
interface with multiple IPv6 address already has been supported, will be in
the out of scope.

Thanks again.

-Hui
2009/2/9 Qin Wu <[email-masked]>