Subject: [netext] revised charter for the working group

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Jan 2010 01:32:44 +0100

All,

I would like to propose some text for the working group's new charter, 
based on discussions in IETF-76 about the outcome of the cross-interface 
handover and flow mobility work. Please see the attachments for the new 
charter text and diff to the current one. Comments appreciated, as always.

We are also moving one work item from the NETLMM working group here, as 
the former group is winding down.

Jari

Network-Based Mobility Extensions (netext)

Last Modified: 2010-01-05

Additional information is available at tools.ietf.org/wg/netext

Chair(s):

    * Rajeev Koodli <[email-masked]>
    * Basavaraj Patil <[email-masked]>

Internet Area Director(s):

    * Ralph Droms <[email-masked]>
    * Jari Arkko <[email-masked]>

Internet Area Advisor:

    * Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/netext
Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html

Description of Working Group:

Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility
protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility
Anchor (LMA) to allow hosts to move around within a domain while keeping
their address or address prefix stable. Proxy Mobile IPv6 has been
incorporated into a number of products and deployments are starting.
Certain deployment considerations, including localized routing and bulk
refresh of lifetime are already emerging.

The working group will focus on the following topics relevant for
network-based mobility:

Localized Routing: a specification for routing traffic between the
MAG(s) without involving the LMA. That is, allow the MAGs to route
traffic between hosts from one MAG to another, without being tunneled
all the way to the LMA. This reduces latency and backhaul load.
Applications such as voice can benefit from the reduced latency.

Bulk Refresh: a specification of improving the signaling load for
binding lifetime refresh. The current specifications call for the
handling of each mobility session independent of each other. When a
large number of hosts are served by a single MAG, a periodic refresh of
the binding lifetimes can lead to a signaling storm. The purpose of the
Bulk Refresh feature is to construct a protocol feature that allows such
refreshes to occur on a per-MAG basis.

LMA Redirection: a specification for allowing an LMA to redirect a MAG
to another LMA. This is primarily needed as a way to perform load
balancing. This functionality is complementary to implementation
techniques that allow distributed MAG implementations to move tasks
around without a visible impact at the protocol level, and the
initial LMA discovery work in the NETLMM WG. An applicability statement
describing the situations where the new functionality is or is not
applicable has to be included in the specification.

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable.  However, link layer implementations can hide mobility
events from the IP stack. For instance, several different radio
technologies are commonly represented as a single virtual interface to
the IP layer. The working group will write an informational document
that explains these designs and provides guidelines on when they are
or are not appropriate. The specification of specific extensions for
any actual link layer is outside the scope of the working group.

Proxy mobility support for virtual interfaces: The working group will
also specify protocol mechanisms between the Proxy Mobile IPv6 network
nodes (MAGs and LMAs) that support virtual interfaces and the ability
to distribute specific traffic flows on different components of the
virtual interface. These mechanisms assume that there exists virtual
interface support on the used link layer.

Radius Extensions to PMIP6: In order to enable network based
mobility using PMIP6, the policy profile needs to signal a set of
attributes and policies to the MAG and LMA. New Radius attributes
need to be specified that are relevant to PMIP6 based
mobility. This work item will specify Radius extensions and
attributes specific to PMIP6.

The work in this charter is entirely internal to the network and does
not affect host IP stack operation in any way (except perhaps through
impacting packet forwarding capacity visible to the hosts). The working
group is not allowed to specify new IP layer protocol mechanisms to signal
mobility related events between the host and the network.

The proposed activity will be complementary to the existing IETF Working
Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will
also act as the primary forum where new extensions on top of the Proxy
Mobile IPv6 protocol can be developed. The addition of such new
extensions to the working group involves addition of the extension to
this charter through the normal rechartering process.

Goals and Milestones:

May 2009	  	WG chartered
Jul 2009	  	Initial WG draft on Bulk Refresh
Jul 2009	  	Decision on the inclusion of possible additional work items
Sep 2009	  	Initial WG draft on LMA Redirection
Nov 2009	  	Initial WG draft on Route Optimization
Dec 2009	  	Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC
Jan 2010	  	Submit LMA Redirection to IESG for publication as a Proposed Standard RFC
Mar 2010		Initial WG document on Inter-access handovers
Mar 2010		Initial WG document on RADIUS extensions to PMIP6
Apr 2010	  	Submit Route Optimization to IESG for publication as a Proposed Standard RFC
May 2010		Initial WG document on Virtual Interface Guidelines
Apr 2010		Initial WG document on Virtual Interface Proxy Mobile IPv6 Support
Oct 2010		Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard
Dec 2010		Submit Virtual Interface Guidelines for publication as Informational
Feb 2011		Submit Virtual Interface Proxy Mobile IPv6 Support for publication as Proposed Standard

recharter_old.txt

recharter_new_jari.txt

Network-Based Mobility Extensions (netext)

Network-Based Mobility Extensions (netext)

Last Modified: 2009-06-18

Last Modified: 2010-01-05

Additional information is available at tools.ietf.org/wg/netext

Additional information is available at tools.ietf.org/wg/netext

Chair(s):

Chair(s):

* Rajeev Koodli <[email-masked]>

* Rajeev Koodli <[email-masked]>

* Basavaraj Patil <[email-masked]>

* Basavaraj Patil <[email-masked]>

Internet Area Director(s):

Internet Area Director(s):

skipping to change at line 62

skipping to change at line 62

LMA Redirection: a specification for allowing an LMA to redirect a MAG

LMA Redirection: a specification for allowing an LMA to redirect a MAG

to another LMA. This is primarily needed as a way to perform load

to another LMA. This is primarily needed as a way to perform load

balancing. This functionality is complementary to implementation

balancing. This functionality is complementary to implementation

techniques that allow distributed MAG implementations to move tasks

techniques that allow distributed MAG implementations to move tasks

around without a visible impact at the protocol level, and the

around without a visible impact at the protocol level, and the

initial LMA discovery work in the NETLMM WG. An applicability statement

initial LMA discovery work in the NETLMM WG. An applicability statement

describing the situations where the new functionality is or is not

describing the situations where the new functionality is or is not

applicable has to be included in the specification.

applicable has to be included in the specification.

Hiding access technology changes from host IP layer: Proxy mobility is

based on the assumption that changes in host IP stacks are

undesirable. However, link layer implementations can hide mobility

events from the IP stack. For instance, several different radio

technologies are commonly represented as a single virtual interface to

the IP layer. The working group will write an informational document

that explains these designs and provides guidelines on when they are

or are not appropriate. The specification of specific extensions for

any actual link layer is outside the scope of the working group.

Proxy mobility support for virtual interfaces: The working group will

also specify protocol mechanisms between the Proxy Mobile IPv6 network

nodes (MAGs and LMAs) that support virtual interfaces and the ability

to distribute specific traffic flows on different components of the

virtual interface. These mechanisms assume that there exists virtual

interface support on the used link layer.

Radius Extensions to PMIP6: In order to enable network based

mobility using PMIP6, the policy profile needs to signal a set of

attributes and policies to the MAG and LMA. New Radius attributes

need to be specified that are relevant to PMIP6 based

mobility. This work item will specify Radius extensions and

attributes specific to PMIP6.

The work in this charter is entirely internal to the network and does

The work in this charter is entirely internal to the network and does

not affect hosts in any way (except perhaps through impacting packet

not affect host IP stack operation in any way (except perhaps through

forwarding capacity visible to the hosts).

impacting packet forwarding capacity visible to the hosts). The working

group is not allowed to specify new IP layer protocol mechanisms to signal

mobility related events between the host and the network.

The proposed activity will be complementary to the existing IETF Working

The proposed activity will be complementary to the existing IETF Working

Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will

Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will

also act as the primary forum where new extensions on top of the Proxy

also act as the primary forum where new extensions on top of the Proxy

Mobile IPv6 protocol can be developed. The addition of such new

Mobile IPv6 protocol can be developed. The addition of such new

extensions to the working group involves addition of the extension to

extensions to the working group involves addition of the extension to

this charter through the normal rechartering process.

this charter through the normal rechartering process.

This initial charter excludes a number of possible work items that were

discussed in the March 2009 BOF. The working group should continue the

discussion about a possible update of its charter and principles under

which the new work items must operate under. The completion of the work

items in the initial charter is not a requirement for the rechartering

to become possible.

Goals and Milestones:

Goals and Milestones:

May 2009 WG chartered

May 2009 WG chartered

Jul 2009 Initial WG draft on Bulk Refresh

Jul 2009 Initial WG draft on Bulk Refresh

Jul 2009 Decision on the inclusion of possible additional work items

Jul 2009 Decision on the inclusion of possible additional work items

Sep 2009 Initial WG draft on LMA Redirection

Sep 2009 Initial WG draft on LMA Redirection

Nov 2009 Initial WG draft on Route Optimization

Nov 2009 Initial WG draft on Route Optimization

Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC

Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC

Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC

Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC

Mar 2010 Initial WG document on Inter-access handovers

Mar 2010 Initial WG document on RADIUS extensions to PMIP6

Apr 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC

Apr 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC

May 2010 Initial WG document on Virtual Interface Guidelines

Apr 2010 Initial WG document on Virtual Interface Proxy Mobile IPv6 Support

Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard

Dec 2010 Submit Virtual Interface Guidelines for publication as Informational

Feb 2011 Submit Virtual Interface Proxy Mobile IPv6 Support for publication as Proposed Standard

End of changes. 6 change blocks.

10 lines changed or deleted

31 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 5 Jan 2010 09:36:33 -0800 (PST)

Hi Jari,
  Would it be possible to also move Netlmm Charter Item 6 into NetExt?
With the currently adopted solution, LMA discovery is far from being resolved. Some scenarios that are important remain uncovered. Solutions parallel to MIPv6 solutions have somehow gone unrecognized. I think this is against basic design principles of PMIPv6.
  In fact LMA discovery is not rocket science. If this item is moved to NetExt, a working group draft can be obtained very quickly.

Regards,

Behcet 

----- Original Message ----
> From: Jari Arkko <[email-masked]>
> To: [email-masked]
> Sent: Mon, January 4, 2010 6:32:44 PM
> Subject: [netext] revised charter for the working group
> 
> All,
> 
> I would like to propose some text for the working group's new charter, based on 
> discussions in IETF-76 about the outcome of the cross-interface handover and 
> flow mobility work. Please see the attachments for the new charter text and diff 
> to the current one. Comments appreciated, as always.
> 
> We are also moving one work item from the NETLMM working group here, as the 
> former group is winding down.
> 
> Jari

---

From: jouni <[email-masked]>
Date: Tue, 5 Jan 2010 21:31:44 +0200

