Subject: [Netext] You have received a card from a family member!
From: webmaster at hallmark.org (webmaster at hallmark.org)
Date: Fri, 29 May 2009 18:12:44 +0200 (CEST)

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090529/26266a0f/attachment.html>

From: webmaster at hallmark.org (webmaster at hallmark.org)
Date: Fri, 29 May 2009 17:30:54 +0200 (CEST)
Subject: [Netext] You have received a card from a family member!
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090529/fd4fd943/attachment.html>

From: support at paypal.com (PayPal Customer Support)
Date: 29 May 2009 11:22:50 -0400
Subject: [Netext] Update Your PayPal Account
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090529/f01fb4e6/attachment.html>

From: support at paypal.com (PayPal Customer Support)
Date: 29 May 2009 11:10:16 -0400
Subject: [Netext] Update Your PayPal Account
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090529/9c572bf3/attachment.html>

From: drahmedi.idowu74 at gmail.com (Dr.Ahmed Idowu)
Date: Thu, 28 May 2009 15:23:06 -0700
Subject: [Netext] Investment Partner.
Message-ID: <03e5e922-39961-31f26409570255@user-2d912a83ae>

Dear Friend,

I am making this contact to you in good faith. I got your email in  my search for a trust worthy and honest person that could assist me in a confidential transaction. I am Honorable Dr. Ahmed Idowu .I am one of the members who conducted the 2007 election with some of my party members, after the election I discovered that the sum of $60 Million Dollars Was remaining and we decided to move it outside the country for safe keeping in a Finance House.

I hereby write to seek for  your opinion for an investment in your country . I will appreciate if you can be able to handle this project perfectly with us, by making sure that the money will be received and safe keep in your custody for investment . Kindly respond back soonest with your  private telephone/ fax numbers for more details.

Plesea kindly get back to me through my private email: drahmed104 at gmail.com

Thanks and God bless.

Yours sincerely,

Hon. Dr.Ahmed Idowu

From: sunseawq at huawei.com (Qin Wu)
Date: Sat, 23 May 2009 16:08:53 +0800
Subject: [Netext] WG status
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Jari:
As regarding localized routing topic in the approved WG's charter,
I have a minor comment. In the description of localized routing topic, it mentioned that
"
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.
"
I wonder how to understand backhaul load reduction, 
>From my understanding, the backbone network should be located between the MAG and the LMA, the backhaul refers to links that carry traffic from 
the MAG to the backbone network or the LMA. In this sense, the backhaul load reduction will be understood as reduce traffic to pass through the MAG.
However the backhaul load reduction realy means the traffic does not need to pass through the LMA, am I right?
For this reason,May I suggest to reword the backhaul as backbone? If I am wrong, please correct me.

Regards!
-Qin
----- Original Message ----- 
From: "Jari Arkko" <jari.arkko at piuha.net>
To: <netext at mail.mobileip.jp>
Sent: Friday, April 24, 2009 4:32 AM
Subject: [Netext] WG status

> The IESG had a call today, and approved the WG's charter as it is below.
> 
> Jari
> 
>> Network-Based Mobility Extensions (netext)
>> -------------------------------------------------------------
>>
>> Last Modified: 2009-04-23
>>
>> Current Status: Proposed Working Group
>>
>> Chair(s):
>> TBD
>>
>> Internet Area Director(s):
>> Ralph Droms <rdroms at cisco.com>
>> Jari Arkko <jari.arkko at piuha.net>
>>
>> Internet Area Advisor:
>> TBD
>>
>> Mailing Lists:
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>> 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.
>>

From: sunseawq at huawei.com (Qin Wu)
Date: Thu, 21 May 2009 16:05:17 +0800
Subject: [Netext] Fw: I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt
Message-ID: <[email-masked]>

Hi folks:

May I interest you to read our draft on the problem statement of IPv4 Support for PMIPv6 localized routing?
This draft investigates all the practical IPv4 support use cases and problems in case of IPv4 support for PMIPv6 localized routing.
Hope it helps to progress the localized routing topic.
The URL link for this Internet draft is
http://tools.ietf.org/html/draft-wu-netext-pmipv6-ipv4-ro-ps-00
Your Comments are welcome.

BR
Qin
----- Original Message ----- 
From: <Internet-Drafts at ietf.org>
To: <i-d-announce at ietf.org>
Sent: Thursday, May 21, 2009 11:30 AM
Subject: I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Problem Statement of IPv4 Support for PMIPv6 Localized Routing
> Author(s)       : W. Wu, Y. Wang
> Filename        : draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt
> Pages           : 8
> Date            : 2009-05-20
> 
> [ID-PMIP6-RO-PS] describes the problem space of localized routing
> which allows end-to-end user traffic forwarding between MN and CN
> directly without involving Local Mobility Anchor (LMA) in a single
> Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with
> IPv4 support which allows IPv4 transport between MAG and LMA and/or
> IPv4 enabled user traffic between MN and CN is not considered. This
> document introduces the scenarios and problem statement for localized
> routing with IPv4 support.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090521/f600c614/attachment.txt>

From: hardie at qualcomm.com (Ted Hardie)
Date: Wed, 20 May 2009 13:49:02 -0700
Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p0624080ec63a1d0d7c21@[10.227.68.132]>

Thanks for the pointer.  I assume, then, that others got it and
commented on it as expected, and that I just had a very unlucky
sample.
			Ted

At 1:36 PM -0700 5/20/09, Basavaraj.Patil at nokia.com wrote:
>Sent to the IETF announce list on Apr 14th:
>
>http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05974.html
>
>
>-Basavaraj
>
>On 5/20/09 3:21 PM, "ext Ted Hardie" <hardie at qualcomm.com> wrote:
>
>> Is this the right message?  I can't find a copy of a message requesting public
>> comment on the charter in my archives, and the kind of offices of two others
>> searching their archives turned up the same lack.
>>
>> Was this meant to be the "IESG solicits feedback message"?  Or has
>> the process changed
>>                         regards,
>>                                 Ted
>>
>>
>> At 12:43 PM -0700 5/20/09, IESG Secretary wrote:
>>> A new IETF working group has been formed in the Internet Area.  For
>>> additional information, please contact the Area Directors or the WG
>>> Chairs.
>>>
>>> Network-Based Mobility Extensions (netext)
>>> -------------------------------------------------------------
>>>
>>> Last Modified: 2009-05-19
>>>
>>> Current Status: Active Working Group
>>>
>>> Chair(s):
>>> Basavaraj Patil <basavaraj.patil at nokia.com>
>>> Rajeev Koodli <rkoodli at starentnetworks.com>
>>>
>>> Internet Area Director(s):
>>> Ralph Droms <rdroms at cisco.com>
>>> Jari Arkko <jari.arkko at piuha.net>
>>>
>>> Internet Area Advisor:
>>> Jari Arkko <jari.arkko at piuha.net>
>>>
>>> Mailing Lists:
>>>
>>> General Discussion: netext at mail.mobileip.jp
>>> To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext
>>> Archive: http://www.mobileip.jp/pipermail/netext/
>>>
>>> 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.
>>>
>>> The work in this charter is entirely internal to the network and does
>>> not affect hosts in any way (except perhaps through impacting packet
> >> forwarding capacity visible to the hosts).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Milestones
>>>
>>> May 2009 WG chartered
>>> July 2009 Initial WG draft on Bulk Refresh
>>> July 2009 Decision on the inclusion of possible additional work items
>>> September 2009 Initial WG draft on LMA Redirection
>>> November 2009 Initial WG draft on Route Optimization
>>> December 2009 Submit Bulk Refresh to IESG for publication as a Proposed
>>> Standard RFC
>>> January 2010 Submit LMA Redirection to IESG for publication as a
>>> Proposed Standard RFC
>>> April 2010 Submit Route Optimization to IESG for publication as a
>>> Proposed Standard RFC
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce at ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Wed, 20 May 2009 22:36:34 +0200
Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext)
In-Reply-To: <p0624080cc63a1646e577@[10.227.68.132]>
Message-ID: <[email-masked]>

Sent to the IETF announce list on Apr 14th:

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05974.html

-Basavaraj

On 5/20/09 3:21 PM, "ext Ted Hardie" <hardie at qualcomm.com> wrote:

> Is this the right message?  I can't find a copy of a message requesting public
> comment on the charter in my archives, and the kind of offices of two others
> searching their archives turned up the same lack.
> 
> Was this meant to be the "IESG solicits feedback message"?  Or has
> the process changed
>                         regards,
>                                 Ted
> 
> 
> At 12:43 PM -0700 5/20/09, IESG Secretary wrote:
>> A new IETF working group has been formed in the Internet Area.  For
>> additional information, please contact the Area Directors or the WG
>> Chairs.
>> 
>> Network-Based Mobility Extensions (netext)
>> -------------------------------------------------------------
>> 
>> Last Modified: 2009-05-19
>> 
>> Current Status: Active Working Group
>> 
>> Chair(s):
>> Basavaraj Patil <basavaraj.patil at nokia.com>
>> Rajeev Koodli <rkoodli at starentnetworks.com>
>> 
>> Internet Area Director(s):
>> Ralph Droms <rdroms at cisco.com>
>> Jari Arkko <jari.arkko at piuha.net>
>> 
>> Internet Area Advisor:
>> Jari Arkko <jari.arkko at piuha.net>
>> 
>> Mailing Lists:
>> 
>> General Discussion: netext at mail.mobileip.jp
>> To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext
>> Archive: http://www.mobileip.jp/pipermail/netext/
>> 
>> 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.
>> 
>> The work in this charter is entirely internal to the network and does
>> not affect hosts in any way (except perhaps through impacting packet
>> forwarding capacity visible to the hosts).
>> 
>> 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.
>> 
>> 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.
>> 
>> Milestones
>> 
>> May 2009 WG chartered
>> July 2009 Initial WG draft on Bulk Refresh
>> July 2009 Decision on the inclusion of possible additional work items
>> September 2009 Initial WG draft on LMA Redirection
>> November 2009 Initial WG draft on Route Optimization
>> December 2009 Submit Bulk Refresh to IESG for publication as a Proposed
>> Standard RFC
>> January 2010 Submit LMA Redirection to IESG for publication as a
>> Proposed Standard RFC
>> April 2010 Submit Route Optimization to IESG for publication as a
>> Proposed Standard RFC
>> 
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce at ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

From: hardie at qualcomm.com (Ted Hardie)
Date: Wed, 20 May 2009 13:21:17 -0700
Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p0624080cc63a1646e577@[10.227.68.132]>

Is this the right message?  I can't find a copy of a message requesting public
comment on the charter in my archives, and the kind of offices of two others
searching their archives turned up the same lack. 

Was this meant to be the "IESG solicits feedback message"?  Or has
the process changed
			regards,
				Ted

At 12:43 PM -0700 5/20/09, IESG Secretary wrote:
>A new IETF working group has been formed in the Internet Area.  For
>additional information, please contact the Area Directors or the WG
>Chairs.
>
>Network-Based Mobility Extensions (netext)
>-------------------------------------------------------------
>
>Last Modified: 2009-05-19
>
>Current Status: Active Working Group
>
>Chair(s):
>Basavaraj Patil <basavaraj.patil at nokia.com>
>Rajeev Koodli <rkoodli at starentnetworks.com>
>
>Internet Area Director(s):
>Ralph Droms <rdroms at cisco.com>
>Jari Arkko <jari.arkko at piuha.net>
>
>Internet Area Advisor:
>Jari Arkko <jari.arkko at piuha.net>
>
>Mailing Lists:
>
>General Discussion: netext at mail.mobileip.jp
>To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext
>Archive: http://www.mobileip.jp/pipermail/netext/
>
>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.
>
>The work in this charter is entirely internal to the network and does
>not affect hosts in any way (except perhaps through impacting packet
>forwarding capacity visible to the hosts).
>
>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.
>
>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.
>
>Milestones
>
>May 2009 WG chartered
>July 2009 Initial WG draft on Bulk Refresh
>July 2009 Decision on the inclusion of possible additional work items
>September 2009 Initial WG draft on LMA Redirection
>November 2009 Initial WG draft on Route Optimization
>December 2009 Submit Bulk Refresh to IESG for publication as a Proposed
>Standard RFC
>January 2010 Submit LMA Redirection to IESG for publication as a
>Proposed Standard RFC
>April 2010 Submit Route Optimization to IESG for publication as a
>Proposed Standard RFC
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce at ietf.org
>https://www.ietf.org/mailman/listinfo/ietf-announce

From: iesg-secretary at ietf.org (IESG Secretary)
Date: Wed, 20 May 2009 12:43:21 -0700 (PDT)
Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext)
Message-ID: <[email-masked]>

A new IETF working group has been formed in the Internet Area.  For
additional information, please contact the Area Directors or the WG
Chairs.