Behcet,

> With the currently adopted solution, LMA discovery is far from being resolved. Some scenarios that are important remain uncovered. Solutions parallel to MIPv6 solutions have somehow gone unrecogniz…

Are you again referring with all this to your DHCP-based solution for LMA discovery?

JOuni

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

---

From: Frank Xia <[email-masked]>
Date: Tue, 05 Jan 2010 15:14:56 -0600

Hi Jouni

At the first, it is not a bad idea to discuss DHCP-based solution.

Even with DNS solution, IMHO, it seems good
to consider to elaborate the draft with information
from http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt.

BR
Frank

----- Original Message ----- 
From: "jouni" <[email-masked]>
To: "Behcet Sarikaya" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 05, 2010 1:31 PM
Subject: Re: [netext] revised charter for the working group

>> With the currently adopted solution, LMA discovery is far from being 
>> resolved. Some scenarios that are important remain uncovered. Solutions 
>> parallel to MIPv6 solutions have somehow gone unrecognized. I think this 
>> is against basic design principles of PMIPv6.
>
>>   In fact LMA discovery is not rocket science. If this item is moved to 
>> NetExt, a working group draft can be obtained very quickly.
>>
>> Regards,
>>
>> Behcet
>>
>>
>>
>>> based on

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 07 Jan 2010 11:33:37 +0200

Hi,

It seems that Frank and Behcet have decided to bring this up here.

We have extensively discussed the DCHP-based discovery over the last months
in the netlmm list, and there has never been support for it. I understand
that the authors of the draft are keen on this. However, support from other
people have been lacking.

So, I don't support taking this up here.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 07 Jan 2010 13:49:09 +0100

Hi Jari,

maybe the new charter should mention the localized routing problem 
statement, which has
been adopted during the Stockholm meeting. First WG version was out end 
of Sept 09.
Version 2 will be submitted within the next 2 weeks.

One further comment: The charter still mixes terms "Localized Routing" 
and "Route Optimization".
Should we take the chance of the charter update and keep the text 
consistent to the agreed term
"Localized Routing"?

marco

Jari Arkko wrote:
> based on discussions in IETF-76 about the outcome of the 
> cross-interface handover and flow mobility work. Please see the 
> attachments for the new charter text and diff to the current one. 
> Comments appreciated, as always.
>
> We are also moving one work item from the NETLMM working group here, 
> as the former group is winding down.
>
> Jari
> ------------------------------------------------------------------------
>

---

From: Frank Xia <[email-masked]>
Date: Thu, 07 Jan 2010 09:59:36 -0600

Hi Jonne

In fact, I don't care too much about where to settle this down.

I only have a little bit sense of discouragement in
technical disussion in NETLMM on this topic.

BR
Frank

----- Original Message ----- 
From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "jouni" 
<[email-masked]>; "Behcet Sarikaya" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 07, 2010 3:33 AM
Subject: Re: [netext] revised charter for the working group

>> from 
>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt.
>>
>> BR
>> Frank
>>
>>
>>> Are you again referring with all this to your DHCP-based solution for 
>>> LMA
>>> discovery?
>>>
>>> JOuni
>>>
>>>
>>>>> discussions in IETF-76 about the outcome of the cross-interface 
>>>>> handover
>>>>> and
>>>>> flow mobility work. Please see the attachments for the new charter 
>>>>> text
>>>>> and diff
>>>>> as

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 07 Jan 2010 18:14:29 +0200

Hi Frank,

I don't care either. However, my understanding is that we have settled it
already - at least until now there has been no support for DHCP based LMA
discovery. 

This may change over time of course. However, I don't think it has changed
enough to take this as a charter item in netext.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Frank Xia <[email-masked]>
Date: Thu, 07 Jan 2010 10:27:35 -0600

Hi Jonne

I am not sure what's hat are you on
when you express your opinion,
individual or a NETLMM co-chair.

IMHO, this topic has two pending issues:
1) DHCP based solution is a potential
   one which is described in NETLMM charter.
   We should  not exclude it without enough
   technical  discussion

2)Current DNS solution is not sufficient
  without some important information which
  is described in
 http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt.

BR
Frank

----- Original Message ----- 
From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "jouni" 
<[email-masked]>; "Behcet Sarikaya" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 07, 2010 10:14 AM
Subject: Re: [netext] revised charter for the working group

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 07 Jan 2010 18:47:26 +0200

Hi Frank,

>    We should  not exclude it without enough

<netlmm chair hat on>
DHCP has been mentioned in the current netlmm charter. However, it is just
one option, there has not been any commitment to the work - just the
possibility if there would be consensus for the work.

There was a discussion some time ago, and there was no consensus to do DHCP
based LMA discovery. People at that point found that it was not a useful
solution. Hence, it has not been specified.

You brought it up again some weeks ago. However, nobody else has supported
it. Therefore we (the chairs) have not seen a need to change our opinions on
the consensus.
</chair hat off>

>  http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt.

<netlmm chair hat on>
There has been absolutely no consensus to add this to the WG draft that is
still under discussion (draft-ietf-netlmm-lma-discovery). If you want
something in, you have to get support. If you don't get support, you don't
get it in.

Just having an I-D and just the authors pushing for it is not quite enough.

</netlmm chair hat off>

<individual>
I believe that there has been no support for this work in netlmm. If there
is no significant change in support, I think it would be strange to take up
something in netext that has been already discarded in netlmm.

Of course, the support and the need for these or any other possible
solutions may change over time. Let's have this discussion when we are at
that stage, though.
</individual>

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Frank Xia <[email-masked]>
Date: Thu, 07 Jan 2010 11:28:39 -0600

Hi Jonne

See my reply...

BR
Frank

----- Original Message ----- 
From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "jouni" 
<[email-masked]>; "Behcet Sarikaya" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 07, 2010 10:47 AM
Subject: Re: [netext] revised charter for the working group

> it. Therefore we (the chairs) have not seen a need to change our opinions 
Frank=> How many people expresses their technical points?  It is very clear 
you
said something 
http://www.ietf.org/mail-archive/web/netlmm/current/msg06382.html
in which  I did not see technical points.
I dont know where your consensus opinion came from.
AFAIK, these people supported the DHC: Behcet, Frank, Sri, Jong-Hyouk Lee.
The following people were against this: you, Vijay.

> something in, you have to get support. If you don't get support, you don't
Frank=>Don't mix concepts  between slience and  "no consensus".
AFAIK Julien also had similar idea, please check
http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html.

> Just having an I-D and just the authors pushing for it is not quite 
Frank=>Every one knows this topic is not brain surgury.  IMHO, people keep
silent just because of lacking interest.   It will be great if you encourage
people to express their technical points.

>>>>>>>>   In fact LMA discovery is not rocket science. If this item is 
>>>>>>>> moved
>>>>>>>> to

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Jan 2010 21:34:38 +0100

These seem like reasonable changes. Thanks.

Jari

Marco Liebsch kirjoitti:
> been adopted during the Stockholm meeting. First WG version was out 
> end of Sept 09.
>> I would like to propose some text for the working group's new 
>> charter, based on discussions in IETF-76 about the outcome of the

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 08 Jan 2010 09:55:03 +0200

Hi Frank,

On 1/7/10 7:28 PM, "ext Frank Xia" <[email-masked]> wrote:

[snip.]
> The following people were against this: you, Vijay.

The discussion died and nobody has supported you in this discussion for a
long time. If these people (outside you and Behcet) still support this idea,
I'm sure they're going to speak up. If there is enough support adding DHCP
option into the current spec is possible. However, you do need support.

Lack of discussion and expression of support == no support. That's how it
works.

>> </chair hat off>
[snip]

> http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html.

Silence is the same as no support. It is true that Julien described the
solution that you later put in a draft on the mailing list pretty early on.
However, I have not seen him - or anybody else except you - support the
standardization of the described method.

If there is support, the things can change. However, you need support first.

I hope this is now clear enough. If your ideas are useful and important I'm
sure you have no problem of getting support for them. Currently, there is
none.

Sorry for everybody on netext list. This later part of the discussion would
be more suited for the netlmm mailing list. However, as the discussion
started on the new charter topic, I thought it would be good for people to
understand the background.

Frank, if you want to continue to discuss the DHCP and DNS options, let's do
it at the netlmm list.

Cheers,

Jonne.

>>>>>>>>>> charter,

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Tue, 12 Jan 2010 15:58:46 +0100

Jari, all,

We (see folks in cc) would propose some modifications to the proposed charter.
The reason is that there is a fundamental difference between link layers solutions helping PMIPv6 procedures and the virtual interface concept. The former is generally indicating any layer 2 solution being IEEE or 3GPP. The latter describes a specific implementation on devices to get around the issue of configuring the same @IP on two different network interfaces.

The new text aims at smoothing the virtual interface presence in the charter and could as follow:

[...]
Link-layer support to hide access technology changes from host IP layer:
Proxy mobility is based on the assumption that changes in host IP stacks are undesirable.  However, link layer implementations can hide mobility events from the IP stack. The working group will write an informational document that explains current designs and provides guidelines on when they are or are not appropriate. The specification of specific extensions for any actual link layer is outside the scope of the working group.

Proxy mobility support for flow mobility and inter-technology handovers:
The working group will also specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support transferring the required information (i.e. triggers) to enable flow mobility across different interfaces and support inter-technology handovers. These mechanisms assume that there exists link-layer support helping mobility procedures.

[...]
Goals and Milestones:

[...]

May 2010 Initial WG document on Link-layer support to support access technology changes
Jun 2010 Initial WG document on Proxy Mobile IPv6 Support for flow mobility and inter-technology handover extensions

[...]
Dec 2010 Submit Link-layer support to support access technology changes for publication as Informational
Feb 2011 Submit Proxy Mobile IPv6 Support for flow mobility and inter-technology handover extensions for publication as Proposed Standard

Comments are welcome.

Telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jari Arkko
Envoyé : mardi 5 janvier 2010 01:33
À : [email-masked]
Objet : [netext] revised charter for the working group

All,

Jari

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Jan 2010 09:36:40 -0800 (PST)

Hi Jonne,

> standardization of the described method.

Wow! It is remarkable how you can remember things!
However, let me tell you that Christian also expressed similar ideas, so the memory can sometimes miss you.

Have you thought about why these people have done so?
It is because anybody who sees DNS mentioned in Jouni's draft remembers MIPv6 DNS solution. Why not take advantage of previous MIPv6 designs? The same goes with DHCP. It is not rocket science.

As I mentioned before, this feature is missing from Jouni's draft. And it is an essential feature of PMIPv6 design to maximize code usage with the HA of MIPv6, do you agree?