Network-Based Mobility Extensions (netext)
-------------------------------------------------------------

Last Modified: 2009-05-19

Current Status: Active Working Group

Chair(s):
Basavaraj Patil <basavaraj.patil at nokia.com>
Rajeev Koodli <rkoodli at starentnetworks.com>

Internet Area Director(s):
Ralph Droms <rdroms at cisco.com>
Jari Arkko <jari.arkko at piuha.net>

Internet Area Advisor:
Jari Arkko <jari.arkko at piuha.net>

Mailing Lists:

General Discussion: netext at mail.mobileip.jp
To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext
Archive: http://www.mobileip.jp/pipermail/netext/

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.

The work in this charter is entirely internal to the network and does
not affect hosts in any way (except perhaps through impacting packet
forwarding capacity visible to the hosts).

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.

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.

Milestones

May 2009 WG chartered
July 2009 Initial WG draft on Bulk Refresh
July 2009 Decision on the inclusion of possible additional work items
September 2009 Initial WG draft on LMA Redirection
November 2009 Initial WG draft on Route Optimization
December 2009 Submit Bulk Refresh to IESG for publication as a Proposed
Standard RFC
January 2010 Submit LMA Redirection to IESG for publication as a
Proposed Standard RFC
April 2010 Submit Route Optimization to IESG for publication as a
Proposed Standard RFC

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 19 May 2009 15:35:17 -0700 (PDT)
Subject: [Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi George,

On Tue, 19 May 2009, George Tsirtsis wrote:

> Sri, et.al.,
>
> First of all thanks for putting this together. You seem to have done
> this reluctantly implying that you had to waste your time doing this.
> This is sad by itself, but it also compound by a number of sniping
> comments and cheap shots which I am generally trying to ignore.
>

Lets focus on the technicals. I tried to keep my responses in a
positive and an objective manner and not react to any provocative
comments, or provoke you either. I really mean it. If not, I failed
some where. Any case, lets move forward and identify what we agree
and what we disagree.

As I see it:

1.) Host awareness

We both agree that for supporting some of the new features, it
needs host awareness. Without qualifying the interface or how
that can be achieved.

2.) On the historical facts as we understand, if host changes
are allowed. We can disagree on this as we did all along. But,
lets look at this this way.

a.) If the initial NETLMM goal was only to support hosts (with
no additional software requirements, or MN-AR interface signaling),
we agree or not, the protocol supports many features under these
constraints. So, we cant argue much here.

b.) Now, the goal is to extend new feature support to hosts
with some software requirements. Lets say this is a new requirement.
Adding support for this, does not remove the support for #a. You
dont agree to this requirement.

3.) Requiring software on the host, is the same as CMIP

We disagreed on this point. I do not believe the required software
will be as complex as implementing 5 other RFCS. But, this issue is
mute, if we decide to support hosts with software requirements,
complex or simple, the support exists.

4.) MN-AR Interface was always present.

There is a disagreement here. You seem to say that this interface
was never present. But, there was a WG doc. We also assumed SDO
specific interface here.

So, it appears we just need to decide if PMIP needs to extend
support hosts with some software requirements. Thats the only
disagreement. Rest of the disagreement or agreements is to fight
for this one point. Secondly, on the interface layer, if IETF
MN-AR interface, or it should be left unspecified for SDO's specific
interface.

> Believe it or not, however, your draft indicates progress in the
> quality level of this discussion, which in general has been rather
> low.
>

Ok. Good.

> In draft-tsirtsis I had to spend an inordinate amount of time and
> effort proving self-evident facts, like the fact that the
> controversial extensions to PMIPv6 REQUIRE the definition of an MN-MAG
> interface. This has been continually disputed by part of this
> community, and it has consumed large amount of time during mailing
> list discussions and even during the NETEXT BOF). The situation in
> NETEXT BOF was actualy truly appalling with even the BOF chairs
> refusing to recognize this as a fact, and even Jari being tentative
> about it.
>

I do not believe any one is saying for supporting the new features
such as flow mobility or some of the advanced inter-tech handoff
scenarios we dont require host awareness. We need some software
there. Offcourse, if the software requires changes to IETF protocols
such as RFC-4861 is subjective, that is debatable.

> You of course are trying to make it look like that this was the plan
> all along, which is nonsense but that's OK.  I am glad that at least
> your draft openly and finally states that an MN-AR interface is indeed
> needed.
>

MN-AR interface doc was a WG doc. I'm not making this up now.
If you are saying we never planned for this interface, you
can search for the WG doc in the archives.

We did not pay attention to this as the base work, except for
the advanced inter-tech handoff scenarios did not require this
interface. And we also assumed the SDO specific layer to handle
this. But, for supporting the new features, leveraging this
interface makes sense.

> So, please NETEXT funs, I do not want to have to argue another time
> that inter-tech handoffs, multihoming, and flow movement need MN
> involvement and MN-MAG signaling.
>

I'm not sure about multihoming (unless you bring up the lack of
MAC address logic and the most interesting case of a dual-radio
of same type, even then it should still assign different prefixes),
But, flow movement or some of the inter-tech handoff requires the MN
to know when to do the switch. That trigger handling or the host
awareness is required.

> Now our disagreement seems to be WRT what this MN-AR protocol is all
> about, and how it compares to client Mobile IP. In my responses below
> I am attempting to make you understand another obvious fact, one that
> I hope will take less time to absorb than the need for the MN-MAG
> protocol did. I summarise this here too:
>
> You state that the MN-MAG protocol is needed so that the MN can:
> -	Provide its interface ID(s), and (I am extrapolating) the presence of VIs etc
> -	Indicate whether it wants to handoff or not
> -	Register multiple IFs at the same time (multihoming)
> -	Indicate which flow should be routed to which MAG (flow movement)
> I agree that all of this is needed to have a complete solution and had
> to wrote draft-tsirtsis partly to prove this point. In
> draft-gundavelli, however, you talk about these functions somewhat
> dismissively as if they are trivial and not a big deal. If you
> actually think for a minute you will realize this:
>
> 1)	This MN-MAG protocol will be client initiated i.e., the MN will be
> requesting various things from the MAGs
> 2)	All of these functions are exactly what client Mobile IP provides,
> MIPv4 to the FA, MIPv6 directly to HA.
> 3)	When you add security all of the above becomes more complex than you think
>
> Why do you think this is going to be ?simpler? than client Mobile IP?
>

Requiring the host to handle this is more complex than client mobile IP,
its again subjective. IMO, its lot simpler requiring the host to
express these preferences and manage its interfaces, to implementing
5 RFC's. To prove it, some one can publish some psuedo code.

> What I am claiming in draft-tsirtsis (section 5) is that the
> functionality you require results in a protocol very much like MIPv4
> FA-mode, except maybe that security is likely to become a
> chain-of-trust model with MN-MAG and MAG-LMA legs instead of the usual
> end-to-end security used by MIP. I think such security model might
> face some interesting challenges ahead, but thats a discussion for
> another day.
>
> In the end you will end up with a lot (if not all) of the complexity
> you allegedly trying to avoid.
>

If the complexity is so much, then PMIP will fail naturally, you dont
have to even worry about this discussion. The published specs will
not have any purpose.

> This is why the comparison to client based mobility is relevant and
> important, and why the bar for a new protocol must be high. This is
> why once you introduce MN-MAG interface you have to question why this
> is not just reintroduction of the FA in the MIPv6 architecture and if
> it is really needed how it would be best introduced in the MIP
> architecture.
>
> Have a nice day.
>
> George
> P.S.: See  more comments inline.
>
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------------
> NETEXT WG                                                  S. Gundavelli
> Internet-Draft                                                     Cisco
> Intended status: Informational                              May 05, 2009
> Expires: November 6, 2009
>
>
>              Extensions to Proxy Mobile IPv6 - Motivation
>          draft-gundavelli-netext-extensions-motivation-00.txt
> ?
>
>
> 6.  Response to draft-tsirtsis-netext-controversy
>
>   The [draft-tsirtsis-netext-controversy] argues that IETF should not
>   allow the proposed new extensions to Proxy Mobile IPv6.  It is
>   unfortunate that the draft was not written in a constructive and an
>   impartial manner.  Its clear, the basic purpose of the draft is to
>   favor client-based solution.  That is fine.  One can certainly
>   disregard these comments as one's opinion, affiliation or attachment
>   to a specific technology as the reason for strong and a one sided
>   view.  But, to an innocent reader who may not know all the technical
>   details may be misled reading such views.  So, its important to
>   respond to these comments.
>
> GT> I am glad you decided to speak for the ?innocent reader?. I will
> try hard to ignore sniping comments like that letting your innocent
> reader decide what they say about their author.
>

Provocative

>
>   The draft mostly argues on legal grounds and makes number of
>   assumptions which are incorrect and continues to build the case based
>   on those assumptions and finally arrives at its own conclusions.  To
>   state a few:
>
>   o  The draft assumes that the mobile node in a Proxy Mobile IPv6
>      domain has no ability, or it should not be able to express
>      attachment, handoff or flow preferences to the network.  The
>      document builds the entire case based on this argument.  It
>      completely ignores the operating environment and does not even
>      mention about the MN-AR Interface document
>      [draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces,
>      which was always considered in the protocol design.
>
> GT> Maybe you should read draft-tsirtsis more carefully. Draft-tsirtsis
>   a) states the undisputed fact that the MN was never supposed to be
> involved (this still the case according to NETLMM charter)

But, this was disputed by many folks in the WG all along. Its ambiguous
and not clear. Client not involved in the signaling with the HA/LMA
or tunnel mgmt, to client managing its interfaces or flows is a
different thing.

I will leave it here.

Thanks
Sri

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Tue, 19 May 2009 11:34:25 -0400
Subject: [Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
Message-ID: <[email-masked]>

Sri, et.al.,

First of all thanks for putting this together. You seem to have done
this reluctantly implying that you had to waste your time doing this.
This is sad by itself, but it also compound by a number of sniping
comments and cheap shots which I am generally trying to ignore.

Believe it or not, however, your draft indicates progress in the
quality level of this discussion, which in general has been rather
low.

In draft-tsirtsis I had to spend an inordinate amount of time and
effort proving self-evident facts, like the fact that the
controversial extensions to PMIPv6 REQUIRE the definition of an MN-MAG
interface. This has been continually disputed by part of this
community, and it has consumed large amount of time during mailing
list discussions and even during the NETEXT BOF). The situation in
NETEXT BOF was actualy truly appalling with even the BOF chairs
refusing to recognize this as a fact, and even Jari being tentative
about it.

You of course are trying to make it look like that this was the plan
all along, which is nonsense but that's OK.  I am glad that at least
your draft openly and finally states that an MN-AR interface is indeed
needed.

So, please NETEXT funs, I do not want to have to argue another time
that inter-tech handoffs, multihoming, and flow movement need MN
involvement and MN-MAG signaling.

Now our disagreement seems to be WRT what this MN-AR protocol is all
about, and how it compares to client Mobile IP. In my responses below
I am attempting to make you understand another obvious fact, one that
I hope will take less time to absorb than the need for the MN-MAG
protocol did. I summarise this here too:

You state that the MN-MAG protocol is needed so that the MN can:
-	Provide its interface ID(s), and (I am extrapolating) the presence of VIs etc
-	Indicate whether it wants to handoff or not
-	Register multiple IFs at the same time (multihoming)
-	Indicate which flow should be routed to which MAG (flow movement)
I agree that all of this is needed to have a complete solution and had
to wrote draft-tsirtsis partly to prove this point. In
draft-gundavelli, however, you talk about these functions somewhat
dismissively as if they are trivial and not a big deal. If you
actually think for a minute you will realize this:

1)	This MN-MAG protocol will be client initiated i.e., the MN will be
requesting various things from the MAGs
2)	All of these functions are exactly what client Mobile IP provides,
MIPv4 to the FA, MIPv6 directly to HA.
3)	When you add security all of the above becomes more complex than you think

Why do you think this is going to be ?simpler? than client Mobile IP?

What I am claiming in draft-tsirtsis (section 5) is that the
functionality you require results in a protocol very much like MIPv4
FA-mode, except maybe that security is likely to become a
chain-of-trust model with MN-MAG and MAG-LMA legs instead of the usual
end-to-end security used by MIP. I think such security model might
face some interesting challenges ahead, but thats a discussion for
another day.

In the end you will end up with a lot (if not all) of the complexity
you allegedly trying to avoid.

This is why the comparison to client based mobility is relevant and
important, and why the bar for a new protocol must be high. This is
why once you introduce MN-MAG interface you have to question why this
is not just reintroduction of the FA in the MIPv6 architecture and if
it is really needed how it would be best introduced in the MIP
architecture.

Have a nice day.

George
P.S.: See more comments inline.

---------------------------------------------------------------------------------------------------------------------------------
NETEXT WG                                                  S. Gundavelli
Internet-Draft                                                     Cisco
Intended status: Informational                              May 05, 2009
Expires: November 6, 2009

              Extensions to Proxy Mobile IPv6 - Motivation
          draft-gundavelli-netext-extensions-motivation-00.txt
?

6.  Response to draft-tsirtsis-netext-controversy

   The [draft-tsirtsis-netext-controversy] argues that IETF should not
   allow the proposed new extensions to Proxy Mobile IPv6.  It is
   unfortunate that the draft was not written in a constructive and an
   impartial manner.  Its clear, the basic purpose of the draft is to
   favor client-based solution.  That is fine.  One can certainly
   disregard these comments as one's opinion, affiliation or attachment
   to a specific technology as the reason for strong and a one sided
   view.  But, to an innocent reader who may not know all the technical
   details may be misled reading such views.  So, its important to
   respond to these comments.

GT> I am glad you decided to speak for the ?innocent reader?. I will
try hard to ignore sniping comments like that letting your innocent
reader decide what they say about their author.

   The draft mostly argues on legal grounds and makes number of
   assumptions which are incorrect and continues to build the case based
   on those assumptions and finally arrives at its own conclusions.  To
   state a few:

   o  The draft assumes that the mobile node in a Proxy Mobile IPv6
      domain has no ability, or it should not be able to express
      attachment, handoff or flow preferences to the network.  The
      document builds the entire case based on this argument.  It
      completely ignores the operating environment and does not even
      mention about the MN-AR Interface document
      [draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces,
      which was always considered in the protocol design.

GT> Maybe you should read draft-tsirtsis more carefully. Draft-tsirtsis
   a) states the undisputed fact that the MN was never supposed to be
involved (this still the case according to NETLMM charter)
   b) it then proves that the desired extensions require that the MN
is involved (e.g., in section 4). This which was necessary to do since
the need for MN involvement has been disputed multiple times,
including during the NETEXT BOF. So, I am now glad you finally agree
and openly state that this is really unavoidable.
   c) The draft also talks about the implications of MN involvement
(e.g., section 5)

   o  The draft fails to differentiate between a mobile node expressing
      minimal hints to the network, such as attachment, connection or
      flow preferences, to a full blown mobile node with all the complex
      software requiring massive system resources and performing all
      aspects of mobility management.

GT> I happen to work for a company that builds such functionality in
mobile phones for a living; It might be reasonable to assume that I
know something about what such devices can do. I suggest that you
might be a bit behind in your appreciation of what such devices are
capable of these days.

  It equates both as one and the
      same with the conclusion that any software on the host is the same
      as client-based mobility.  But, it does not see the difference,
      boiling a glass of water to boiling an ocean.

GT> You may want to consider that comparison yourself. Based on what
you want to do in section 5 you will have to define a protocol that
can handle:
- roaming,
- inter-tech handovers,
- multihoming, and
- flow movement.
You will have to do this interoperably and securely.  Why do you think
that this is going to be a ?simple? protocol? Where do you think the
perceived complexity involved with say MIPv6 coming from, if not from
the fact that it needs to support all of the above functions?

   o  The draft reviews some of the multihoming and flow mobility
      scenario's and makes a case that it is not possible to perform
      flow mobility or support complex handoff scenario's without the
      mobile node being aware and which is correct.  Ack !  But, again
      it ignores the MN-AR Interface or SDO specific layer which can be
      used for such purpose.

GT> Perfect, as I said many people in NETEXT BOF and in the mailing
list have been trying to dodge the issue claiming that MN involvement
may not actually be needed.

   o  The draft ignores the market direction and the industry
      preferences for network-based mobility management, either in the
      form of Proxy Mobile IPv6 or Generic Tunneling Protocol [GTP], and
      the resulting benefits in that approach.

GT> The draft does not ignore them at all. Markets, rarely ask for
specific protocols. They mostly ask for functionality which we then
have to provide with ?reasonable? protocol designs, which is what this
discussion is all about.

   o  The draft disregards the amount of scrutiny, reviews and the
      external validations that went into the base protocol design for
      ensuring the protocol followed the IETF design principles.

GT> The draft does not ignore that either. On the contrary is fully
aware of the resistance experienced during PMIPv6 base protocol design
to even add basic requirements like the Handoff Indication to the
design, and the fact that the same attitude of not facing up to issues
is repeated now with further controversial extensions.

   The following sections respond to more specific comments, on section
   by section basis.

6.1.  PMIP with Host Signaling & Historic Reasons - Clarification

   There is a comment, a mobile node in a Proxy Mobile IPv6 domain is
   not allowed to have any intelligence.  And there will point you to
   some incomplete and ambiguous line in the charter that was never ever
   discussed widely during the formation of NETLMM working group and
   which went practically unnoticed.  Even if it did, it does not mean
   much and is not relevant.  In any case, following is the response to
   that comment.

   Proxy Mobile IPv6 was certainly created with the goal that the mobile
   node will not perform any mobility signaling with its local mobility
   anchor.

GT> This is the only thing draft-tsirtsis says. It says nothing about
mobiles being ?stupid?, ?dumb? or anything like that.

  So far it is correct.  However, no where in the base
   protocol specification, it ever stated and assumed that:

   o  that the mobile node that attached to a Proxy Mobile IPv6 domain
      will be a dumb and a stupid terminal which can do only a single
      attachment, cannot dynamically manage its interfaces or cannot
      configure an address dynamically on a real or on a virtual
      interface.

   o  that it will be disallowed from providing handoff, attachment or
      flow preferences to the network, through a SDO specific interface
      layer.

   o  that an operator cannot install any intelligent application
      software, such as connection manager which using the configured
      policies or user inputs, makes the network attachment decisions.

   o  that it will be disallowed from being aware of the operating
      environment.

GT> I am not sure what the above list proves and draft-tsirtsis does
not contradict any of the above.

   These restrictions do not make any sense and are not needed.
   Providing attachment and handoff preferences was always factored in
   to the design.  The MN-AR Interface document
   [draft-ietf-netlmm-mn-ar-if-03] which was a working document prior to
   the adoption of the initial Proxy Mobile IPv6 document, was specified
   for that purpose.  The protocol also allowed this interface to be
   defined in a SDO specific manner, specifying the protocol between the
   network nodes only by reacting to the provided events.  This is not a
   design flaw, but allowing the room for all the extensions to come in
   place in a evolutionary manner.

   An application software such as connection manager is a basic host
   requirement for any multihomed terminal and is not a Proxy Mobile
   IPv6 requirement.  This component cannot be avoided on any multihomed
   host.  The behavior of any host will be unpredictable and unreliable
   with respect to the choices it makes for all its network connections.
   Proxy Mobile IPv6 only requires few additional hooks on such software
   module, that too for supporting some features.

GT> A Connectivity manager, is typically self-contained, in-box,
implementation specific software, which does not produce any
out-of-box signaling. What you are talking about here is MN to AR
signaling which is clearly beyond the remit of what a normal
connectivity manager normally is all about. This is not a bad thing
by-itself but you keep talking about this as if existing connectivity
manager will just provide the PMIP-hooks for free.

6.2.  MAG ... the new FA ?

   Section 5.2.2 of [draft-tsirtsis-controversy-00] tries hard to imply
   that functional element, mobile access gateway is the same as foreign
   agent in Mobile IPv4, with the objective to prove that any software
   requirement on the client maps to Mobile IPv4 model.  Sure, the
   models map in the mobility element count, but there are role
   differences in each of those models and the argument completely
   discounts this aspect.

   In a network-based mobility model, there is an element on the network
   that is designated to perform the mobility management functions.  We
   can call this a foreign agent, mobile access gateway or a mobility
   proxy, but the functional role has a specific purpose and the model
   is not Mobile IPv4.  The functional role of the mobile node is not
   beyond than managing its interfaces, address configuration and
   expressing handoff and flow preferences to the network.

GT> Are you actually reading what you are writing? You claim that with
PMIP the MN?s role is *passive*, and yet you also say it is
?expressing handoff and flow preferences to the network. ?. What does
client Mobile IP do beyond that??

   It plays a
   mere passive role and allowing the mobile access gateway to play the
   active role on the aspects of mobility management.  So, there is a
   fundamental difference between this when compared to the Mobile IPv4.
   In any case, the comparison that is needed is in relation to client-
   based mobility.  Following are the fundamental differences between
   all the three models:

   o  In Mobile IPv4 (FA-CoA Mode), the mode of active client and
      passive network node, the mobile node plays an active role,
      performs all aspects of mobility management, while the foreign
      agent plays mere passive role

   o  In Proxy Mobile IPv6, the mode of passive client and active
      network node, the mobile node plays a mere passive role in the
      mobility management.  It does not perform any mobility signaling
      with the local mobility anchor.  It is only expected to provide
      attachment, handoff and flow preferences to the network, while the
      mobile access gateway is responsible for performing all aspects of
      mobility management.

GT> Again, according to this the MN is *passive* but it performs all
sorts of active functions like handoff and flow movement. You do
realize that you are making no sense right?

   o  In Mobile IPv6, the mode of active client, the mobile node plays
      the active role and performs all aspects of mobility management.
      It requires Mobile IPv6 client [RFC-3775], DSMIP6 [ID-DSMIP6],
      MCOA [ID-MCOA6], IKEv2 [RFC-4306] and IPsec [RFC-4301] stacks.
      Its requires significant amount of software and system resources
      on the client.

6.3.  The Internet, the Interface, and the Host

   And we got a ticket !  We are breaking the Internet building blocks.
   Section 3.0 of [draft-tsirtsis-controversy-00] is not clear on what
   the concern is.  Following are the clarifications.

   o  The IP mobility is above network layer, it is a service layer and
      as specified in Section 6.6 of [RFC-5213], a mobile node on
      attaching to the Proxy Mobile IPv6 network is required to present
      its identify.

GT> Except it does not say how?.which is why I call RFC5213 ?incomplete?.

  So, the mobile access gateway has a clear relation
      between a mobile node's identify, its link-layer identifier and on
      the offered mobility service along with the assigned prefix.  But,
      this relation is preserved in an application layer and at the IP
      layer its just the standard protocol operation confirming to all
      the standard IETF protocols.

   o  When looked at from the perspective of IP layer, the MN-AR link is
      any other IP link.  Its a point-to-point link and with the mobile
      access gateway functioning as the IPv6 router on the link.  The
      prefix set that it projects on the link is always tied to that
      mobile node's interface, but that relation is preserved in
      application layer and the network layer has no understanding of
      any of this relation.  Its a normal IPv6 link with the presence of
      two nodes on the link and a set of hosted IPv6 prefixes.

GT> Which as draft-tsirtsis indicates is fine as long as the MN has a
single interface.

   o  The comment on NDP operation for multihomed hosts is not
      applicable.  The MN-AR link is a point-to-point link, with only
      one interface of the mobile node, either real or a virtual
      interface, is present.  So, the protocol does not modify the low
      level building blocks of the Internet and so the allegation is not
      correct.

6.4.  What is wrong with PMIP so far ? Nothing !

   Clarifications to Section 4.0 of [draft-tsirtsis-controversy-00] in
   the same order.

   1.  The absence of MN-AR interface, as an IETF specified interface
       does not imply the protocol is broken.  For example, the IP layer
       is built with the assumption that the layer-2 driver for a given
       access technology will provide the required hooks for the IP
       layer.  Its the same thing here.  A given SDO can define such
       interface.

GT> Yes, this is the definition of ?broken? or at least the definition
of ?incomplete? as I call it in draft-tsirtsis. One of the major flaws
of PMIPv6 is that it is NOT self-contained.

   2.  It is indeed correct that there is no concept of a MAC address in
       certain link-layer technologies, but that's only in CDMA and in
       LTE.

GT>So all the 3GPP and 3GPP2 interfaces?you call that ?only??

The absence of such semantic in these two technologies is
       not a problem for the current operating environment.

          - the protocol uses the Access Technology Type for the
          uniqueness and for a dual-mode terminal that are going to be
          in the market, it is highly unlikely there are multiple
          radio's of the same type.

          - even otherwise, a simple semantic allowing the mobile node
          to present an identifier as part of the attachment preferences
          will be just fine.

GT> sure, which will then have to be secured appropriately, you also
want to add flow movement and handoff indications etc, as I said this
is not as simple as you try making it out to be.

   3.  The use of virtual interfaces is a host specific semantic.  It is
       perfectly valid for a host to use the physical interfaces in a
       bridged mode and present a virtual link-layer identifier.  This
       is perfectly valid and many protocols such as HRRP or VRRP use
       such mode.  This has no implication on the IPv6 link or on the
       link neighbors.