> If there is support, the things can change. However, you need support first.

I agree with Frank that it could also be intepreted as people are not against including DNS and DHCP support to the solution.

As you Netlmm chairs are reluctant, why not let Netext do this?

Ciao,

Behcet

---

From: <[email-masked]>
Date: Wed, 13 Jan 2010 10:20:54 +0100

Hi all,

I second Telemaco. The charter should leave the door open and not refer to a specific solution.

Regards,
Pierrick

> De : [email-masked] [mailto:[email-masked]] De la part
> de MELIA TELEMACO
> Envoyé : mardi 12 janvier 2010 15:59
> À : Jari Arkko; [email-masked]
> Cc : Antonio de la Oliva; Zuniga,Juan Carlos
> Objet : Re: [netext] revised charter for the working group
> 
> Jari, all,
> 
> The reason is that there is a fundamental difference between link layers
> solutions helping PMIPv6 procedures and the virtual interface concept. The
> former is generally indicating any layer 2 solution being IEEE or 3GPP.
> The latter describes a specific implementation on devices to get around
> the issue of configuring the same @IP on two different network interfaces.
> 
> Proxy mobility is based on the assumption that changes in host IP stacks
> are undesirable.  However, link layer implementations can hide mobility
> events from the IP stack. The working group will write an informational
> document that explains current designs and provides guidelines on when
> they are or are not appropriate. The specification of specific extensions
> for any actual link layer is outside the scope of the working group.
> 
> The working group will also specify protocol mechanisms between the Proxy
> Mobile IPv6 network nodes (MAGs and LMAs) that support transferring the
> required information (i.e. triggers) to enable flow mobility across
> different interfaces and support inter-technology handovers. These
> mechanisms assume that there exists link-layer support helping mobility
> procedures.
> 
> [...]
> Goals and Milestones:
> 
> [...]
> 
> Jun 2010 Initial WG document on Proxy Mobile IPv6 Support for flow
> mobility and inter-technology handover extensions
> 
> [...]
> Feb 2011 Submit Proxy Mobile IPv6 Support for flow mobility and inter-
> technology handover extensions for publication as Proposed Standard
> 
> Comments are welcome.
> 
> Telemaco
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 13 Jan 2010 13:45:23 -0800

Jari, all,

Jari Arkko wrote:
> based on discussions in IETF-76 about the outcome of the cross-
> interface handover and flow mobility work. Please see the attachments
> for the new charter text and diff to the current one. Comments
> appreciated, as always.

Below are my comments on parts of the new charter text being proposed.
 
      Hiding access technology changes from host IP layer: Proxy mobility is	
 	based on the assumption that changes in host IP stacks are	
 	undesirable.  However, link layer implementations can hide mobility	
 	events from the IP stack. [...]

The statement that "link layer implementation can hide mobility events from the IP stack" is rather vague with respect to the types of events we're concerned with. 

The link layer implementation's prerogative with respect to hiding events from the IP stack are limited to hiding _link layer_ events. It seems to me that the only link layer events an IP stack should be interested in are link_up and link_down events. If so we should be explicit about it.

                                       For instance, several different radio	
 	technologies are commonly represented as a single virtual interface to	
 	the IP layer.

I am not sure I agree that "several different radio technologies are commonly represented as a single virtual interface to	the IP layer".

The 'virtual' qualifier doesn't tell much; it would be more accurate to say that "a single interface might transmit packets over different media" (for the sake of brevity I'll be calling that a multi-media interface in the rest of this note.)
 
                    The working group will write an informational document	
 	that explains these designs and provides guidelines on when they are	
 	or are not appropriate. The specification of specific extensions for	
 	any actual link layer is outside the scope of the working group.	

If these designs are existing ones, either they're documented or they're not. If they're documented, I see little value in documenting them again, and I am also not sure that we have the expertise to do so. If they're not, I don't think it's our role to explain undocumented designs originating from outside the IETF, unless the IETF is the Internet Explanation Task Force. 

If these designs do not exist yet, I am concerned that we're chartering exploration of an unbounded area...

I think the WG should focus entirely on writing an informational applicability statement that analyzes the issues involved with the use of multi-media interfaces and characterizes the contexts in which their use is appropriate or not. 
 		
 	virtual interface. 

It is rather vague what are the central features of a "protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces". We should be defining precisely the features of the protocol mechanisms to be developed.

And again, the term virtual interface isn't IMHO specific enough. If we can agree that the issue we're concerned about is that of "a single interface might transmit packets over different media", it's not clear to me yet that protocol extensions are needed. 

So how about rewording as "The WG will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single MN interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary.

                          These mechanisms assume that there exists virtual	
 	interface support on the used link layer.

This is also vague -- what constitutes virtual interface support? Is this limited to the ability for a single interface to transmit packets over different media? If it is we should say so, e.g. "The WG will assume that there the MN has a multi-media interface". If it implies more, I'm concerned again that we are in unbounded area and I request that we list here explicitly the features assumed from such a support, e.g., "The WG will assume that the MN has a multi-media interface capable of X, Y and Z".

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 14 Jan 2010 11:23:19 +0900

Hi all,

Please see my comments inline!

Regards,
TrungTM

> The statement that "link layer implementation can hide mobility events from the IP stack" is rather vague with respect to the types of events we're concerned with.

I think we should better state that: "However, link layer
implementations can hide link changes from the IP stack"
The term link is as defined in RFC 2416.

> The 'virtual' qualifier doesn't tell much; it would be more accurate to say that "a single interface might transmit packets over different media" (for the sake of brevity I'll be calling that a mul…

Since the term "virtual interface" is a well known one, I do not think
that the term "multi-media interface" is better!

> I think the WG should focus entirely on writing an informational applicability statement that analyzes the issues involved with the use of multi-media interfaces and characterizes the contexts in w…

I do agree that we should better focus on analyzing the issues
involved with the use of virtual interface and characterizing the
contexts in which their use is appropriate or not.
Documenting the current existing design may overlap with current
practices document of MIF WG.

> It is rather vague what are the central features of a "protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces". We should be defining precis…

Defining precisely the features of the protocol mechanisms to be
developed is or work in coming internet draft.
I prefer to change this part as follows:

"Proxy mobility support for virtual interfaces: The working group will
also specify protocol mechanisms between the Proxy Mobile IPv6 network
nodes (MAGs and LMAs) that support virtual interfaces and the ability
to distribute specific traffic flows on different physical interfaces
that are abstracted by virtual interface.

-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 14 Jan 2010 08:36:48 -0800

Trung,

Cutting thru the parts where we agree, I have replied to your comments below -

Tran Minh Trung wrote:
> >      Hiding access technology changes from host IP layer: Proxy
> >      mobility is based on the assumption that changes in host IP stacks 
> >      are undesirable.  However, link layer implementations can hide
> >      mobility events from the IP stack. [...]
> >
> > The statement that "link layer implementation can hide mobility
> > events from the IP stack" is rather vague with respect to the types of
> > events we're concerned with.
> 

That would work with me.
 
> > I am not sure I agree that "several different radio technologies are
> > commonly represented as a single virtual interface to      the IP
> > layer".
> >
> > The 'virtual' qualifier doesn't tell much; it would be more accurate
> > to say that "a single interface might transmit packets over different
> > media" (for the sake of brevity I'll be calling that a multi-media
> > interface in the rest of this note.)
> 

I wasn't saying that "multi-media interface" is better than "virtual interface".

A term can be well known yet vague, and this is the case for "virtual interface". 

We should define precisely what we're talking about, and I think that something along "a single interface that can send/receive packets over different media" is a more accurate definition than "virtual interface". 
 
> >                    The working group will write an informational
> >  document that explains these designs and provides guidelines on when
> >  they are or are not appropriate. The specification of specific
> >  extensions for any actual link layer is outside the scope of the working
> >  group.
> >
> > If these designs are existing ones, either they're documented or
> > they're not. If they're documented, I see little value in documenting
> > them again, and I am also not sure that we have the expertise to do so.
> > If they're not, I don't think it's our role to explain undocumented
> > designs originating from outside the IETF, unless the IETF is the
> > Internet Explanation Task Force.
> >
> > If these designs do not exist yet, I am concerned that we're
> > chartering exploration of an unbounded area...
> >
> > I think the WG should focus entirely on writing an informational
> > applicability statement that analyzes the issues involved with the use
> > of multi-media interfaces and characterizes the contexts in which their
> > use is appropriate or not.
> 

Good.

> >        Proxy mobility support for virtual interfaces: The working
> >        group will also specify protocol mechanisms between the Proxy Mobile
> >        IPv6 network nodes (MAGs and LMAs) that support virtual interfaces 
> >        and the ability to distribute specific traffic flows on different 
> >        components of the virtual interface.
> >
> > It is rather vague what are the central features of a "protocol
> > mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs)
> > that support virtual interfaces". We should be defining precisely the
> > features of the protocol mechanisms to be developed.
> 

No. 

The charter is there to specify the objective of the working group. As I said, virtual interface is too vague, thus I don't know what constitutes a protocol mechanisms that support virtual interfaces, thus I don't know what this WG is chartered to do by reading the charter, so the charter isn't fine as is.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Jan 2010 14:11:34 -0800 (PST)

Hi Julien,
  Quoting from MIF WG PS draft 
http://tools.ietf.org/html/draft-ietf-mif-problem-statement-01

interfaces may be logical, virtual or physical. I don't understand your objection to virtual interface? 

I think that the charter item 
Hiding access technology changes from host IP layer

and 

Proxy mobility support for virtual interfaces:

will enable NetExt to develop efficient flow mobility solutions for PMIPv6.

So I support it.

Regards,

Behcet

----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: Tran Minh Trung <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thu, January 14, 2010 10:36:48 AM
> > On Thu, Jan 14, 2010 at 6:45 AM, Laganier, Julien
> > wrote:
> > > Jari, all,
> > >
> We should define precisely what we're talking about, and I think that something 
> along "a single interface that can send/receive packets over different media" is 
> a more accurate definition than "virtual interface". 
> 
> The charter is there to specify the objective of the working group. As I said, 
> virtual interface is too vague, thus I don't know what constitutes a protocol 
> mechanisms that support virtual interfaces, thus I don't know what this WG is 
> chartered to do by reading the charter, so the charter isn't fine as is.
> 
> --julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Jan 2010 14:43:10 -0800

> objection to virtual interface?

What is it exactly that you don't understand in what I wrote below?