GT> Did anyone say this is a problem? On the contrary draft-tsirtsis
says this is necessary, and it had to say this since a lot of PMIP
folks have been arguing forever that somehow it might not be needed.
You of course continue to pretend that you are oblivious to the fact
that there is no way to signal the fact that a VI exists or that two
specific interfaces are under a given VI.

   4.  It is true that the mobile node can potentially specify if the
       given attachment is due to an handoff or as result of a new
       interface bringup.  But, the absence of such event is fine in
       most cases.  The network through context transfer procedures or
       through other means, can derive that information.  We can
       certainly add this in the IETF specified MN-AR interface layer.

6.5.  Its not a Tool Proliferation !

   A comment was made in Section 5.2.3 of
   [draft-tsirtsis-controversy-00], that allowing host participation in
   any level, is equivalent to client performing all aspects of mobility
   management and results in redundant tool proliferation.

   Its not always a binary logic.  No host involvement in mobility
   management does not imply the host has zero awareness of the
   operating environment, or that it is disallowed from running any
   intelligent software such as connection manager, or that is a
   violation for it express its connection or flow preferences to the
   network.  That was never a basis for the design of the Proxy Mobile
   IPv6 protocol.  Allowing the host to have such capabilities only
   improves the protocol and cannot be considered as a tool
   proliferation.

   Even otherwise, new ideas, fresh discoveries on how to deploy a
   technology in a real-world network and when coupled by urgent
   customer needs, always can re-shape a technology.  A technology
   solution that start with Protocol-A need not be restricted to that
   protocol, but instead can go with Protocol-B, if that happens to be a
   better protocol and if market wants that solution.  There are many
   instances in IETF, where it allowed multiple technologies to co-exist
   and let the market adopt what is right, to name a few:

GT> This is of course true. What I claim is not that this is never
allowed,  but that the bar for new entrants must be high and the
reasons and architectural implications must be understood before
creating yet another protocol that does the same thing with an
existing one.

On Tue, May 5, 2009 at 10:51 PM, Sri Gundavelli <sgundave at cisco.com> wrote:
>
>
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>> Sent: Thursday, April 16, 2009 3:39 AM
>> To: netext at mail.mobileip.jp
>> Subject: [Netext] Fwd: I-D
>> Action:draft-tsirtsis-netext-controversy-00.txt
>>
>> This draft is relevant to the discussion regarding the more
>> controversial proposed extensions of PMIPv6.
>>
>
> I tried to respond to all the comments raised in this document.
> The draft talks about the motivation for the new features and responds to
> the comments mentioned in draft-tsirtsis-netext-controversy-00.txt.
>
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motiv
> ation-00.txt
>
> Hopefully, both the drafts dont go for -01 version, I really had to struggle
> to
> find the time for this.
>
> Sri
>
>
>
>
>
>> I hope this helps.
>>
>> Regards
>> George
>>
>>
>> ---------- Forwarded message ----------
>> From: ?<Internet-Drafts at ietf.org>
>> Date: Thu, Apr 16, 2009 at 11:00 AM
>> Subject: I-D Action:draft-tsirtsis-netext-controversy-00.txt
>> To: i-d-announce at ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>>
>> ? ? ? ?Title ? ? ? ? ? : Discussion of Controversial PMIP Extensions
>> ? ? ? ?Author(s) ? ? ? : G. Tsirtsis
>> ? ? ? ?Filename ? ? ? ?: draft-tsirtsis-netext-controversy-00.txt
>> ? ? ? ?Pages ? ? ? ? ? : 17
>> ? ? ? ?Date ? ? ? ? ? ?: 2009-04-16
>>
>> This document discusses the recent controversy regarding PMIP
>> extensions for inter-technology handoffs and multihoming. ?Many of
>> the arguments presented below have been discussed in NETEXT BOF and
>> subsequent discussions on the mailing list. ?They are written here in
>> an attempt to explain why some of the proposed PMIP extensions are so
>> controversial.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-tsirtsis-netext-cont
>> roversy-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce at ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 19 May 2009 17:18:40 +0800
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,

Thanks for the response.

Please see some replies.

BR,
Mohana

> -----Original Message-----
> From: Sri Gundavelli [mailto:sgundave at cisco.com]
> Sent: Tuesday, May 19, 2009 1:51 PM
> To: Mohana Jeyatharan
> Cc: netext at mail.mobileip.jp
> Subject: RE: [Netext] New Version Notification for draft-gundavelli-
> netext-extensions-motivation-00 (fwd)
> 
> Hi Mohana,
> 
> Thanks for the review comments. Some comments below.
> 
> 1. Mainly, the assumptions or the requirements that are placed
> on the host by some of the new features, such as flow mobility,
> we need some explicit triggers from the host to the network.
> Potentially this interface can be captured in the MN-AR interface
> doc and with the triggers idenfied. Having an IETF specified MN-AR
> interface doc can complete the whole puzzle and also can be
> referenced for developing alternative SDO specific interfaces. In
> that sense, this interface is critical.

Ok, understand. So, this interface can be used by any SDO. It is better
to standardize such an interface in IETF. 

> 2. Also, as Raj pointed out earlier, we need to classify the hosts
> in a slightly different manner. The support for PMIP can be for
> a.) The sacred unmodified client, what ever that is, and b.) Host
> with some intelligence to express flow and attach preferences.
> RFC-5213 has support for all the base features for type-a hosts.
> However, for supporting inter-tech handoffs in a complete and
> explicit way, we need #b. But, adding support for #b does not
> take away support for #a. So, its important to classify the hosts
> w.r.t PMIP support, in both the ways.

Yes. So, now we want to work on #b and we are in no way taking away
support for #a. So the initial goal of PMIPv6 still stands. I really
don't understand what are we breaking by making the UE a little smarter.
I hope we all can agree on this and push the multihoming and inter
access handoff into the Netext charter. 

> 3. The host awareness overall improves the protocol. Allowing the
> mobile to understand that the projected prefix has mobility
> characterstics, or that it is in a PMIP domain, is useful for
> it to express the preferences to the network in a better manner.

Yes and also there is nothing wrong in making the terminal intelligent.
Making the terminal intelligent is nothing to do with MN performing
mobility management. Again, I hope all in the WG can agree to this.

> Regards
> Sri
> 
> 
> On Mon, 18 May 2009, Mohana Jeyatharan wrote:
> 
> > Hi Sri,
> >
> > Thanks for your tremendous effort in writing this draft and
highlighting
> > the urgent need for PMIPv6 to be extended to support multihoming and
> > inter access technology handoffs.
> >
> > As you have clearly indicated in this draft, that creating a
connection
> > manager to indicate the MN's intention is already the underlying
> > assumption in RFC 5213. Thus, such operation is already widely
accepted
> > for PMIPv6 deployment and such signaling should be no problem. In
that
> > case, I hope we can all agree, to perform flow mobility and inter
access
> > technology using such connection manager module that controls such
> > processes is required and it is not like breaking any IETF design
rules.
> >
> >
> > Also, thanks Sri for explaining the protocols that have been
developed
> > by IETF and how feature add on has been done in the past. MIPv6 was
> > developed and now we are developing a protocol MCoA to perform
> > multihoming. I am also referring to section 6.5 where you have
> > highlighted multiple technologies have co-exitsted in IETF. Similary
> > PMIPv6 was developed with the motive of "providing mobility support
for
> > unmodified hosts"
> > and now we need to look into ways of enhancing PMIPv6 so that we can
> > achieve flow mobility, inter access technology handoffs and so on.
As
> > you have clearly indicated, introducing a connection manager to
legacy
> > hosts does not mean you are changing anything at L3 and it is not
> > introducing many software logic into the MN to perform mobility.
> >
> > Thus it is clear that, PMIPv6 is a network based mobility management
> > protocol(no MN-LMA signaling) and a MN should be allowed to perform
> > multihoming and inter access handoff by using a simple software
module.
> > In 3GPP people are looking into ways of extending the protocol for
flow
> > mobility. After all, IETF developed PMIPv6 bcos there was a need
from
> > the industry. Similarly, if operators are interested in flow
mobility
> > when PMIPv6 is used to manage mobility for multiple interfaced node,
> > then why IETF is reluctant to accept this? After all IETF has done
> > multiple developed multiple technologies.
> >
> > Sri I just have two clarification questions.
> > (1) So are you saying that the MN-AR document is thebest way to
handle
> > the flow mobility, handoff indication and stuff or do you think SDO
> > specific layer is needed. Bcos, in the draft you mentioned both and
it
> > is not very clear to me.
> >
> > (2) If MN is aware it is PMIPv6 domain, then can it be modified in a
way
> > that the host can be able to accept packets addresses to one
interface
> > via the other interface. I am asking this bcos, this is point to
point
> > model and there should be no problem. Any thoughts on this? Does it
need
> > lot of software logic to perform this.
> >
> > I hope we can all agree that featrure add on to PMIPv6 is not
breaking
> > the Internet or anything like that. IETF must work on this, bcos the
> > industries are nterested in it and there are lot of people in IETF
who
> > want to work on this. People want to work on this bcos it has a good
> > use.
> >

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 18 May 2009 22:50:43 -0700 (PDT)
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Mohana,

Thanks for the review comments. Some comments below.

1. Mainly, the assumptions or the requirements that are placed
on the host by some of the new features, such as flow mobility,
we need some explicit triggers from the host to the network.
Potentially this interface can be captured in the MN-AR interface
doc and with the triggers idenfied. Having an IETF specified MN-AR
interface doc can complete the whole puzzle and also can be
referenced for developing alternative SDO specific interfaces. In
that sense, this interface is critical.

2. Also, as Raj pointed out earlier, we need to classify the hosts
in a slightly different manner. The support for PMIP can be for
a.) The sacred unmodified client, what ever that is, and b.) Host
with some intelligence to express flow and attach preferences.
RFC-5213 has support for all the base features for type-a hosts.
However, for supporting inter-tech handoffs in a complete and
explicit way, we need #b. But, adding support for #b does not
take away support for #a. So, its important to classify the hosts
w.r.t PMIP support, in both the ways.

3. The host awareness overall improves the protocol. Allowing the
mobile to understand that the projected prefix has mobility
characterstics, or that it is in a PMIP domain, is useful for
it to express the preferences to the network in a better manner.

Regards
Sri

On Mon, 18 May 2009, Mohana Jeyatharan wrote:

> Hi Sri,
>
> Thanks for your tremendous effort in writing this draft and highlighting
> the urgent need for PMIPv6 to be extended to support multihoming and
> inter access technology handoffs.
>
> As you have clearly indicated in this draft, that creating a connection
> manager to indicate the MN's intention is already the underlying
> assumption in RFC 5213. Thus, such operation is already widely accepted
> for PMIPv6 deployment and such signaling should be no problem. In that
> case, I hope we can all agree, to perform flow mobility and inter access
> technology using such connection manager module that controls such
> processes is required and it is not like breaking any IETF design rules.
>
>
> Also, thanks Sri for explaining the protocols that have been developed
> by IETF and how feature add on has been done in the past. MIPv6 was
> developed and now we are developing a protocol MCoA to perform
> multihoming. I am also referring to section 6.5 where you have
> highlighted multiple technologies have co-exitsted in IETF. Similary
> PMIPv6 was developed with the motive of "providing mobility support for
> unmodified hosts"
> and now we need to look into ways of enhancing PMIPv6 so that we can
> achieve flow mobility, inter access technology handoffs and so on. As
> you have clearly indicated, introducing a connection manager to legacy
> hosts does not mean you are changing anything at L3 and it is not
> introducing many software logic into the MN to perform mobility.
>
> Thus it is clear that, PMIPv6 is a network based mobility management
> protocol(no MN-LMA signaling) and a MN should be allowed to perform
> multihoming and inter access handoff by using a simple software module.
> In 3GPP people are looking into ways of extending the protocol for flow
> mobility. After all, IETF developed PMIPv6 bcos there was a need from
> the industry. Similarly, if operators are interested in flow mobility
> when PMIPv6 is used to manage mobility for multiple interfaced node,
> then why IETF is reluctant to accept this? After all IETF has done
> multiple developed multiple technologies.
>
> Sri I just have two clarification questions.
> (1) So are you saying that the MN-AR document is thebest way to handle
> the flow mobility, handoff indication and stuff or do you think SDO
> specific layer is needed. Bcos, in the draft you mentioned both and it
> is not very clear to me.
>
> (2) If MN is aware it is PMIPv6 domain, then can it be modified in a way
> that the host can be able to accept packets addresses to one interface
> via the other interface. I am asking this bcos, this is point to point
> model and there should be no problem. Any thoughts on this? Does it need
> lot of software logic to perform this.
>
> I hope we can all agree that featrure add on to PMIPv6 is not breaking
> the Internet or anything like that. IETF must work on this, bcos the
> industries are nterested in it and there are lot of people in IETF who
> want to work on this. People want to work on this bcos it has a good
> use.
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 18 May 2009 22:50:36 -0700
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thanks Frank for the review. Good to know you agree with the
thoughts.

Sri

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong at huawei.com] 
> Sent: Wednesday, May 06, 2009 2:17 PM
> To: Sri Gundavelli; netext at mail.mobileip.jp
> Subject: Re: [Netext] New Version Notification for 
> draft-gundavelli-netext-extensions-motivation-00 (fwd)
> 
> Hi Sri
> 
> I have a quick look at the document.
> 
> Some common view points I share with you are as following:
> 1)"reviving the  MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]"
> 2)"This(notes: clint mobile IP) may happen eventually, but for the
>       current time frame, the market is looking for other 
> solutions and
>       network-based mobility is the preferred approach which requires
>       minimal host support with a small application module that any
>      vendor can develop in no time"
> ... ...
> 
> Additional, I would like to give you a real deployment case.
> Verizon LTE network will use PMIPv6 between
> HSGW/ePDSN and PDN SAE GW.  AFAIK, this will be the
> first large-scale IP mobility deployment.
> 
> Now that we can't stop PMIP deployment, the only way we
> can benefit the industry is to solve the problems which PMIP
> deployment would encounter.
> 
> BR
> Frank
> 
> ----- Original Message ----- 
> From: "Sri Gundavelli" <sgundave at cisco.com>
> To: <netext at mail.mobileip.jp>
> Sent: Tuesday, May 05, 2009 9:53 PM
> Subject: [Netext] New Version Notification for 
> draft-gundavelli-netext-extensions-motivation-00 (fwd)
> 
> 
> >
> > This provides some motivation for the flow mobility and 
> other extensions.
> >
> > 
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-ex
> tensions-motivation-00.txt
> >
> >
> >
> > ---------- Forwarded message ----------
> > Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
> > From: IETF I-D Submission Tool <idsubmission at ietf.org>
> > To: sgundave at cisco.com
> > Subject: New Version Notification for
> >     draft-gundavelli-netext-extensions-motivation-00
> >
> >
> > A new version of I-D, 
> draft-gundavelli-netext-extensions-motivation-00.txt 
> > has been successfuly submitted by Sri Gundavelli and posted 
> to the IETF 
> > repository.
> >
> > Filename: draft-gundavelli-netext-extensions-motivation
> > Revision: 00
> > Title: Extensions to Proxy Mobile IPv6 - Motivation
> > Creation_date: 2009-05-05
> > WG ID: Independent Submission
> > Number_of_pages: 24
> >
> > Abstract:
> > Proxy Mobile IPv6 is a network-based mobility management protocol
> > standardized in IETF and is being specified in various system
> > architectures as a protocol for building a common and access
> > independent mobile core.  Currently, there are number of proposals
> > and a huge amount of interest in NETEXT working group for extending
> > the protocol to support various mobility extensions.  This document
> > identifies some of the critical extensions that are absolutely
> > required and builds a case as why these extensions have to be
> > supported.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext 
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Mon, 18 May 2009 08:53:09 +0800
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,

Thanks for your tremendous effort in writing this draft and highlighting
the urgent need for PMIPv6 to be extended to support multihoming and
inter access technology handoffs.

As you have clearly indicated in this draft, that creating a connection
manager to indicate the MN's intention is already the underlying
assumption in RFC 5213. Thus, such operation is already widely accepted
for PMIPv6 deployment and such signaling should be no problem. In that
case, I hope we can all agree, to perform flow mobility and inter access
technology using such connection manager module that controls such
processes is required and it is not like breaking any IETF design rules.

Also, thanks Sri for explaining the protocols that have been developed
by IETF and how feature add on has been done in the past. MIPv6 was
developed and now we are developing a protocol MCoA to perform
multihoming. I am also referring to section 6.5 where you have
highlighted multiple technologies have co-exitsted in IETF. Similary
PMIPv6 was developed with the motive of "providing mobility support for
unmodified hosts"
and now we need to look into ways of enhancing PMIPv6 so that we can
achieve flow mobility, inter access technology handoffs and so on. As
you have clearly indicated, introducing a connection manager to legacy
hosts does not mean you are changing anything at L3 and it is not
introducing many software logic into the MN to perform mobility. 

Thus it is clear that, PMIPv6 is a network based mobility management
protocol(no MN-LMA signaling) and a MN should be allowed to perform
multihoming and inter access handoff by using a simple software module.
In 3GPP people are looking into ways of extending the protocol for flow
mobility. After all, IETF developed PMIPv6 bcos there was a need from
the industry. Similarly, if operators are interested in flow mobility
when PMIPv6 is used to manage mobility for multiple interfaced node,
then why IETF is reluctant to accept this? After all IETF has done
multiple developed multiple technologies.

Sri I just have two clarification questions.
(1) So are you saying that the MN-AR document is thebest way to handle
the flow mobility, handoff indication and stuff or do you think SDO
specific layer is needed. Bcos, in the draft you mentioned both and it
is not very clear to me.

(2) If MN is aware it is PMIPv6 domain, then can it be modified in a way
that the host can be able to accept packets addresses to one interface
via the other interface. I am asking this bcos, this is point to point
model and there should be no problem. Any thoughts on this? Does it need
lot of software logic to perform this.

I hope we can all agree that featrure add on to PMIPv6 is not breaking
the Internet or anything like that. IETF must work on this, bcos the
industries are nterested in it and there are lot of people in IETF who
want to work on this. People want to work on this bcos it has a good
use.

BR,
Mohana
> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Sri Gundavelli
> Sent: Wednesday, May 06, 2009 10:53 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] New Version Notification for
draft-gundavelli-netext-
> extensions-motivation-00 (fwd)
> 
> 
> This provides some motivation for the flow mobility and other
extensions.
> 
>
http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-
> motivation-00.txt
> 
> 
> 
> ---------- Forwarded message ----------
> Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> To: sgundave at cisco.com
> Subject: New Version Notification for
>      draft-gundavelli-netext-extensions-motivation-00
> 
> 
> A new version of I-D,
draft-gundavelli-netext-extensions-motivation-00.txt
> has been successfuly submitted by Sri Gundavelli and posted to the
IETF
> repository.
> 
> Filename:	 draft-gundavelli-netext-extensions-motivation
> Revision:	 00
> Title:		 Extensions to Proxy Mobile IPv6 - Motivation
> Creation_date:	 2009-05-05
> WG ID:		 Independent Submission
> Number_of_pages: 24
> 
> Abstract:
> Proxy Mobile IPv6 is a network-based mobility management protocol
> standardized in IETF and is being specified in various system
> architectures as a protocol for building a common and access
> independent mobile core.  Currently, there are number of proposals
> and a huge amount of interest in NETEXT working group for extending
> the protocol to support various mobility extensions.  This document
> identifies some of the critical extensions that are absolutely
> required and builds a case as why these extensions have to be
> supported.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Wed, 13 May 2009 18:05:26 +0200
Subject: [Netext] Extending PMIPv6 to support also mobile access networks
Message-ID: <1242230726.5379.42.camel@localhost>

Hi all,

	Some weeks ago we were discussing about potential next steps in NETEXT.
One of the suggested topics was NEMO+PMIPv6 and, related to that, I
brought the issue of extending PMIPv6 to support not only non-mobile
points of attachment (i.e., MAGs), but also mobile ones (enabling mobile
platforms).

	We have just published a paper in which we describe some of the
scenarios we have in mind, the motivation and a potential solution
(please note that we claim some IPR on parts of the solution):

http://www.comsoc.org/livepubs/ci1/public/2009/may/bernardos.html

	Comments are highly welcome.

	Thanks,

	Carlos

P.S.: If you cannot get the paper and wants to read it, please contact
me directly and I'll send you the pdf.
-- 
   Carlos Jes?s Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
        Advances in Vehicular Communications Networks
 http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090513/bdac2277/attachment.bin>

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 07 May 2009 09:38:47 -0500
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00	(fwd)
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jong-Hyouk

Sorry,  I get this information from my 
friends in Verizon.

Probably, we can wait and see if some 
formal documents available.

BR
Frank
  ----- Original Message ----- 
  From: Jong-Hyouk Lee 
  To: Frank Xia 
  Cc: Sri Gundavelli ; netext at mail.mobileip.jp 
  Sent: Thursday, May 07, 2009 5:07 AM
  Subject: Re: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)

  Hi. Frank.

  Thanks for providing the real use case of PMIPv6. Could you provide more details about the news Verizon LTE will deploy PMIPv6? Is there any formal document or link for it?

  Cheers.

  On Thu, May 7, 2009 at 6:17 AM, Frank Xia <xiayangsong at huawei.com> wrote:

    Hi Sri

    I have a quick look at the document.

    Some common view points I share with you are as following:
    1)"reviving the  MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]"
    2)"This(notes: clint mobile IP) may happen eventually, but for the
        current time frame, the market is looking for other solutions and
        network-based mobility is the preferred approach which requires
        minimal host support with a small application module that any
       vendor can develop in no time"
    ... ...

    Additional, I would like to give you a real deployment case.
    Verizon LTE network will use PMIPv6 between
    HSGW/ePDSN and PDN SAE GW.  AFAIK, this will be the
    first large-scale IP mobility deployment.

    Now that we can't stop PMIP deployment, the only way we
    can benefit the industry is to solve the problems which PMIP
    deployment would encounter.

    BR
    Frank

    ----- Original Message ----- From: "Sri Gundavelli" <sgundave at cisco.com>
    To: <netext at mail.mobileip.jp>
    Sent: Tuesday, May 05, 2009 9:53 PM
    Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) 

      This provides some motivation for the flow mobility and other extensions.

      http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt

      ---------- Forwarded message ----------
      Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
      From: IETF I-D Submission Tool <idsubmission at ietf.org>
      To: sgundave at cisco.com
      Subject: New Version Notification for
         draft-gundavelli-netext-extensions-motivation-00

      A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository.

      Filename: draft-gundavelli-netext-extensions-motivation
      Revision: 00
      Title: Extensions to Proxy Mobile IPv6 - Motivation
      Creation_date: 2009-05-05
      WG ID: Independent Submission
      Number_of_pages: 24

      Abstract:
      Proxy Mobile IPv6 is a network-based mobility management protocol
      standardized in IETF and is being specified in various system
      architectures as a protocol for building a common and access
      independent mobile core.  Currently, there are number of proposals
      and a huge amount of interest in NETEXT working group for extending
      the protocol to support various mobility extensions.  This document
      identifies some of the critical extensions that are absolutely
      required and builds a case as why these extensions have to be
      supported.

      The IETF Secretariat.

      _______________________________________________
      NetExt mailing list
      NetExt at mail.mobileip.jp
      http://www.mobileip.jp/mailman/listinfo/netext 

    _______________________________________________
    NetExt mailing list
    NetExt at mail.mobileip.jp
    http://www.mobileip.jp/mailman/listinfo/netext

  -- 
  Internet Management Technology Lab, Sungkyunkwan University. 
  Jong-Hyouk Lee.

  #email: jonghyouk (at) gmail (dot) com 
  #webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090507/a8bcd1cc/attachment.html>

From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Thu, 7 May 2009 19:07:17 +0900
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi. Frank.

Thanks for providing the real use case of PMIPv6. Could you provide more
details about the news Verizon LTE will deploy PMIPv6? Is there any formal
document or link for it?

Cheers.

On Thu, May 7, 2009 at 6:17 AM, Frank Xia <xiayangsong at huawei.com> wrote:

> Hi Sri
>
> I have a quick look at the document.
>
> Some common view points I share with you are as following:
> 1)"reviving the  MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]"
> 2)"This(notes: clint mobile IP) may happen eventually, but for the
>     current time frame, the market is looking for other solutions and
>     network-based mobility is the preferred approach which requires
>     minimal host support with a small application module that any
>    vendor can develop in no time"
> ... ...
>
> Additional, I would like to give you a real deployment case.
> Verizon LTE network will use PMIPv6 between
> HSGW/ePDSN and PDN SAE GW.  AFAIK, this will be the
> first large-scale IP mobility deployment.
>
> Now that we can't stop PMIP deployment, the only way we
> can benefit the industry is to solve the problems which PMIP
> deployment would encounter.
>
> BR
> Frank
>
> ----- Original Message ----- From: "Sri Gundavelli" <sgundave at cisco.com>
> To: <netext at mail.mobileip.jp>
> Sent: Tuesday, May 05, 2009 9:53 PM
> Subject: [Netext] New Version Notification for
> draft-gundavelli-netext-extensions-motivation-00 (fwd)
>
>
>
>
>> This provides some motivation for the flow mobility and other extensions.
>>
>>
>> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt
>>
>>
>>
>> ---------- Forwarded message ----------
>> Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
>> From: IETF I-D Submission Tool <idsubmission at ietf.org>
>> To: sgundave at cisco.com
>> Subject: New Version Notification for
>>    draft-gundavelli-netext-extensions-motivation-00
>>
>>
>> A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt
>> has been successfuly submitted by Sri Gundavelli and posted to the IETF
>> repository.
>>
>> Filename: draft-gundavelli-netext-extensions-motivation
>> Revision: 00
>> Title: Extensions to Proxy Mobile IPv6 - Motivation
>> Creation_date: 2009-05-05
>> WG ID: Independent Submission
>> Number_of_pages: 24
>>
>> Abstract:
>> Proxy Mobile IPv6 is a network-based mobility management protocol
>> standardized in IETF and is being specified in various system
>> architectures as a protocol for building a common and access
>> independent mobile core.  Currently, there are number of proposals
>> and a huge amount of interest in NETEXT working group for extending
>> the protocol to support various mobility extensions.  This document
>> identifies some of the critical extensions that are absolutely
>> required and builds a case as why these extensions have to be
>> supported.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090507/61a9542a/attachment.html>