> We should define precisely what we're talking about, and I think that 
> something along "a single interface that can send/receive packets over 
> different media" is a more accurate definition than "virtual interface".

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Jan 2010 15:56:49 -0800 (PST)

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; Tran Minh Trung <[email-masked]>
> Sent: Fri, January 15, 2010 4:43:10 PM
> Subject: RE: [netext] revised charter for the working group
> 
> Behcet Sarikaya wrote:
> > 
> > Hi Julien,

Do you want it to be called virtual network interface? That is probably better and I would have no objection. 

As such, virtual interface is a term well understood in OS circles, like setting up a virtual interface in Linux.

Regards,

Behcet

---

From: Tran Minh Trung <[email-masked]>
Date: Sat, 16 Jan 2010 10:12:22 +0900

Hi all,

Julien wants to have a more accurate definition. It is good. However I
think the following paragraph, quoting from  recharter_new_jari.txt,
is clear enough.

" For instance, several different radio technologies are commonly
represented as a single virtual interface to the IP layer."

About "Proxy mobility support for virtual interfaces", I prefer to
change this part as follows:

that are abstracted by virtual interface."

Regards,
TrungTM

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Jan 2010 19:30:40 -0800

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Friday, January 15, 2010 3:57 PM
> To: Laganier, Julien
> Cc: [email-masked]
> "Laganier, Julien" <[email-masked]>[Laganier, Julien]  wrote:
> >
> > Behcet Sarikaya wrote:
> > >
> > > Hi Julien,
> As such, virtual interface is a term well understood in OS circles,
> like setting up a virtual interface in Linux.

If it is well understood, you can give me a precise definition and if we can agree on it put that text in the charter. It is important to know what it is and what it does because it is on premise of its existence that we are supposed to see what sort of protocol extensions are needed to support it on one hand, and to do flow mobility on another hand.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Jan 2010 19:53:51 -0800

Tran Minh Trung wrote
> 
> Hi all,
> 
> Julien wants to have a more accurate definition. It is good. 

Good to see we agree here.

>                                                       [...] However I

As I said to Behcet and as you noted above, because we are possibly going to specify protocol mechanisms that will have to support virtual interfaces and will have to rely on them to provide flow mobility, to understand the extent of the work to be chartered it is important that we have a common understanding of the underlying assumptions, e.g., what features from the virtual interfaces are available to us and what we we are going to do to support it. 

(and since the working group will have to discuss that anyway, discussing it now ahead of time can save us time at a later stage when the work is advanced.)

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Jan 2010 09:11:37 -0800 (PST)

http://en.wikipedia.org/wiki/Virtual_Interface

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Sent: Fri, January 15, 2010 9:30:40 PM
> > "Laganier, Julien" [Laganier, Julien]  wrote:
> > >
> > > Behcet Sarikaya wrote:
> > > >
> > > > Hi Julien,
> If it is well understood, you can give me a precise definition and if we can 
> agree on it put that text in the charter. It is important to know what it is and 
> what it does because it is on premise of its existence that we are supposed to 
> see what sort of protocol extensions are needed to support it on one hand, and 
> to do flow mobility on another hand.
> 
> --julien

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 21:05:46 +0100

Following up on at least the following charter proposal:
"
"

There are some ambiguities in this writeup.
1. Is the virtual interface mentioned above refering to the existence of
such an interface on the host (MN)?
2. It appears that the virtual interface above refers to such capability on
the MAG and LMA entities. Is that the intent?

The WG has been considering specifying a document which explains how an MN
with a virtual interface could handle inter-technology handovers. With that
in mind, I would propose the following text:

Proxy mobility support for hosts using a virtual interface: The WG will
specify the use of a virtual interface on a multi-interfaced host w.r.t its
applicability in the context of inter-technology handovers and flow
mobility. PMIP6 assumes mobility support for unmodified hosts. A virtual
interface on an MN is not required, but the existence of such capability
could enable mobility of the host between different access technologies.

-Raj

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 21:50:00 +0100

W.r.t the following proposal:

"

I agree with Julien that the statement "link later implementations can hide
mobility events" as being vague. We can explicitly say that 3GPP has for
example a solution for mobility between different radio-access technologies
which are agnostic to the IP stack.

The intent of this work item in the charter is to document various
approaches taken to hide the physical interface from the IP stack or what is
being refered to here as a virtual interface. So we could simply rephrase it
as: "Hiding physical/logical interfaces from host IP layer" and not cover
the aspect of hiding the access technology changes occuring as a result of
mobility or other reasons.

-Raj 

On 1/13/10 3:45 PM, "ext Laganier, Julien" <[email-masked]> wrote:

> The statement that "link layer implementation can hide mobility events from
> the IP stack" is rather vague with respect to the types of events we're
> concerned with.
> 
> The link layer implementation's prerogative with respect to hiding events from
> the IP stack are limited to hiding _link layer_ events. It seems to me that
> the only link layer events an IP stack should be interested in are link_up and
> link_down events. If so we should be explicit about it.
> 
> I am not sure I agree that "several different radio technologies are commonly
> represented as a single virtual interface to      the IP layer".
> 
> The 'virtual' qualifier doesn't tell much; it would be more accurate to say
> that "a single interface might transmit packets over different media" (for the
> sake of brevity I'll be calling that a multi-media interface in the rest of
> this note.)
> 
> If these designs are existing ones, either they're documented or they're not.
> If they're documented, I see little value in documenting them again, and I am
> also not sure that we have the expertise to do so. If they're not, I don't
> think it's our role to explain undocumented designs originating from outside
> the IETF, unless the IETF is the Internet Explanation Task Force.
> 
> I think the WG should focus entirely on writing an informational applicability
> statement that analyzes the issues involved with the use of multi-media
> interfaces and characterizes the contexts in which their use is appropriate or
> not.
>                
> It is rather vague what are the central features of a "protocol mechanisms
> between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support
> virtual interfaces". We should be defining precisely the features of the
> protocol mechanisms to be developed.
> 
> And again, the term virtual interface isn't IMHO specific enough. If we can
> agree that the issue we're concerned about is that of "a single interface
> might transmit packets over different media", it's not clear to me yet that
> protocol extensions are needed.
> 
> So how about rewording as "The WG will determine if protocol extensions are
> required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to
> support the ability for a single MN interface to transmit packets over
> different media and the ability to distribute specific traffic flows on
> different media components of that single interface. The relevant protocol
> extensions will be developed as necessary.
> 
> This is also vague -- what constitutes virtual interface support? Is this
> limited to the ability for a single interface to transmit packets over
> different media? If it is we should say so, e.g. "The WG will assume that
> there the MN has a multi-media interface". If it implies more, I'm concerned
> again that we are in unbounded area and I request that we list here explicitly
> the features assumed from such a support, e.g., "The WG will assume that the
> MN has a multi-media interface capable of X, Y and Z".
> 
> --julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Jan 2010 13:16:43 -0800 (PST)

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]; [email-masked]
> Sent: Mon, January 18, 2010 2:05:46 PM

I agree with clarifying that virtual interface is at the hosts or MNs. Otherwise dealing with the virtual interfaces at the MAG or LMA doesn't make sense :).

However, I think that the following should be an integral part of the charter item:

The working group will specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) 

Regards,

Behcet

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 22:21:09 +0100

Hi Behcet,

On 1/18/10 3:16 PM, "ext Behcet Sarikaya" <[email-masked]> wrote:

----snip-----

> IPv6 network nodes (MAGs and LMAs)

Yes. The intent is that the WG will specify protocol extensions to the
signaling between the MAG and LMA and between MAGs to enable
inter-technology handovers and support flow mobility.

-Raj

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 18 Jan 2010 13:59:10 -0800

> http://en.wikipedia.org/wiki/Virtual_Interface

So what?

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 19 Jan 2010 09:53:43 +0900

> inter-technology handovers and support flow mobility.

I think it should also support multihoming.

TrungTM

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 03:04:57 +0100

No.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 11:10:14 +0200

Julien,

> The statement that "link layer implementation can hide mobility events from the IP stack" is rather vague with respect to the types of events we're concerned with. 

Hmm. I'm reading on...

> The link layer implementation's prerogative with respect to hiding events from the IP stack are limited to hiding _link layer_ events. It seems to me that the only link layer events an IP stack should be interested in are link_up and link_down events.
>   

Yes. But what is perhaps more interesting from the point of view of this 
WG is the things that the multi-media interface hides from IP.

> I think the WG should focus entirely on writing an informational applicability statement that analyzes the issues involved with the use of multi-media interfaces and characterizes the contexts in w…

I agree with this. That's a good formulation. Thanks.

> So how about rewording as "The WG will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single MN interface to…

This is good.

> This is also vague -- what constitutes virtual interface support? Is this limited to the ability for a single interface to transmit packets over different media? If it is we should say so, e.g. "Th…

I'm not sure I can right away list what the capabilities are. I think 
the basic requirement is that the interface looks like a regular IP 
interface. I.e., IP layer has to do nothing special to make it work. No 
new L3 signaling, for instance.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 11:15:38 +0200

Telemaco,

> The reason is that there is a fundamental difference between link layers solutions helping PMIPv6 procedures and the virtual interface concept. The former is generally indicating any layer 2 soluti…

As you can tell from the other discussion, there are a number of terms 
suggested for what we are trying to do. I like your formulation, but I'd 
like to point out that the names do not matter so much than being able 
to clearly define what the names stand for.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 11:26:15 +0200

Julien,

> I am not sure I agree that "several different radio technologies are commonly represented as a single virtual interface to	the IP layer".

Maybe you problem is with the term "virtual interface". We can use 
another term, or define this more precisely, but I use networks every 
day that switch between 802.11b/g/n. Similarly, I use networks that 
switch between 2G and 3G cellular access, all without none of this being 
visible on my IP layer. I call this common practice.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Jan 2010 02:44:27 -0800

>> again that we are in unbounded area and I request that we list here
>> explicitly the features assumed from such a support, e.g., "The WG will
>> assume that the MN has a multi-media interface capable of X, Y and Z".
>>   

I see these properties and the operating mode to be specified as part of
documenting this behavior. Not sure, if the charter should go into such
details. But, few comments at a high-level, and which can change as we
discuss. Our updated Virtual interface doc should have all the details. We
will post that.

- Virtual interface is a logical interface that appears to the host stack as
another interface through which it can send and receive packets. One or more
IPv4 or IPv6 addresses can be bound to this virtual interface and this
address binding to this virtual interface is visible to the IPv6 ND peers on
the link.

- Virtual interface has a relation to a set of physical interfaces on the
host. These physical interfaces in the context of virtual interface are
knows are sub-interfaces. These sub-interfaces provide transmit and receive
functions for sending and receiving packets over physical links. A virtual
interface can receive packets sent to any of its sub-interfaces.

- The send/receive vectors of a virtual interface are managed dynamically
and are tied to the sub-interfaces. The change of mapping between this
virtual interface and the sub-interfaces can change dynamically and this
change will not be visible to the applications.

- Applications when bound to the virtual interface, provide address
continuity and session continuity, across the mapping change between a
virtual interface and its sub interfaces.

- An IPv6 link as seen by the applications that the virtual interface is
being part of through specific sub interface(s), when changed to be as part
of through a different set of sub interface(s), will not trigger session
loss, address loss, as long as the IPv6 prefix is valid, and the host
continues to receives RA's from the IP routers to the virtual interface over
the sub-interface(s).

- The host has the path awareness of an IPv6 link, through a sub-interface
and is driven by the host routing table, which uses the sub-interfaces for
packet forwarding. Addresses from Prefix P1, P2 tied to the virtual
interface, may have two different link paths, Prefix P1 over E0, Prefix P2
over E1, and this mapping may be reversed, without applications being aware
of, and with the needed path changes on the network side.

I'm sure, we can discuss/argue about these points. Lets do that as part of
completing this work, let me first post the doc.

Regards
Sri

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 13:39:31 +0200

Marco,

> consistent to the agreed term

Ok. Thanks. I have taken these into account in a new version.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 13:52:02 +0200

> mobility or other reasons.

This works for me. I will have a complete modified charter text soon out 
for review.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 13:56:49 +0200

I have a new version of the charter proposal. This tries to take the 
input from Julien, Telemaco, etc. into account. I've also had extensive 
discussions with Basavaraj and Rajeev about this. Its not clear that we 
can satisfy everyone's wishes, however. I have not moved discovery items 
from NETLMM WG here.

Diffs are at 
http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html

----------

Mobility Extensions (netext)

Last Modified: 2010-01-19

Chair(s):

Internet Area Advisor:

Mailing Lists:

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable.  However, link layer implementations can hide the
actually used physical interfaces from the IP stack. For instance, a
single interface might transmit packets over different media, as is
common practice in certain radio networks. This can be used to achieve
inter-access handovers or flow mobility, i.e., the movement of
selected flows from one access technology to another. The
specification of any actual link layer mechanisms is outside the scope
of the working group, but the group works on the following:

- Informational applicability statement that analyzes the issues
  involved with this approach and characterizes the contexts in which
  such use is or is not appropriate.

- The working group will determine if protocol extensions are required
  between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to
  support the ability for a single host interface to transmit packets
  over different media and the ability to distribute specific traffic
  flows on different media components of that single interface. The
  relevant protocol extensions will be developed as necessary. The WG
  will assume that there the host has an interface that is capable of
  employing multiple media.

Goals and Milestones:

May 2009          WG chartered
Jul 2009          Initial WG draft on Bulk Refresh
Jul 2009          Decision on the inclusion of possible additional work 
items
Sep 2009          Initial WG draft on LMA Redirection
Sep 2009          Initial WG draft on Localized Routing
Dec 2009          Submit Bulk Refresh to IESG for publication as a 
Proposed Standard RFC
Jan 2010          Submit LMA Redirection to IESG for publication as a 
Proposed Standard RFC
Mar 2010        Initial WG document on RADIUS extensions to PMIP6
Apr 2010          Submit Localized Routing to IESG for publication as a 
Proposed Standard RFC
May 2010        Initial WG document on Applicability Statement on 
Multiple Media on One Interface
Jun 2010        WG decision on what Proxy Mobile IPv6 support is needed 
to support multiple media on one interface
Sep 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions 
to Support Multiple Media on One Interface
Oct 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Multiple Media on One 
Interface to IESG for publication as Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Multiple 
Media on One Interface for publication as Proposed Standard RFC(s)

---

From: Qin Wu <[email-masked]>
Date: Tue, 19 Jan 2010 20:28:24 +0800

It seems that "the localized routing problem statement" is forgotten to mention in the new charter.
Is it reasonable to have a milestone for this WG document as well?

Regards!
-Qin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 14:39:20 +0200

> Is it reasonable to have a milestone for this WG document as well?

Yes it is. I forgot to edit it in. Here's a new revision. Is this better?

Chair(s):

Internet Area Advisor:

Mailing Lists:

Localized Routing: a specification for routing traffic between the
MAG(s) without involving the LMA. That is, allow the MAGs to route
traffic between hosts from one MAG to another, without being tunneled
all the way to the LMA. This reduces latency and backhaul load.
Applications such as voice can benefit from the reduced latency.
The working group will produce a problem statement and a
specification of the localized routing mechanism.

Goals and Milestones:

May 2009          WG chartered
Jul 2009          Initial WG draft on Bulk Refresh
Jul 2009          Decision on the inclusion of possible additional work 
items
Sep 2009          Initial WG draft on LMA Redirection
Sep 2009          Initial WG draft on Localized Routing Problem Statement
Dec 2009          Submit Bulk Refresh to IESG for publication as a 
Proposed Standard RFC
Jan 2010          Submit LMA Redirection to IESG for publication as a 
Proposed Standard RFC
Mar 2010        Initial WG document on RADIUS extensions to PMIP6
Apr 2010          Submit Localized Routing Problem Statement to IESG for 
publication as an Informational RFC
Apr 2010        Initial WG draft on Localized Routing Solution
May 2010        Initial WG document on Applicability Statement on 
Multiple Media on One Interface
Jun 2010        WG decision on what Proxy Mobile IPv6 support is needed 
to support multiple media on one interface
Sep 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions 
to Support Multiple Media on One Interface
Oct 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Multiple Media on One 
Interface to IESG for publication as Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Multiple 
Media on One Interface for publication as Proposed Standard RFC(s)
Feb 2011          Submit Localized Routing Solution to IESG for 
publication as a Proposed Standard RFC

---

From: Qin Wu <[email-masked]>
Date: Tue, 19 Jan 2010 20:44:33 +0800

Yes, it looks good to me.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 08:05:45 -0800 (PST)

Hi Jari,

----- Original Message ----
> To: "[email-masked]" <[email-masked]>
> Sent: Tue, January 19, 2010 5:56:49 AM
> I have a new version of the charter proposal. This tries to take the input from 
> Julien, Telemaco, etc. into account. I've also had extensive discussions with 
> Basavaraj and Rajeev about this. Its not clear that we can satisfy everyone's 
> wishes, however. I have not moved discovery items from NETLMM WG here.

This is really unfortunate indeed.

I thought Netext chairs agreed :).

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 08:29:22 -0800 (PST)

Hi Jari,

> employing multiple media.

I suggest having virtual interface terminology back in the text possibly qualifying it with the hosts.

I don't understand why we have to deal with/worry about multiple media or multi-media? We have text about flows, why should we try to be more specific with what is in the flows? sn't it traffic selection or flow description issue and we have no charter item on it, right?

Regards,

Behcet

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Tue, 19 Jan 2010 17:56:42 +0100

Hi Jari,

Thanks for the updated text.

However, I still believe that the part of the charter referring to the "single host interface" needs to be changed.

IMHO the single host interface concept is too restrictive and we should be open to other possibilities. Part of the work should be to investigate what solutions are out there, ideally co-ordinating with the findings of the MIF wg (MIF does not address mobility, we should).

Having this in mind the new text could read as follow:

"The working group will determine if protocol extensions are required	
between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to	
support the ability for host with multiple interfaces to transmit packets over different media and the ability to distribute specific traffic	
flows on different media components of that single interface. The	
relevant protocol extensions will be developed as necessary."

Let us know your thoughts.

Thanks,
Telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jari Arkko
Envoyé : mardi 19 janvier 2010 12:57
À : [email-masked]
Objet : [netext] second revision of the new charter for the working group

Diffs are at 

----------

Chair(s):

Internet Area Advisor:

Mailing Lists:

Goals and Milestones:

May 2009          WG chartered

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 08:59:13 -0800

Jari,
> > commonly represented as a single virtual interface to	the IP layer".
> 
> Maybe you problem is with the term "virtual interface". 

Right. I think it's too vague.

> We can use another term, or define this more precisely, but I use networks every
> switch between 2G and 3G cellular access, all without none of this
> being visible on my IP layer. I call this common practice.

I too use network that switch between IEEE 802.11 a/b/g/n or various cellular radio technologies. But in this case the IP layer does see a network interface, and I have plugged in my computer a physical network interface card, so virtual is not a good qualifier IMHO.

The text in the new charter that you just sent out looks better.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 10:02:00 -0800

Hi Telemaco,

MELIA TELEMACO wrote:
> However, I still believe that the part of the charter referring to the
> "single host interface" needs to be changed.

I disagree.
 
> IMHO the single host interface concept is too restrictive and we should
> be open to other possibilities. Part of the work should be to
> investigate what solutions are out there, ideally co-ordinating with
> the findings of the MIF wg (MIF does not address mobility, we should).

>From its inception the NETLMM WG has assumed no host change, and so far NETEXT has abided.

Now we are discussing extending the charter to unmodified host _IP stack operation_, which would let the WG leverage on underlying layers that present a single interface to the IP layer while hiding link changes and attachment to multiple MAGs. 

This still fits with the original "no host change" motto insofar these underlying layers are not in our (the IETF) control and we do not specify them.

It's a quite a change, and my understanding is that we have no consensus to go beyond that.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 11:44:48 -0800

Jari,

Cutting thru the parts where we agree:

> > The link layer implementation's prerogative with respect to hiding
> > events from the IP stack are limited to hiding _link layer_ events. It
> > seems to me that the only link layer events an IP stack should be
> > interested in are link_up and link_down events.
> 
> Yes. But what is perhaps more interesting from the point of view of
> this WG is the things that the multi-media interface hides from IP.

Right. Ï kind of like the wording that somebody else suggested: "However, link layer implementations can hide link changes from the IP stack."
 
[...]

> > This is also vague -- what constitutes virtual interface support? Is
> > this limited to the ability for a single interface to transmit packets
> > over different media? If it is we should say so, e.g. "The WG will
> > assume that there the MN has a multi-media interface". If it implies
> > more, I'm concerned again that we are in unbounded area and I request
> > that we list here explicitly the features assumed from such a support,
> > e.g., "The WG will assume that the MN has a multi-media interface
> > capable of X, Y and Z".
> 

Putting forth the requirement that the interface looks like a regular IP interface is already a step in the good direction IMHO.

We can also derive straight away other requirements that stems from this one, e.g., a single interface can simultaneously attach to multiple MAGs via one or more radio technologies, it can transmit outbound packets on the MAG of its choice, and receive inbound packets via either of the MAGs. All the MAGs are assumed to be reachable at the same link-local IPv6 address or IPv4 address.