From: xiayangsong at huawei.com (Frank Xia)
Date: Wed, 06 May 2009 16:17:18 -0500
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri

I have a quick look at the document.

Some common view points I share with you are as following:
1)"reviving the  MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]"
2)"This(notes: clint mobile IP) may happen eventually, but for the
      current time frame, the market is looking for other solutions and
      network-based mobility is the preferred approach which requires
      minimal host support with a small application module that any
     vendor can develop in no time"
... ...

Additional, I would like to give you a real deployment case.
Verizon LTE network will use PMIPv6 between
HSGW/ePDSN and PDN SAE GW.  AFAIK, this will be the
first large-scale IP mobility deployment.

Now that we can't stop PMIP deployment, the only way we
can benefit the industry is to solve the problems which PMIP
deployment would encounter.

BR
Frank

----- Original Message ----- 
From: "Sri Gundavelli" <sgundave at cisco.com>
To: <netext at mail.mobileip.jp>
Sent: Tuesday, May 05, 2009 9:53 PM
Subject: [Netext] New Version Notification for 
draft-gundavelli-netext-extensions-motivation-00 (fwd)

>
> This provides some motivation for the flow mobility and other extensions.
>
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt
>
>
>
> ---------- Forwarded message ----------
> Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> To: sgundave at cisco.com
> Subject: New Version Notification for
>     draft-gundavelli-netext-extensions-motivation-00
>
>
> A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt 
> has been successfuly submitted by Sri Gundavelli and posted to the IETF 
> repository.
>
> Filename: draft-gundavelli-netext-extensions-motivation
> Revision: 00
> Title: Extensions to Proxy Mobile IPv6 - Motivation
> Creation_date: 2009-05-05
> WG ID: Independent Submission
> Number_of_pages: 24
>
> Abstract:
> Proxy Mobile IPv6 is a network-based mobility management protocol
> standardized in IETF and is being specified in various system
> architectures as a protocol for building a common and access
> independent mobile core.  Currently, there are number of proposals
> and a huge amount of interest in NETEXT working group for extending
> the protocol to support various mobility extensions.  This document
> identifies some of the critical extensions that are absolutely
> required and builds a case as why these extensions have to be
> supported.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 5 May 2009 19:53:28 -0700 (PDT)
Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd)
Message-ID: <[email-masked]>

This provides some motivation for the flow mobility and other extensions.

http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt

---------- Forwarded message ----------
Date: Tue,  5 May 2009 19:42:20 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission at ietf.org>
To: sgundave at cisco.com
Subject: New Version Notification for
     draft-gundavelli-netext-extensions-motivation-00

A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository.

Filename:	 draft-gundavelli-netext-extensions-motivation
Revision:	 00
Title:		 Extensions to Proxy Mobile IPv6 - Motivation
Creation_date:	 2009-05-05
WG ID:		 Independent Submission
Number_of_pages: 24

Abstract:
Proxy Mobile IPv6 is a network-based mobility management protocol
standardized in IETF and is being specified in various system
architectures as a protocol for building a common and access
independent mobile core.  Currently, there are number of proposals
and a huge amount of interest in NETEXT working group for extending
the protocol to support various mobility extensions.  This document
identifies some of the critical extensions that are absolutely
required and builds a case as why these extensions have to be
supported.

The IETF Secretariat.

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 5 May 2009 19:51:47 -0700
Subject: [Netext] Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
> Sent: Thursday, April 16, 2009 3:39 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Fwd: I-D 
> Action:draft-tsirtsis-netext-controversy-00.txt
> 
> This draft is relevant to the discussion regarding the more
> controversial proposed extensions of PMIPv6.
> 

I tried to respond to all the comments raised in this document.
The draft talks about the motivation for the new features and responds to
the comments mentioned in draft-tsirtsis-netext-controversy-00.txt.

http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motiv
ation-00.txt

Hopefully, both the drafts dont go for -01 version, I really had to struggle
to
find the time for this.

Sri

> I hope this helps.
> 
> Regards
> George
> 
> 
> ---------- Forwarded message ----------
> From:  <Internet-Drafts at ietf.org>
> Date: Thu, Apr 16, 2009 at 11:00 AM
> Subject: I-D Action:draft-tsirtsis-netext-controversy-00.txt
> To: i-d-announce at ietf.org
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> ? ? ? ?Title ? ? ? ? ? : Discussion of Controversial PMIP Extensions
> ? ? ? ?Author(s) ? ? ? : G. Tsirtsis
> ? ? ? ?Filename ? ? ? ?: draft-tsirtsis-netext-controversy-00.txt
> ? ? ? ?Pages ? ? ? ? ? : 17
> ? ? ? ?Date ? ? ? ? ? ?: 2009-04-16
> 
> This document discusses the recent controversy regarding PMIP
> extensions for inter-technology handoffs and multihoming. ?Many of
> the arguments presented below have been discussed in NETEXT BOF and
> subsequent discussions on the mailing list. ?They are written here in
> an attempt to explain why some of the proposed PMIP extensions are so
> controversial.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-tsirtsis-netext-cont
> roversy-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Fri, 1 May 2009 18:39:56 +0200
Subject: [Netext] Netext BoF at IETF74: Meeting minutes
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi George,

I am sure the audio archives of the meeting reflect the reality.
Let me see if I can improve the meeting minutes and capture your comments
beyond the one that you see now. If you have some notes of the meeting as
well and can share it, I would be happy to incorporate it.

-Raj 

On 5/1/09 11:11 AM, "ext George Tsirtsis" <tsirtsis at googlemail.com> wrote:

> Funny, I kind of remember standing in front of that mic quit a lot but
> according to this, I made exactly one comment during the entire BOF.
> 
> Maybe its my Greek accent :-)
> 
> George
> 
> On Fri, May 1, 2009 at 4:51 PM,  <Basavaraj.Patil at nokia.com> wrote:
>> 
>> 
>> Network-based Mobility Extensions (NetExt) Bof
>> THURSDAY, March 26, 2009
>> 1300-1500 Afternoon Session I in Imperial A
>> 
>> Bof chairs: Rajeev Koodli <rkoodli at starentnetworks dot com>
>> ? ? ? ?Basavaraj Patil <basavaraj dot patil at nokia dot com>
>> 
>> Acknowledgment for the meeting minutes:
>> ? ?Samita Chakrabarti <samitac at ipinfusion dot com>
>> ? ?Harsh Verma <harsh dot verma at rsystems dot com>
>> 
>> -----------------------------------------------
>> 
>> 1. Bof Overview and Scope - Chairs
>> 
>> - Background ? Bar BoF discussion held at Dublin IETF , dinner meeting
>> ? ? ? at IETF73, work on problem statements initiated
>> 
>> - PMIP6 is one of the protocols for IP Mob management in emerging network
>> ?architectures ?(LTE/SAE in 3GPP, Wimax)
>> 
>> - A few improvements/deployment considerations need to be addressed
>> ?? ? ? ? Multi-interface support
>> ?? ? ? ? Localized routing
>> ?? ? ? ? Inter-technology handovers
>> - Objective today: Discuss if we have consensus w.r.t the proposed
>> ?extensions to PMIP6 and whether to form a wg to work on the same
>> 
>> - Ground rules:
>> ?. Assume PMIP6 as the basis [ no MIP6 interaction]
>> ?. Not a placeholder for all NETLMM related topis
>> 
>> Hesham ? ?- Is that a realistic rule?
>> 
>> Jari ? clarified that will take into account for new MIP6 features,
>> ? ? but we already have a charter in the general WG.
>> 
>> Jari - if we develop a new feature, it should not become harder or we
>> ? ? should provide a mechanism. This WG will only deal with the problem
>> ? ? but not provide a solution
>> 
>> ? ? The intent here was that we are not going identify any new work
>> 
>> Sri - Be careful of formulating Ground Rules
>> 
>> Jari ? Interaction with MIP6
>> 
>> Vijay ? had a comment on which is a concern that PMIP6 is still not a
>> ? ? ?deployable protocol. There are still a few more items..
>> 
>> Rajiv ? MN involvement is not the same as protocol-level changes.
>> ?The question to ask is can we not design a protocol without host
>> ?changes for the problem in question?
>> ?What breaks and what doesn?t?
>> 
>> Domagoj ? comment ? if something has to be done on the MN side, why
>> ? ?can it not be taken care of
>> 
>> Hesham ? No changes to the MN approach ? if we have to change it we
>> ? ? ? will change it.
>> 
>> Rajiv - We do not want to design disincentives. It is too early to say
>> ? ? ?that host changes are needed.
>> 
>> Jari ? If we have a proposal that allows us to do things, it will go
>> ? ? into the charter and others will not.
>> 
>> .....................
>> 
>> 2. Multi-interface support for PMIP6 ( Vijay Deverapalli)
>> I-D: draft-jeyatharan-netext-multihoming-ps-01
>> 
>> -Using PMIP6 to specify multi-interface network mobility is under-specified.
>> ? ? ? Scenario1 - setting up mobility sessions on demand: additional
>> ? ? ? mobility session for a particular service
>> ? ? ? Scenario 2 ? Flow mobility
>> ? ? ? MN ?may bring up another interface is another access is
>> ? ? ? available and then move some flows to the other interface for
>> ? ? ? load balancing
>> ? ? ? Scenario 3 : attachment to a new MAG and multi-interfaces of MN
>> ? ? ? ? -- handover of sessions from if1 to if2 and MAG-old to
>> ? ? ? MAG-new
>> 
>> Parvez ? There are 3 different scenarios, but what about an MN
>> ? ? ? attaching to multiple PDNs? Should it use the same address?
>> 
>> Vijay ? different IP addresses for different interfaces
>> 
>> Dave - Scenario 2: If the MN wants to move flows from one IF to the
>> ? ? other, is the same IP address used on both interfaces??
>> 
>> Sri ? If there are interfaces with a virtual node, it is possible.
>> 
>> Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an
>> ? ?extension to 5213 and 5213 does not prevent it
>> 
>> Hesham ? This is not rocket science. It is not a new problem.
>> 
>> Rajeev ? this is not a new protocol, but there are obviously
>> ? ? ? implementation issues
>> 
>> Hesham ? does not make any sense from the perspective of no MN changes
>> 
>> Raj ? there may be things that could b done at another layer which
>> ? ?could accomplish the same thing. We are not re-inventing a new
>> ? ?protocol.
>> 
>> Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be
>> ? ? ?needed here?
>> 
>> Vijay ? just to first see if there is a problem and can it be solved
>> ? ? ?with an access service mechanism.
>> 
>> Rajeev ? it could be a PDN, but this is for a new additional session
>> 
>> ??? ? assign multiple
>> ? ?Try to assign two interfaces, it does not work.
>> ? ?Tricks people do to hide
>> 
>> Rajeev ? it is difference between protocol and what you need to do for
>> implementation
>> 
>> ??? - ? ?It requires Mobile Intervention.
>> ? ?Not sure if we can do this at IETF
>> 
>> Kent ? Need a document what can change in implementation and what
>> ? ? cannot be changed.
>> ? ? Ans(Raj): We will look into that but the current BOF is to
>> ? ? describe the problem
>> 
>> Raj ? we will have to deal
>> 
>> Dave ? Are we talking about changes to some proprietary info about MN
>> ? ? or dependencies of RFCs?
>> 
>> Sri ? Would you consider? Dave ? there is no RFC
>> 
>> Jabber - Vidya says that we do not want to modify MN in any way to
>> ? ? ? support this feature
>> 
>> ........................
>> 
>> 3. PMIPv6 localized routing (Marco Liebsch)
>> I-D: draft-liebsch-netext-pmip6-ro-ps-00
>> 
>> Obj: establish and maintain forwarding data for two MNs (during
>> ? ? handovers) without going through MN?s LMA. Fundamental difference
>> ? ? to host mobility, such as MIPv6 RO.
>> 
>> MNs have no control on setting up localized routes is correct
>> 
>> Discussion ?
>> 
>> Kent ? Are Handovers also covered in Detection and Setup
>> ? ?When you are doing Handover, you want to establish and
>> ? ?maintain the optimized routing.
>> ? ?Is the scope MAG to MAG or LMA to LMA?
>> 
>> 
>> Raj ? the base spec allows you to do Localized Routing
>> 
>> Marco ? if you handle everything locally
>> 
>> Carlos ? use of EnableMAGLocalRouting Flag within the scope of the
>> ? ? ? work should be clarified. We are only assuming PMIP MNs. This Flag is
>> ? ? ? used for optimizing between a PMIP and regular host.
>> 
>> Sri ? No, this is not so.
>> 
>> Sri ? Is the focus on lack of signaling?
>> 
>> Parvez - Should send an email on his point
>> Raj ? granularity of localized routing may be discussed
>> 
>> ??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4
>> ? ?address. So it is ?possible.
>> 
>> Rajeev ? the flow can be between any two end-points and not restricted
>> ? ? ? to hosts that are PMIP6 MNs only
>> 
>> ....................
>> 
>> 4. Inter technology handovers (Suresh Krishnan)
>> I-D: draft-krishnan-netext-intertech-ps-00
>> 
>> See slides for PS overview.
>> 
>> Discussion
>> Chan Wah ? What is the timeframe for Predictive Handovers?
>> 
>> Suresh ? Does not matter, can be a second or a day
>> 
>> Suresh ? Access Network may be separate from Mobility Provider.
>> 
>> Sri ? Implementation Specific Issues ? is Prefix an issue?
>> ? ?If we move to a new prefix, the app will break
>> ? ?Let?s say we have a Virtual Interface sitting on top of two
>> ? ?physical interfaces
>> 
>> Hesham ? agree with points, what happens when there are two different
>> ? ? ? access technologies?
>> 
>> Carlos ? problem of not knowing the other interface, it goes beyond
>> ? ? ? the scope of IETF, as we do not want to deal with Layer 2
>> 
>> Suresh - We are only trying to agree on what the problem is
>> 
>> Telemaco ? testing the scenarios, DHCP does not work.
>> 
>> Kent ? Not sure if single radio Vs multiple radio was discussed,
>> 
>> Sri ? Predictive handover will not network when there is single radio
>> 
>> Summary: Lot of discussion and issues related to single radio, dual
>> radio, lower layer information and how apps are bound to an interface
>> etc.
>> 
>> ....................
>> 
>> 5. Bulk re-registrations (Domagoj Premec)
>> I-D: draft-premec-netlmm-bulk-re-registration-02
>> 
>> - ? ? ? Comparison using 500000 MNs and 20 MAGs
>> - ? ? ? ML Discussion summary
>> - ? ? ? Issues with LMA Selection [ runtime selection functionality]
>> Kent, Sri: Support dynamic LMA selection ? good idea. ?Let?s talk
>> ? ? ?about re-registration solutions.
>> Hidetoshi ?Support
>> Jonne ? Support
>> 
>> ......................
>> 
>> 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen)
>> I-D: draft-korhonen-netext-redirect-ps-00
>> 
>> General consesus on the problem statement and support for doing this
>> work in Netext.
>> 
>> .....................
>> 
>> 7. Open discussion
>> 
>> Sri: Need document on intertechnology interface handover on multiple
>> ? ? interfaces
>> Hesham: Talking only about multihoming issues. How do you move PMIPv6
>> ? ? over interfaces? Can?t move.
>> Raj: That?s the problem we would like to solve; some people believe it is
>> ? ? solvable.
>> George: Be careful when you say it?s done. It may be done in a SDO but
>> ? ? it is not the same as in IETF.
>> DT: On the issue of multiple-interfaces, don?t move the the address
>> ? ? from interface to interface over ANs ? it can only move from
>> ? ? virtual interface to virtual interface.
>> James kempf: Local routing and such are good ideas.
>> Jari: With regards to multihoming and handover, agree that there is a
>> ? ? problem. Don?t have to solve in one way only
>> Vidya: multihoming within PMIP protocol ? PMIP was not chartered for
>> ? ? that. Multihoming/Handover cannot be solved without mobile node
>> ? ? involvement.
>> Parviz: Don?t like that we are coming to IETF with a solution
>> Speaker: Moving IP-addresses is not the right thing to do.
>> Sri: Let?s focuss on session continuity.
>> 
>> ................
>> 
>> Questions to the WG about various work items:
>> 
>> - Localized forwarding, bulk-registration, Runtime LMA selection ??
>> ?no controversy ?and consensus to work on these problems
>> 
>> - On the question about multihoming/flow mobility and,
>> ?inter-technology handovers there was a split about whether Netext
>> ?should extend PMIP6 with these features
>> 
>> Jari also asked a question about whether host based MIP6 should be
>> used as the means to address multihoming and intertechnology handovers
>> Vs PMIP6
>> ? There was again about equal support for enabling these features
>> ? using host based MIP6 vs using PMIP6.
>> 
>> More discussion on these features to be continued on the ML.
>> 
>> 
>> 
>> 
>> -Basavaraj
>> 
>> 
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Fri, 1 May 2009 17:11:05 +0100
Subject: [Netext] Netext BoF at IETF74: Meeting minutes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Funny, I kind of remember standing in front of that mic quit a lot but
according to this, I made exactly one comment during the entire BOF.