--julien

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:18:51 +0100

Behcet,

> I thought Netext chairs agreed :).

I don't believe it is a matter of whether the Netext chairs agreed to take
on some work. Its the WG as a whole that decides based on consensus. I
believe there are pleny of things on the Netext plate already with the
revised charter.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jan 2010 22:27:07 +0200

Julien,

> Cutting thru the parts where we agree:

...

> We can also derive straight away other requirements that stems from this one, e.g., a single interface can simultaneously attach to multiple MAGs via one or more radio technologies, it can transmit…
Is there something in the new proposed charter that needs to change 
based on this? If so, can you suggest specific changes?

Jari

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:35:12 +0100

Hi Julien,

On 1/19/10 1:44 PM, "ext Laganier, Julien" <[email-masked]> wrote:

> Putting forth the requirement that the interface looks like a regular IP
> interface is already a step in the good direction IMHO.
> 
> We can also derive straight away other requirements that stems from this one,
> e.g., a single interface can simultaneously attach to multiple MAGs via one or
> more radio technologies, it can transmit outbound packets on the MAG of its
> choice, and receive inbound packets via either of the MAGs. All the MAGs are
> assumed to be reachable at the same link-local IPv6 address or IPv4 address.

Did you imply a single physical interface simultaneously attaching to
multiple MAGs? RFC5213 allows the host to be attached via different
interfaces to different MAGs in a PMIP6 domain. W.r.t receiving inbound
packets on any of the MAGs are you assuming that the MN can be assigned the
same prefix on multiple interfaces?
Or are you assuming a virtual interface at the IP layer that is assigned a
prefix and the underlying physical interfaces are attached simultaneously to
different MAGs?

-Raj

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 19 Jan 2010 16:17:09 -0500

Hi Jari,
 
I am not clear about 
 
  relevant protocol extensions will be developed as necessary. "
 
What does this mean? I thought we agreed in the last meeting that there will be a network-based protocol for flow mobility and inter-tech handovers. The text above says we will have to determine again?
I hope not.. :-)
 
Thanks,
 
-Rajeev

________________________________

From: [email-masked] on behalf of Jari Arkko
Sent: Tue 1/19/2010 4:39 AM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [netext] second revision of the new charter for the workinggroup

Chair(s):

Internet Area Advisor:

Mailing Lists:

Goals and Milestones:

May 2009          WG chartered

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 13:48:22 -0800

Hi Rajeev,

Koodli, Rajeev wrote:
> What does this mean? I thought we agreed in the last meeting that there
> will be a network-based protocol for flow mobility and inter-tech
> handovers. The text above says we will have to determine again?
> I hope not.. :-)
 
Since I originated the "will determine" wording that triggered your message, I'm taking the freedom to explain the intent I had.

Saying that there will be a network-based protocol for flow mobility and inter-tech handovers is different from saying that protocol extensions are required for flow mobility and inter-tech handovers with a network-based protocol. 

I think the current text captures what we are up to.

If no extensions are required for flow mobility and inter-tech handovers with a network-based protocol, it means we already have a network-based protocol that can handle flow mobility and inter-tech handovers. If extensions are required, then they will be specified to ensure that we have a network-based protocol for flow mobility and inter-tech handovers.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 13:48:53 -0800 (PST)

Raj,

----- Original Message ----
> To: [email-masked]; [email-masked]; [email-masked]
> Sent: Tue, January 19, 2010 2:18:51 PM
> On 1/19/10 10:05 AM, "ext Behcet Sarikaya" wrote:
> 
> > Hi Jari,
> > 
> >  
> > 
> > 
> >> From: Jari Arkko 
> >> To: "[email-masked]" 
> on some work. 

Thank you!

> Its the WG as a whole that decides based on consensus. I

My objection is based on this same point. We are planning so many extensions on PMIPv6 then why are we ridding it of DHCP or DNS based LMA discovery, both of which are already part of MIPv6 protocol suite?
Such a mechanism could be used by all SDOs while some of the extensions proposed would not be.

I hope that there is a reason for that as there is a reason for everything :).

Regards,

Behcet

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 14:10:50 -0800

Jari,
 
> > Putting forth the requirement that the interface looks like a regular
> > IP interface is already a step in the good direction IMHO.
> >
> > We can also derive straight away other requirements that stems from
> > this one, e.g., a single interface can simultaneously attach to
> > multiple MAGs via one or more radio technologies, it can transmit
> > outbound packets on the MAG of its choice, and receive inbound packets
> > via either of the MAGs. All the MAGs are assumed to be reachable at the
> > same link-local IPv6 address or IPv4 address.
> 

I have incorporated the above in the relevant paragraph of the charter:

Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable.  However, some link layer implementations can hide link changes from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but when a single interface can simultaneously attach to multiple MAGs via one or more radio technologies, can transmit
outbound packets on the MAG of its choice, and receive inbound packets via either of the MAGs, the working group will work on the following:

--julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 19 Jan 2010 17:09:56 -0500

Hi Julien,
 
sorry, I don't understand the nuances here.. We have gone through this exercise more than once and now we need clear milestones. Saying that the WG will determine if a protocol is necessary is akin to saying we will open the same discussion all over. I don't wish to do that.
 
I would like to have a deliverable on network-based protocol for flow mobility and inter-tech handovers. If it turns out that everything can be done without having to define any new protocol, we would meet the deliverable date in record time! :-)
 
I am opposed to this "determine the need" milestone and deliverable. I would like to keep the WG deliverables simple and achievable.
 
Thanks,
 
-Rajeev

From: [email-masked] on behalf of Laganier, Julien
Sent: Tue 1/19/2010 1:48 PM
To: Koodli, Rajeev; Jari Arkko; Qin Wu
Cc: [email-masked]
Subject: Re: [netext] second revision of the new charter for the workinggroup

Hi Rajeev,

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 14:34:07 -0800 (PST)

Hi Rajeev,
  I think the charter item and the timing are both OK.

BTW, wish you success in your new affiliation :).

Regards,

Behcet 

----- Original Message ----
> From: "Koodli, Rajeev" <[email-masked]>
> To: "Laganier, Julien" <[email-masked]>; Jari Arkko <[email-masked]>; Qin Wu <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, January 19, 2010 4:09:56 PM
> sorry, I don't understand the nuances here.. We have gone through this exercise 
> more than once and now we need clear milestones. Saying that the WG will 
> determine if a protocol is necessary is akin to saying we will open the same 
> discussion all over. I don't wish to do that.
> 
> I would like to have a deliverable on network-based protocol for flow mobility 
> and inter-tech handovers. If it turns out that everything can be done without 
> having to define any new protocol, we would meet the deliverable date in record 
> time! :-)
> 
> I am opposed to this "determine the need" milestone and deliverable. I would 
> like to keep the WG deliverables simple and achievable.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> Since I originated the "will determine" wording that triggered your message, I'm 
> taking the freedom to explain the intent I had.
> 
> Saying that there will be a network-based protocol for flow mobility and 
> inter-tech handovers is different from saying that protocol extensions are 
> required for flow mobility and inter-tech handovers with a network-based 
> protocol.
> 
> If no extensions are required for flow mobility and inter-tech handovers with a 
> network-based protocol, it means we already have a network-based protocol that 
> can handle flow mobility and inter-tech handovers. If extensions are required, 
> then they will be specified to ensure that we have a network-based protocol for 
> flow mobility and inter-tech handovers.
> 
> --julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 19 Jan 2010 17:34:18 -0500

Behcet,
 
thank you for your wishes.
 
>From a WG management point of view, having these additional items is not worthwhile.
Haven't we spent enough time (multiple BoF cycles, ML, meeting time) on this already?
 
We should stick to the network-based protocol deliverables on flow mobility and inter-tech handovers.
 
-Rajeev

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Tue 1/19/2010 2:34 PM
To: Koodli, Rajeev
Cc: [email-masked]
Subject: Re: [netext] second revision of the new charter for the workinggroup

Hi Rajeev,

Regards,

Behcet

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 16:08:56 -0800

Hi Rajeev,

Koodli, Rajeev wrote:
> 
> sorry, I don't understand the nuances here.. We have gone through this
> exercise more than once and now we need clear milestones. Saying that
> the WG will determine if a protocol is necessary is akin to saying we
> will open the same discussion all over. I don't wish to do that.

I do not believe we've already discussed (and concluded) whether PMIPv6 required extensions to provide flow mobility when a single interface on the host can attach to multiple MAGs.

My recollection is, in the context of providing flow mobility in a network-based mobility environment, we did discuss 1) whether changes to the host were required, and 2) whether it made sense to require a new IP layer protocol between the host and the network. 

So this is a different discussion that we do need to have in any case.
 
> I would like to have a deliverable on network-based protocol for flow
> mobility and inter-tech handovers. 

And there is such a deliverable in the last charter Jari sent out.

> If it turns out that everything can be done without having to define
> any new protocol, we would meet the deliverable date in record time! :-)
> I am opposed to this "determine the need" milestone and deliverable. I
> would like to keep the WG deliverables simple and achievable.

The WG deliverables in the last charter Jari sent out should be simple and achievable to the extent that we can determine if the protocol is sufficient as is or requires extensions. 

Would we not be in a position to achieve that determination in a reasonable time, I do not see inclusion of a protocol extension in the deliverables and omission of the required determination step as a panacea...

--julien

> Since I originated the "will determine" wording that triggered your
> message, I'm taking the freedom to explain the intent I had.
> 
> Saying that there will be a network-based protocol for flow mobility
> and inter-tech handovers is different from saying that protocol
> extensions are required for flow mobility and inter-tech handovers with
> a network-based protocol.
> 
> If no extensions are required for flow mobility and inter-tech
> handovers with a network-based protocol, it means we already have a
> network-based protocol that can handle flow mobility and inter-tech
> handovers. If extensions are required, then they will be specified to
> ensure that we have a network-based protocol for flow mobility and
> inter-tech handovers.
> 
> --julien
> This email and any attachments may contain legally privileged and/or
> confidential information of Starent Networks, Corp. and is intended
> only for the individual or entity named in the message.  The
> information transmitted may not be used to create or change any
> contractual obligations of Starent Networks, Corp.  Any review,
> retransmission, dissemination or other use of, or taking of any action
> in reliance upon this e-mail and its attachments by persons or entities
> other than the intended recipient is prohibited. If you are not the
> intended recipient, please notify the sender immediately -- by replying
> to this message or by sending an email to
> [email-masked] -- and destroy all copies of this
> message and any attachments without reading or disclosing their
> contents. Thank you.

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 20 Jan 2010 09:20:28 +0800

Hello Jari,

Thanks for the second version of the charter scope.

I have couple of questions:

"The working group will determine if protocol extensions are required  
      between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to  
      support the ability for a single host interface to transmit
packets  
      over different media and the ability to distribute specific
traffic  
      flows on different media components of that single interface. The

      relevant protocol extensions will be developed as necessary. The
WG  
      will assume that there the host has an interface that is capable
of  
      employing multiple media."

[1]In the above, the term single interface you are referring to is the
virtual interface I guess?  I mean an implict description to virtual
interface.

[2] Also, the current charter text says that "the working group will
determine whether extensions needed for flow mobility ". 

Basically, my concern is that there should "not be any exploring"
whether flow mobility etc is needed and the charter should say we are
specifying protocol for flow mobility without any explcity signaling
from IP layer.

Your original(the 1st) charter text is fine.  Probably the term virtaul
interface can be changed to IP layer seeing a single interface that is
attached to different media components.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Jari Arkko
> Sent: Tuesday, January 19, 2010 7:57 PM
> To: [email-masked]
> Archive:
http://www.ietf.org/mail-archive/web/netext/current/maillist.html

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 19 Jan 2010 20:30:18 -0500

Hi,
 
> I do not believe we've already discussed (and concluded) 
> whether PMIPv6 required extensions to provide flow mobility 
> when a single interface on the host can attach to multiple MAGs.

Hmm.. NetExt is based on PMIPv6. So, we would be talking about PMIPv6
extensions for flow mobility.
Please take a look at the past meeting presentations on the discussions.

We cannot afford to introduce intermediate deliverables on
"investigation" after having spent over a year on these topics. 

> 
> My recollection is, in the context of providing flow mobility 
> in a network-based mobility environment, we did discuss 1) 
> whether changes to the host were required, and 2) whether it 
> made sense to require a new IP layer protocol between the 
> host and the network. 
> 

We did that too, and agreed to have no host changes at IP layer.
We agreed to have network layer protocol extensions (LMA - MAG,
MAG-MAG).

> So this is a different discussion that we do need to have in any case.

Disagree.

> And there is such a deliverable in the last charter Jari sent out.

I meant *a single* deliverable.

> > any new protocol, we would meet the deliverable date in 
> record time! 
> > :-) I am opposed to this "determine the need" milestone and 
> > deliverable. I would like to keep the WG deliverables 
> simple and achievable.
> 
> The WG deliverables in the last charter Jari sent out should 
> be simple and achievable to the extent that we can determine 
> if the protocol is sufficient as is or requires extensions. 

Again, we are not re-opening the issue of "if protocol extensions are
necessary".
We have discussed this sufficiently (over a year!), and the agreement is
to go with no host changes, and network-mobility extensions. What those
extensions are is to be specified in the deliverable.

> 
> Would we not be in a position to achieve that determination 
> in a reasonable time, I do not see inclusion of a protocol 
> extension in the deliverables and omission of the required 
> determination step as a panacea...

Well, if we go with this, every deliverable needs to be interposed with
an additional, intermediate "if necessary" deliverable. LMA redirection
- 1) if necessary Informational, followed by 2) PS document. Same for
Bulk Refresh and so on.

As you can see, this is not feasible. We propose charter text, go
through one or two BoFs, revise charter and agree on some items to work
on. We have done this for over a year now for flow mobility and
inter-tech handovers - remember Dublin bar BoF? It's time to get some
work done!

Thanks,

-Rajeev

> > extensions are required for flow mobility and inter-tech handovers 
> > with a network-based protocol.
> > 
> > in reliance upon this e-mail and its attachments by persons or 
> > entities other than the intended recipient is prohibited. 
> If you are 
> > not the intended recipient, please notify the sender 
> immediately -- by 
> > replying to this message or by sending an email to

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 20 Jan 2010 09:47:23 +0800

Hi Sri,

Thanks for such elaborate explanation on the characteristics of the
virtual interface.  Although we have been seeing the term virtual
interface, we needed more explanation on the functions of this
interface.  To achieve flow mobility and specify how inter RAT handoff
can be achieved for PMIP, such description is useful.  For flow mobiltiy
with such virtual interface we need to specify the network entity
interactions(MAG-LMA interaction).

I have two questions.

> continues to receives RA's from the IP routers to the virtual
interface
> over

Suppose IF1 (interface 1) sees prefix P1, P2 in RA, later IF1 sees P1 in
RA due to flow mobility and then interface 2 sees P2 in RA due to flow
mobility, can such RA sequences be supported by IPv6 stack that sees a
single virtual interface?
I think it should not cause nay confusion bcos prefixes tied to a
certain interface canbe sent in a combined way or sent in seperate ways
using RA.
This feature you have highlighted is very useful to perform flow
mobility between interfaces.  Just wanted to clarify this.

>From the above I understand the virtual interface can route P1 via a
certain interface and P2 via another interface.  Basically, it is
capable of mapping prefixes to the correct interface.
If so, such feature is also very useful in achieving flow mobility.

Waiting to see the vitual interface which can be very useful in the
protocol work for flow mobility.

BR,
Mohana
Behalf
> Of Sri Gundavelli
> Sent: Tuesday, January 19, 2010 6:44 PM
> To: Laganier, Julien
> Cc: [email-masked]
> this
> >> different media? If it is we should say so, e.g. "The WG will
assume
> that
> - Virtual interface is a logical interface that appears to the host
stack
> as
> another interface through which it can send and receive packets. One
or
> more
> address binding to this virtual interface is visible to the IPv6 ND
peers
> on
> continues to receives RA's from the IP routers to the virtual
interface
> over

---

From: liu dapeng <[email-masked]>
Date: Wed, 20 Jan 2010 09:50:45 +0800

2010/1/20, MELIA TELEMACO <[email-masked]>:
> IMHO the single host interface concept is too restrictive and we should be
> open to other possibilities. Part of the work should be to investigate what
> solutions are out there, ideally co-ordinating with the findings of the MIF
> wg (MIF does not address mobility, we should).

Agree.
Furthermore, the problem is not caused by PMIP it self, it is caused
by the multiple interfaces, and should netext focus on mobility and
leverage or co-operate with MIF which is focusing on solving the
issues caused by multiple interfaces?

BR,
Dapeng Liu

> support the ability for host with multiple interfaces to transmit packets

---

From: liu dapeng <[email-masked]>
Date: Wed, 20 Jan 2010 10:01:43 +0800

Hi Jari,

Thanks for the new charter,

2010/1/19, Jari Arkko <[email-masked]>:
> common practice in certain radio networks.

I am wondering whether the " link layer implementations " here is
refer to virtual interface? Should it be an IP layer mechanism instead
of Link layer? Otherwise why IETF should define link layer mechanism?
Besides, since it is related to enhance host to solve problems caused
by multiple interfaces, what is the relationship of this work and MIF?
Should there be any joint efforts with them?

BR,
Dapeng Liu

This can be used to achieve

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 20 Jan 2010 10:16:37 +0100

>> "single host interface" needs to be changed.
Julien, why should the charter be more restrictive than what RFC5213
assumes? The spec considers indication in the HI option of 'handover
between interfaces' or even 'Attachment over new interface' ?
Why should the charter mention single host interface now?
The charter should be more open and not narrow the playgroud
of the work too much. If the charter would explicitly talk about
virtual interface solution, this one may appear to IP layer as a
single interface. Below that, a host could have multiple physical
interfaces. And this is nothing new, so, RFC25213 takes
the right assumption.

marco

---

From: <[email-masked]>
Date: Wed, 20 Jan 2010 11:11:59 +0100

Hi Julien,

> de Laganier, Julien
> Envoyé : mardi 19 janvier 2010 19:02
> À : MELIA TELEMACO; Jari Arkko; [email-masked]
> Objet : Re: [netext] second revision of the new charter for theworking
> group
> 
> Hi Telemaco,
> 
> MELIA TELEMACO wrote:
> >
> > Hi Jari,
> >
> Now we are discussing extending the charter to unmodified host _IP stack
> operation_, which would let the WG leverage on underlying layers that
> present a single interface to the IP layer while hiding link changes and
> attachment to multiple MAGs.
> 
> This still fits with the original "no host change" motto insofar these
> underlying layers are not in our (the IETF) control and we do not specify
> them.
> 

Actually, the "single interface" approach may not be the only way. For instance, draft-bernardos-mif-pmip leverages on the weak host model (RFC 1122) to address IP flow mobility issue and leave the host unmodified. This is why we think the charter should not be so "solution oriented".

Pierrick

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Wed, 20 Jan 2010 13:10:04 +0100

Right, and to add credibility to the statement below we did implement the ideas described in http://tools.ietf.org/html/draft-bernardos-mif-pmip-01. The tests conducted so far are successful. The next version of the ID will describe the solution and limitations met so far.
The only things that we need on the MN are:
- routing tables update
- smarter source address selection functions (and this is probably also required for the virtual interface part)

But I assume this is part of the standard IP behavior...

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 20 janvier 2010 11:12
À : [email-masked]; MELIA TELEMACO; [email-masked]; [email-masked]
Objet : RE: [netext] second revision of the new charter for theworking group

Hi Julien,

Pierrick

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 20 Jan 2010 10:40:40 -0500

I agree with Marco. Why should there by a 'single interface' here?
 
Jari's original text was fine, but it needed to elaborate a 'virtual interface'. We are trying to solve *multi-access* problem here. If 'single host interface' is a replacement for 'virtual interface' in the original text, we need to use a different terminology here.
 
Regards,
 
-Rajeev

From: [email-masked] on behalf of Marco Liebsch
Sent: Wed 1/20/2010 1:16 AM
To: Laganier, Julien
Cc: [email-masked]; MELIA TELEMACO
Subject: Re: [netext] second revision of the new charter forthe working group

marco

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 21 Jan 2010 10:07:53 +0900

Hi Rajeev,

I tend to agree with you that we need to define/extend network-based protocol between MAG and LMA for flow mobility and inter-technology handovers because LMA at least needs to acquire relevant parameters from MAG to realize those functionalities.

I think above fact is NOT DEPENDENT on how the MN looks like whether it has logical virtual interface capability or not and also how the interface between MN and MAG is defined.

I would expect the current charter to be updated by reflecting this fact.

BR,
Junghoon

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Thu, 21 Jan 2010 14:11:56 +0800

Hi,

I think we do need a clear terminology about "interface" in different
contexts. 

It seems that there are two kind of interfaces discussed here. One is
the interface for the IP layer, which I think can be more than one for a
host as RFC5213 says. As a network based solution, PMIP should not
discuss the flow handover between the IP layer interfaces. 