Maybe its my Greek accent :-)

George

On Fri, May 1, 2009 at 4:51 PM,  <Basavaraj.Patil at nokia.com> wrote:
>
>
> Network-based Mobility Extensions (NetExt) Bof
> THURSDAY, March 26, 2009
> 1300-1500 Afternoon Session I in Imperial A
>
> Bof chairs: Rajeev Koodli <rkoodli at starentnetworks dot com>
> ? ? ? ?Basavaraj Patil <basavaraj dot patil at nokia dot com>
>
> Acknowledgment for the meeting minutes:
> ? ?Samita Chakrabarti <samitac at ipinfusion dot com>
> ? ?Harsh Verma <harsh dot verma at rsystems dot com>
>
> -----------------------------------------------
>
> 1. Bof Overview and Scope - Chairs
>
> - Background ? Bar BoF discussion held at Dublin IETF , dinner meeting
> ? ? ? at IETF73, work on problem statements initiated
>
> - PMIP6 is one of the protocols for IP Mob management in emerging network
> ?architectures ?(LTE/SAE in 3GPP, Wimax)
>
> - A few improvements/deployment considerations need to be addressed
> ?? ? ? ? Multi-interface support
> ?? ? ? ? Localized routing
> ?? ? ? ? Inter-technology handovers
> - Objective today: Discuss if we have consensus w.r.t the proposed
> ?extensions to PMIP6 and whether to form a wg to work on the same
>
> - Ground rules:
> ?. Assume PMIP6 as the basis [ no MIP6 interaction]
> ?. Not a placeholder for all NETLMM related topis
>
> Hesham ? ?- Is that a realistic rule?
>
> Jari ? clarified that will take into account for new MIP6 features,
> ? ? but we already have a charter in the general WG.
>
> Jari - if we develop a new feature, it should not become harder or we
> ? ? should provide a mechanism. This WG will only deal with the problem
> ? ? but not provide a solution
>
> ? ? The intent here was that we are not going identify any new work
>
> Sri - Be careful of formulating Ground Rules
>
> Jari ? Interaction with MIP6
>
> Vijay ? had a comment on which is a concern that PMIP6 is still not a
> ? ? ?deployable protocol. There are still a few more items..
>
> Rajiv ? MN involvement is not the same as protocol-level changes.
> ?The question to ask is can we not design a protocol without host
> ?changes for the problem in question?
> ?What breaks and what doesn?t?
>
> Domagoj ? comment ? if something has to be done on the MN side, why
> ? ?can it not be taken care of
>
> Hesham ? No changes to the MN approach ? if we have to change it we
> ? ? ? will change it.
>
> Rajiv - We do not want to design disincentives. It is too early to say
> ? ? ?that host changes are needed.
>
> Jari ? If we have a proposal that allows us to do things, it will go
> ? ? into the charter and others will not.
>
> .....................
>
> 2. Multi-interface support for PMIP6 ( Vijay Deverapalli)
> I-D: draft-jeyatharan-netext-multihoming-ps-01
>
> -Using PMIP6 to specify multi-interface network mobility is under-specified.
> ? ? ? Scenario1 - setting up mobility sessions on demand: additional
> ? ? ? mobility session for a particular service
> ? ? ? Scenario 2 ? Flow mobility
> ? ? ? MN ?may bring up another interface is another access is
> ? ? ? available and then move some flows to the other interface for
> ? ? ? load balancing
> ? ? ? Scenario 3 : attachment to a new MAG and multi-interfaces of MN
> ? ? ? ? -- handover of sessions from if1 to if2 and MAG-old to
> ? ? ? MAG-new
>
> Parvez ? There are 3 different scenarios, but what about an MN
> ? ? ? attaching to multiple PDNs? Should it use the same address?
>
> Vijay ? different IP addresses for different interfaces
>
> Dave - Scenario 2: If the MN wants to move flows from one IF to the
> ? ? other, is the same IP address used on both interfaces??
>
> Sri ? If there are interfaces with a virtual node, it is possible.
>
> Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an
> ? ?extension to 5213 and 5213 does not prevent it
>
> Hesham ? This is not rocket science. It is not a new problem.
>
> Rajeev ? this is not a new protocol, but there are obviously
> ? ? ? implementation issues
>
> Hesham ? does not make any sense from the perspective of no MN changes
>
> Raj ? there may be things that could b done at another layer which
> ? ?could accomplish the same thing. We are not re-inventing a new
> ? ?protocol.
>
> Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be
> ? ? ?needed here?
>
> Vijay ? just to first see if there is a problem and can it be solved
> ? ? ?with an access service mechanism.
>
> Rajeev ? it could be a PDN, but this is for a new additional session
>
> ??? ? assign multiple
> ? ?Try to assign two interfaces, it does not work.
> ? ?Tricks people do to hide
>
> Rajeev ? it is difference between protocol and what you need to do for
> implementation
>
> ??? - ? ?It requires Mobile Intervention.
> ? ?Not sure if we can do this at IETF
>
> Kent ? Need a document what can change in implementation and what
> ? ? cannot be changed.
> ? ? Ans(Raj): We will look into that but the current BOF is to
> ? ? describe the problem
>
> Raj ? we will have to deal
>
> Dave ? Are we talking about changes to some proprietary info about MN
> ? ? or dependencies of RFCs?
>
> Sri ? Would you consider? Dave ? there is no RFC
>
> Jabber - Vidya says that we do not want to modify MN in any way to
> ? ? ? support this feature
>
> ........................
>
> 3. PMIPv6 localized routing (Marco Liebsch)
> I-D: draft-liebsch-netext-pmip6-ro-ps-00
>
> Obj: establish and maintain forwarding data for two MNs (during
> ? ? handovers) without going through MN?s LMA. Fundamental difference
> ? ? to host mobility, such as MIPv6 RO.
>
> MNs have no control on setting up localized routes is correct
>
> Discussion ?
>
> Kent ? Are Handovers also covered in Detection and Setup
> ? ?When you are doing Handover, you want to establish and
> ? ?maintain the optimized routing.
> ? ?Is the scope MAG to MAG or LMA to LMA?
>
>
> Raj ? the base spec allows you to do Localized Routing
>
> Marco ? if you handle everything locally
>
> Carlos ? use of EnableMAGLocalRouting Flag within the scope of the
> ? ? ? work should be clarified. We are only assuming PMIP MNs. This Flag is
> ? ? ? used for optimizing between a PMIP and regular host.
>
> Sri ? No, this is not so.
>
> Sri ? Is the focus on lack of signaling?
>
> Parvez - Should send an email on his point
> Raj ? granularity of localized routing may be discussed
>
> ??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4
> ? ?address. So it is ?possible.
>
> Rajeev ? the flow can be between any two end-points and not restricted
> ? ? ? to hosts that are PMIP6 MNs only
>
> ....................
>
> 4. Inter technology handovers (Suresh Krishnan)
> I-D: draft-krishnan-netext-intertech-ps-00
>
> See slides for PS overview.
>
> Discussion
> Chan Wah ? What is the timeframe for Predictive Handovers?
>
> Suresh ? Does not matter, can be a second or a day
>
> Suresh ? Access Network may be separate from Mobility Provider.
>
> Sri ? Implementation Specific Issues ? is Prefix an issue?
> ? ?If we move to a new prefix, the app will break
> ? ?Let?s say we have a Virtual Interface sitting on top of two
> ? ?physical interfaces
>
> Hesham ? agree with points, what happens when there are two different
> ? ? ? access technologies?
>
> Carlos ? problem of not knowing the other interface, it goes beyond
> ? ? ? the scope of IETF, as we do not want to deal with Layer 2
>
> Suresh - We are only trying to agree on what the problem is
>
> Telemaco ? testing the scenarios, DHCP does not work.
>
> Kent ? Not sure if single radio Vs multiple radio was discussed,
>
> Sri ? Predictive handover will not network when there is single radio
>
> Summary: Lot of discussion and issues related to single radio, dual
> radio, lower layer information and how apps are bound to an interface
> etc.
>
> ....................
>
> 5. Bulk re-registrations (Domagoj Premec)
> I-D: draft-premec-netlmm-bulk-re-registration-02
>
> - ? ? ? Comparison using 500000 MNs and 20 MAGs
> - ? ? ? ML Discussion summary
> - ? ? ? Issues with LMA Selection [ runtime selection functionality]
> Kent, Sri: Support dynamic LMA selection ? good idea. ?Let?s talk
> ? ? ?about re-registration solutions.
> Hidetoshi ?Support
> Jonne ? Support
>
> ......................
>
> 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen)
> I-D: draft-korhonen-netext-redirect-ps-00
>
> General consesus on the problem statement and support for doing this
> work in Netext.
>
> .....................
>
> 7. Open discussion
>
> Sri: Need document on intertechnology interface handover on multiple
> ? ? interfaces
> Hesham: Talking only about multihoming issues. How do you move PMIPv6
> ? ? over interfaces? Can?t move.
> Raj: That?s the problem we would like to solve; some people believe it is
> ? ? solvable.
> George: Be careful when you say it?s done. It may be done in a SDO but
> ? ? it is not the same as in IETF.
> DT: On the issue of multiple-interfaces, don?t move the the address
> ? ? from interface to interface over ANs ? it can only move from
> ? ? virtual interface to virtual interface.
> James kempf: Local routing and such are good ideas.
> Jari: With regards to multihoming and handover, agree that there is a
> ? ? problem. Don?t have to solve in one way only
> Vidya: multihoming within PMIP protocol ? PMIP was not chartered for
> ? ? that. Multihoming/Handover cannot be solved without mobile node
> ? ? involvement.
> Parviz: Don?t like that we are coming to IETF with a solution
> Speaker: Moving IP-addresses is not the right thing to do.
> Sri: Let?s focuss on session continuity.
>
> ................
>
> Questions to the WG about various work items:
>
> - Localized forwarding, bulk-registration, Runtime LMA selection ??
> ?no controversy ?and consensus to work on these problems
>
> - On the question about multihoming/flow mobility and,
> ?inter-technology handovers there was a split about whether Netext
> ?should extend PMIP6 with these features
>
> Jari also asked a question about whether host based MIP6 should be
> used as the means to address multihoming and intertechnology handovers
> Vs PMIP6
> ? There was again about equal support for enabling these features
> ? using host based MIP6 vs using PMIP6.
>
> More discussion on these features to be continued on the ML.
>
>
>
>
> -Basavaraj
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Fri, 1 May 2009 17:51:53 +0200
Subject: [Netext] Netext BoF at IETF74: Meeting minutes
Message-ID: <[email-masked]>