The other kind are the interfaces in link layer, which may denote
different physical accesses but share a same IP interface. PMIP allow
the flow handover between the accesses under one IP interface. But, for
host, it's link layer solution which is out of the scope.

So, I suggest the definition of  the two kind of "interfaces" to avoid
the confusion.

Br

Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Koodli, Rajeev
Sent: Wednesday, January 20, 2010 11:41 PM
To: Marco Liebsch; Laganier, Julien
Cc: [email-masked]; MELIA TELEMACO
Subject: Re: [netext] second revision of the new charter forthe working
group

 
Jari's original text was fine, but it needed to elaborate a 'virtual
interface'. We are trying to solve *multi-access* problem here. If
'single host interface' is a replacement for 'virtual interface' in the
original text, we need to use a different terminology here.
 
Regards,
 
-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Jan 2010 19:45:38 -0800

Hi Mohana,

Please see inline.

> mobility between interfaces.  Just wanted to clarify this.

Yes. The reachable paths for the prefixes have changed from the host
perspective, but the v.if detects no change, its logically on the same IPv6
link with hosted prefixes P1/P2. The physical interfaces are used for
delivery purposes and advertised RA's will have not impact on them.

> If so, such feature is also very useful in achieving flow mobility.

Yes. 

> protocol work for flow mobility.

Sure.

Regards
Sri

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 22 Jan 2010 11:24:09 -0500

I also agree that the charter should not be restrictive to a specific
solution.

Having a single interface that transmits packets over different media is
one solution. However, there are single-radio implementations that
cannot transmit packets over different media and therefore cannot
simultaneously attach to multiple MAGs (via two or more radio
technologies).

With the current PMIP, if an MN (with single-radio implementation)
attaches to a new MAG with a different link technology this new MAG
cannot assume that the session is the continuation of a previous one. 

Solving this mobility issue should be in the scope of the Netext group.

Juan Carlos

> Behalf Of Koodli, Rajeev
> Sent: Wednesday, 20 January, 2010 10:41 AM
> > Now we are discussing extending the charter to unmodified host _IP
> stack operation_, which would let the WG leverage on underlying layers
> that present a single interface to the IP layer while hiding link
> changes and attachment to multiple MAGs.
> >
> > This still fits with the original "no host change" motto insofar
> these underlying layers are not in our (the IETF) control and we do
not
> specify them.

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 23:11:37 +0100

Hi Carlos,

I agree with your comment. Basically the intent is that we should enable
mobility across access technologies without having to resort to any IP layer
signaling between the MAG and MN.
Charter should not assume the capabilities of an MN in terms of whether it
is attached via one or more interfaces at any given time.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 Jan 2010 15:56:01 -0800 (PST)

----- Original Message ----
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Fri, January 22, 2010 4:11:37 PM

I am not sure.

What Juan Carlos is talking about is a single radio inter-technology handover. This is a bit confusing. I think that what he means is a single radio MN connecting to various 3GPP technologies. In fact this is not an inter-technology handover. So the solution is already there in 5213.

Regards,

Behcet

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Jan 2010 23:01:32 +0200

Rajeev, Julien,

> I am opposed to this "determine the need" milestone and deliverable. I would like to keep the WG deliverables simple and achievable.

I understand where you coming from, but first of all, its not 100% clear 
to me what extensions are necessary, so an extra step to determine them 
seems useful. Secondly, the milestone is not that bad if you read it 
carefully. It says "decision on what ... support is needed ..." which 
IMHO is exactly what we need to do. The purpose is not to make you go 
through a hoop or prevent you from doing this work. The work is agreed 
upon in the charter, all you have to do is to come up with a plan that 
describes what extensions you will do, and then do them!

Jul 2010        WG decision on what Proxy Mobile IPv6 support is needed 
to support multiple media on one interface
Oct 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions 
to Support Multiple Media on One Interface
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Multiple 
Media on One Interface for publication as Proposed Standard RFC(s)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Jan 2010 23:26:40 +0200

Xiao,

> So, I suggest the definition of  the two kind of "interfaces" to avoid

That's a good idea. Thanks.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Jan 2010 23:49:16 +0200

Pierrick,

> Actually, the "single interface" approach may not be the only way. For instance, draft-bernardos-mif-pmip leverages on the weak host model (RFC 1122) to address IP flow mobility issue and leave the…

Lets talk about this for a second.

It seems that there are a number of different host impacts.

1) We might need a new protocol between the host and the network. This 
implies new code on hosts and network and new protocol messages on the wire.

2) We might need just new code on the host, but still be able to 
determine all necessary information from existing exchanges.

3) We might need to assume that the host implements something which is 
allowed according to the RFCs but has not been implemented.

4) We might need to assume some code on the host that is often but not 
universally there on all current hosts.

5) We might need to assume some configuration on the host.

Obviously, on a network where someone is in full control we can assume 
anything, and build any amount of new protocols and code to optimize the 
behavior. Such networks are VERY rare, however. For instance, I'm 
writing this mail on my laptop which is connected over my cell phone to 
3G network, and the network can make no assumptions about what features 
my kernel has on my laptop. Or what my config is. Yet, a phone or a USB 
stick that implements 2G to 3G switching works just fine with this 
configuration.

My point is that we are not after no host impacts in some theoretical 
standardization sense. We actually want devices to work, old devices, 
current devices, new devices. Out of the box. And whether they work is 
affected by a number of things, including lack of code or config. I 
don't feel any happier about my hosed connection if the RFCs would have 
allowed it work. Or if the code is there but I didn't know I needed to 
turn it on. If it doesn't work, it doesn't work.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Jan 2010 23:53:40 +0200

Mohana,

> virtual interface I guess?  I mean an implict description to virtual

Yes. Though we do not want to imply anything about a particular 
implementation technique. Other than that the IP layer of the host is 
unaware of all of this...

> specifying protocol for flow mobility without any explcity signaling

There should not be any question about the need to support this 
functionality. Or even need to do work. But its a legitimate question 
how exactly what those extensions are.

I have changed the text to say "... determine what extensions ...", 
aligning it with what the milestones say.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Jan 2010 23:53:51 +0200

Dapeng,

Virtual interface is one way to do this. The important concept is that
the IP layer in the host is unaware of what's happening.

And you are right that these are link layer mechanisms, outside the
scope of the IETF. That's why the charter says that any actual link
layer mechanisms are outside the scope. However, it is important for us
to be able to describe the concept and interface from IP for this. And
to build the back-end protocols needed in PMIP to implement some of
this support.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2010 00:18:04 +0200

Julien,

> outbound packets on the MAG of its choice, and receive inbound packets via either of the MAGs, the working group will work on the following:
The last part is a bit too complex. How about this:

... following. It is assumed that that an interface (at the IP layer) 
can send and receive packets over multiple media and/or work with 
multiple MAGs.

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 25 Jan 2010 14:25:06 -0800

Jari,

> > Hiding access technology changes from host IP layer: Proxy mobility
> is based on the assumption that changes in host IP stacks are
> undesirable.  However, some link layer implementations can hide link
> changes from the IP stack. For instance, a single interface might
> transmit packets over different media, as is common practice in certain
> radio networks. This can be used to achieve inter-access handovers or
> flow mobility, i.e., the movement of selected flows from one access
> technology to another. The specification of any actual link layer
> mechanisms is outside the scope of the working group, but when a single
> interface can simultaneously attach to multiple MAGs via one or more
> radio technologies, can transmit
> > outbound packets on the MAG of its choice, and receive inbound
> packets via either of the MAGs, the working group will work on the
> following:
> >

Actually even simpler would be "... following. It is assumed that a single IP layer interface can simultaneously attach to multiple MAGs."

--julien

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2010 00:35:21 +0200

Melia,

> relevant protocol extensions will be developed as necessary."

This is tricky. We are walking a fine line between what our consensus or 
lack thereof indicates for the multihoming work, and still enabling the 
basic RFC 5213 mechanisms to work as expected.

 From my perspective the message from the BOF was loud and clear: we are 
not adding new mechanisms at IP layer for PMIP multihoming, flow 
mobility, or intertechnology handovers. There are also good practical 
reasons for this, as I explained in another mail.

If we start from that point of view then the charter needs to reflect 
that the functionality is really in L2, but it also needs to allow RFC 
5213 handover hints to work with the new functionality. Let me see if I 
can craft some text about this.

Jari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 26 Jan 2010 10:35:03 +0100

Hi Jari,

> stick that implements 2G to 3G switching works just fine with this 

Well, I partially agree with this. Your laptop works OK with that
configuration, but if in addition to the USB stick you add a wifi
connection, then your laptop may not work just fine without assuming
something else. Besides, if you want to benefit from sending http
traffic through one interface (e.g. wifi) and voip traffic through
another one (e.g. cellular), then you need something else (some
support/configuration at the laptop). If we want to enable flow mobility
in nodes with multiple interfaces in a PMIP domain, we may need to
assume that the mobile node is at least capable of doing some things
(where capable may imply certain configuration/standard support). A
single IP interface sending/receiving over multiple media (flow mobility
not just vertical handovers) will need to know "how" to dispatch flows,
something that is not implemented in host devices yet (at least widely,
as far as I know).

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 26 Jan 2010 04:23:30 -0800

Hi Jari,

If I may comment. 

>> turn it on. If it doesn't work, it doesn't work.

To most part implementing the virtual interface with bridging the physical
interfaces will allow multihoming, inter-tech handoffs and partial flow
handoff grouped at prefix level. Existing semantics and implementations
would work fine. No changes required on the host. However, for flow movement
for a single /128-bit scope, we need to preserve flow stickiness to physical
interfaces. This may require some minor tweaking, or activating some
behavior on the host.  We may have to bit lenient and not state that it
should work with a legacy IPv6 hosts, or stack written 5 years back, else we
have tough problem at hand with constraints not really serving any purpose.
With out that constraint, we do have a solution for network-based flow
mobility which has some business value.

Sri

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Tue, 26 Jan 2010 14:21:31 +0100

Hello,

Yep I agree and I guess this is the point Carlos wanted to make too.

Telemaco

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 26 Jan 2010 10:10:05 -0500

Behcet,

> Behalf Of Behcet Sarikaya
> Sent: Friday, 22 January, 2010 6:56 PM
> To: [email-masked]
> Cc: [email-masked]
> > To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> What Juan Carlos is talking about is a single radio inter-technology
> handover. This is a bit confusing. I think that what he means is a
> single radio MN connecting to various 3GPP technologies. In fact this
> is not an inter-technology handover. So the solution is already there
> in 5213.
> 

I meant "two different link technologies". If you assume one to be 3GPP then the other one would need to be a non-3GPP technology.