Network-based Mobility Extensions (NetExt) Bof
THURSDAY, March 26, 2009
1300-1500 Afternoon Session I in Imperial A

Bof chairs: Rajeev Koodli <rkoodli at starentnetworks dot com>
        Basavaraj Patil <basavaraj dot patil at nokia dot com>

Acknowledgment for the meeting minutes:
    Samita Chakrabarti <samitac at ipinfusion dot com>
    Harsh Verma <harsh dot verma at rsystems dot com>

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

1. Bof Overview and Scope - Chairs

- Background ? Bar BoF discussion held at Dublin IETF , dinner meeting
       at IETF73, work on problem statements initiated

- PMIP6 is one of the protocols for IP Mob management in emerging network
  architectures  (LTE/SAE in 3GPP, Wimax)
 
- A few improvements/deployment considerations need to be addressed
  ?       Multi-interface support
  ?       Localized routing
  ?       Inter-technology handovers
- Objective today: Discuss if we have consensus w.r.t the proposed
  extensions to PMIP6 and whether to form a wg to work on the same

- Ground rules:
  . Assume PMIP6 as the basis [ no MIP6 interaction]
  . Not a placeholder for all NETLMM related topis

Hesham    - Is that a realistic rule?
    
Jari ? clarified that will take into account for new MIP6 features,
     but we already have a charter in the general WG.

Jari - if we develop a new feature, it should not become harder or we
     should provide a mechanism. This WG will only deal with the problem
     but not provide a solution

     The intent here was that we are not going identify any new work

Sri - Be careful of formulating Ground Rules
    
Jari ? Interaction with MIP6

Vijay ? had a comment on which is a concern that PMIP6 is still not a
      deployable protocol. There are still a few more items..

Rajiv ? MN involvement is not the same as protocol-level changes.
 The question to ask is can we not design a protocol without host
 changes for the problem in question?
 What breaks and what doesn?t?

Domagoj ? comment ? if something has to be done on the MN side, why
    can it not be taken care of

Hesham ? No changes to the MN approach ? if we have to change it we
       will change it.

Rajiv - We do not want to design disincentives. It is too early to say
      that host changes are needed.

Jari ? If we have a proposal that allows us to do things, it will go
     into the charter and others will not.

.....................

2. Multi-interface support for PMIP6 ( Vijay Deverapalli)
I-D: draft-jeyatharan-netext-multihoming-ps-01

-Using PMIP6 to specify multi-interface network mobility is under-specified.
       Scenario1 - setting up mobility sessions on demand: additional
       mobility session for a particular service
       Scenario 2 ? Flow mobility
       MN  may bring up another interface is another access is
       available and then move some flows to the other interface for
       load balancing
       Scenario 3 : attachment to a new MAG and multi-interfaces of MN
         -- handover of sessions from if1 to if2 and MAG-old to
       MAG-new

Parvez ? There are 3 different scenarios, but what about an MN
       attaching to multiple PDNs? Should it use the same address?

Vijay ? different IP addresses for different interfaces

Dave - Scenario 2: If the MN wants to move flows from one IF to the
     other, is the same IP address used on both interfaces??

Sri ? If there are interfaces with a virtual node, it is possible.

Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an
    extension to 5213 and 5213 does not prevent it

Hesham ? This is not rocket science. It is not a new problem.

Rajeev ? this is not a new protocol, but there are obviously
       implementation issues

Hesham ? does not make any sense from the perspective of no MN changes

Raj ? there may be things that could b done at another layer which
    could accomplish the same thing. We are not re-inventing a new
    protocol. 

Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be
      needed here?

Vijay ? just to first see if there is a problem and can it be solved
      with an access service mechanism.

Rajeev ? it could be a PDN, but this is for a new additional session

??? ? assign multiple
    Try to assign two interfaces, it does not work.
    Tricks people do to hide

Rajeev ? it is difference between protocol and what you need to do for
implementation

??? -    It requires Mobile Intervention.
    Not sure if we can do this at IETF

Kent ? Need a document what can change in implementation and what
     cannot be changed.
     Ans(Raj): We will look into that but the current BOF is to
     describe the problem

Raj ? we will have to deal

Dave ? Are we talking about changes to some proprietary info about MN
     or dependencies of RFCs?

Sri ? Would you consider? Dave ? there is no RFC

Jabber - Vidya says that we do not want to modify MN in any way to
       support this feature

........................

3. PMIPv6 localized routing (Marco Liebsch)
I-D: draft-liebsch-netext-pmip6-ro-ps-00

Obj: establish and maintain forwarding data for two MNs (during
     handovers) without going through MN?s LMA. Fundamental difference
     to host mobility, such as MIPv6 RO.

MNs have no control on setting up localized routes is correct

Discussion ? 

Kent ? Are Handovers also covered in Detection and Setup
    When you are doing Handover, you want to establish and
    maintain the optimized routing.
    Is the scope MAG to MAG or LMA to LMA?

Raj ? the base spec allows you to do Localized Routing

Marco ? if you handle everything locally

Carlos ? use of EnableMAGLocalRouting Flag within the scope of the
       work should be clarified. We are only assuming PMIP MNs. This Flag is
       used for optimizing between a PMIP and regular host.

Sri ? No, this is not so.
    
Sri ? Is the focus on lack of signaling?

Parvez - Should send an email on his point
Raj ? granularity of localized routing may be discussed

??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4
    address. So it is  possible.

Rajeev ? the flow can be between any two end-points and not restricted
       to hosts that are PMIP6 MNs only

....................

4. Inter technology handovers (Suresh Krishnan)
I-D: draft-krishnan-netext-intertech-ps-00

See slides for PS overview.

Discussion
Chan Wah ? What is the timeframe for Predictive Handovers?

Suresh ? Does not matter, can be a second or a day

Suresh ? Access Network may be separate from Mobility Provider.

Sri ? Implementation Specific Issues ? is Prefix an issue?
    If we move to a new prefix, the app will break
    Let?s say we have a Virtual Interface sitting on top of two
    physical interfaces

Hesham ? agree with points, what happens when there are two different
       access technologies?

Carlos ? problem of not knowing the other interface, it goes beyond
       the scope of IETF, as we do not want to deal with Layer 2

Suresh - We are only trying to agree on what the problem is

Telemaco ? testing the scenarios, DHCP does not work.

Kent ? Not sure if single radio Vs multiple radio was discussed,

Sri ? Predictive handover will not network when there is single radio

Summary: Lot of discussion and issues related to single radio, dual
radio, lower layer information and how apps are bound to an interface
etc. 

....................

5. Bulk re-registrations (Domagoj Premec)
I-D: draft-premec-netlmm-bulk-re-registration-02

-       Comparison using 500000 MNs and 20 MAGs
-       ML Discussion summary
-       Issues with LMA Selection [ runtime selection functionality]
Kent, Sri: Support dynamic LMA selection ? good idea.  Let?s talk
      about re-registration solutions.
Hidetoshi ?Support
Jonne ? Support

......................

6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen)
I-D: draft-korhonen-netext-redirect-ps-00

General consesus on the problem statement and support for doing this
work in Netext.

.....................

7. Open discussion

Sri: Need document on intertechnology interface handover on multiple
     interfaces 
Hesham: Talking only about multihoming issues. How do you move PMIPv6
     over interfaces? Can?t move.
Raj: That?s the problem we would like to solve; some people believe it is
     solvable. 
George: Be careful when you say it?s done. It may be done in a SDO but
     it is not the same as in IETF.
DT: On the issue of multiple-interfaces, don?t move the the address
     from interface to interface over ANs ? it can only move from
     virtual interface to virtual interface.
James kempf: Local routing and such are good ideas.
Jari: With regards to multihoming and handover, agree that there is a
     problem. Don?t have to solve in one way only
Vidya: multihoming within PMIP protocol ? PMIP was not chartered for
     that. Multihoming/Handover cannot be solved without mobile node
     involvement. 
Parviz: Don?t like that we are coming to IETF with a solution
Speaker: Moving IP-addresses is not the right thing to do.
Sri: Let?s focuss on session continuity.

................

Questions to the WG about various work items:

- Localized forwarding, bulk-registration, Runtime LMA selection  ?
  no controversy  and consensus to work on these problems

- On the question about multihoming/flow mobility and,
  inter-technology handovers there was a split about whether Netext
  should extend PMIP6 with these features

Jari also asked a question about whether host based MIP6 should be
used as the means to address multihoming and intertechnology handovers
Vs PMIP6
   There was again about equal support for enabling these features
   using host based MIP6 vs using PMIP6.

More discussion on these features to be continued on the ML.

-Basavaraj

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Fri, 1 May 2009 07:15:54 -0700 (PDT)
Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This link is not broken, it is OK now.

________________________________
From: Jeon Seil <sijeon79 at gmail.com>
To: netext at mail.mobileip.jp
Sent: Friday, May 1, 2009 2:13:14 AM
Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting

Hi.. NETEXT folks... I''ve just subscribed this mailing list.

Due to this link is broken (https://datatracker.ietf.org/meeting/74/materials.html)

I need all NETEXT related PPT?materials discussed in 74th IETF 

Thank you..

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090501/7b64392a/attachment.html>

From: sijeon79 at gmail.com (Jeon Seil)
Date: Fri, 1 May 2009 16:13:14 +0900
Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting
Message-ID: <[email-masked]>

Hi.. NETEXT folks.. I''ve just subscribed this mailing list.

Due to this link is broken (
https://datatracker.ietf.org/meeting/74/materials.html)

I need all NETEXT related PPT materials discussed in 74th IETF

Thank you..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090501/3170fd05/attachment.html>