Subject: [Netext] <Adv> New Course "Leading Cooperative Teams" 8-9 Jun 09
From: admin at uknowledge.com (United Knowledge Pte Ltd)
Date: Tue, 28 Apr 2009 22:23:32 +0800

To All Professional

1 Additional Seats Free for each Participant Registered before  28 May 09         See Attached Flyer.

Leading Cooperative Teams

Enhancing Trust and Collaboration at the Workplace
 
by Dr Celeste Brody, PhD,     8-9 Jun 09  or  14-15 Sep 09,  S$880 

1 Additional Seats Free for each Participant Registered before  28 May 09 
Venue :   PSB Academy (Henderson Campus)   Tentative(To-Be-Confirmed)

Best Regards, 
Joanne Ng, Tel (65) 6546 5801 
United Knowledge Pte Ltd   23 Loyang View,  Singapore 507247
joanne at uknowledge.com

To UnSubscribe,  simply reply to this email with Subject : UnSubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090428/84c472d3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3523 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090428/84c472d3/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flyer_CooperativeTeams.pdf
Type: application/pdf
Size: 79474 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090428/84c472d3/attachment-0001.pdf>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 23 Apr 2009 23:32:47 +0300
Subject: [Netext] WG status
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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.
>
> 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 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 2009 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
>
> _______________________________________________
> 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: Thu, 23 Apr 2009 21:33:58 +0200
Subject: [Netext] Second draft version of the charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

The proposed charter is okay to proceed with from the perspective of seeking
IESG approval.  

The only thing that I would like to suggest modifying in terms of the
proposed charter is the ability to add new work items  (some of which are
currently being debated and we hope to arrive at some conclusion in the next
few weeks) without having to go through a rechartering process.

The statement:
" The addition of such new extensions to the working group involves addition
of the extension to this charter through the normal rechartering process."
is to a certain degree limiting the flexibility. The rechartering process in
general can be a pretty length and exhaustive exercise in the IETF. If the
WG members conclude that an extension is necessary and it does not modify
the fundamental principles of the protocol and does no harm, then the WG
should be able to add the work item to the charter with just AD approval.

Maybe one possibility in terms of the work items that are not agreed upon
and can be captured in the charter proposal itself is as follows:
"The Netext WG will debate and conclude whether PMIP6 enhancements for
multihoming, flow mobility and inter-technology handovers will be developed
by the WG. Depending on the outcome the WG may add these work items to the
list of deliverables without a rechartering process."

-Raj

On 4/23/09 9:00 AM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:

> 
> 
> This is a slight edit of what I proposed, with small edits based on
> comments from Gerardo.
> 
> There has been a few comments back and forth about the last paragraph
> but for now I intend to keep it in slightly modified form.
> 
> I have not seen major screaming about my previous draft version, so
> I am  planning to move forward in tonight's IESG call.
> 
> 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.
> 
> 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 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 2009 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 23 Apr 2009 17:00:50 +0300
Subject: [Netext] Second draft version of the charter
Message-ID: <[email-masked]>

This is a slight edit of what I proposed, with small edits based on
comments from Gerardo.

There has been a few comments back and forth about the last paragraph
but for now I intend to keep it in slightly modified form.

I have not seen major screaming about my previous draft version, so
I am  planning to move forward in tonight's IESG call.

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.

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 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 2009 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: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 23 Apr 2009 16:55:58 +0300
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Yungui Wang wrote:
> Hello Jari
>
> Yeah, of course you are right that 'MIF does not rely on Mobile IPv6 
> or Proxy version thereof'. 
> I just want to view it from side of PMIP domain. Such as, there is
> a valid requirement/scenario that a certain multiple interface
> capable node, which maybe can't enable traffic flow handover 
> between interfaces but needed, is located in the PMIP domain. 
> Next step will be how to do in PMIP domain. Thus, I'd like to 
> propose its working item into Netext charter, not to MIF charter. 
> >From requirement/scenario to working item, in my understanding, 
> that's a general process in IETF.
>   

Ok. I think this does fall under the category that we are already 
discussing, the multihoming and inter-access handover support in PMIP. I 
realize your issue is looking at it from a different aspect, but it is 
still part of the same overall problem area. Please propose some 
concrete work item.

Jari

> Also I have seen that debate at before. The opposed voices 
> are similarly solution-based, e.g. existing MIP multihoming 
> works, unmodified-host, etc. I won't join in. 
> However, could you tell me how to deal with above 
> requirement/scenario?
>
> Thanks.
> Yungui
>
>
>   
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko at piuha.net] 
>> Sent: Wednesday, April 22, 2009 11:57 PM
>> To: w52006 at huawei.com
>> Cc: netext at mail.mobileip.jp
>> Subject: Re: [Netext] Draft revision of the NETEXT charter
>>
>> Yungui,
>>
>>     
>>> I am concerning of how MIF capable node works in PMIP domain.
>>> In the charter of MIF, there is a paragraph described as below:
>>> "...The group shall not assume any
>>> software beyond basic IP protocol support on its peers or in network
>>> nodes. No work will be done to enable traffic flows to move from one
>>> interface to another. The group recognizes existing work on 
>>>       
>> mechanisms
>>     
>>> that require peer or network support for moving traffic 
>>>       
>> flows such as
>>     
>>> RFC 5206, RFC 4980 and the use of multiple care-of 
>>>       
>> addresses in Mobile
>>     
>>> IPv6. This group does not work on or impact such mechanisms.  ..."
>>>
>>> That's, MIF capable node is dependent on network to provide 
>>>       
>> traffic flows 
>>     
>>> moving among interfaces.
>>>       
>> No, maybe this is a misunderstanding. MIF is really not assuming 
>> anything like that happening. The charter text simply notes that such 
>> work exists and that its not MIF WG's place to develop those further.
>>
>>     
>>>  However, how to do traffic flows handover 
>>> between interfaces in PMIP domain is not described. If MIF 
>>>       
>> capable node
>>     
>>> is located in PMIP domain, then this feature will be disable. 
>>> I am wondering if/when these works will be done in Netext(PMIP).
>>> Some PS and I-D had stated these issues as below.
>>>
>>>       
>> http://tools.ietf.org/html/draft-devarapalli-netext-multi-inte
>> rface-support-
>>     
>>> 00
>>> http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
>>> http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
>>> http://tools.ietf.org/html/draft-koodli-flow-handover-00
>>> Thus, personally propose this working item is included in 
>>>       
>> the charter 
>>     
>>> and making things progress. Thanks.
>>>   
>>>       
>> The MIF charter did not mention PMIP specifically, but the 
>> list was not 
>> intended to be complete. Multiple care-of address work in 
>> Mobile IPv6 is 
>> already being standardized, and PMIP multihoming is under 
>> consideration 
>> (currently heavily debated).
>>
>> In any case, MIF does not rely on Mobile IPv6 or Proxy 
>> version thereof. 
>> Those efforts are proceeding independently.
>>
>> Jari
>>
>>     
>
>
>
>   

From: w52006 at huawei.com (Yungui Wang)
Date: Thu, 23 Apr 2009 09:52:54 +0800
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Jari

Yeah, of course you are right that 'MIF does not rely on Mobile IPv6 
or Proxy version thereof'. 
I just want to view it from side of PMIP domain. Such as, there is
a valid requirement/scenario that a certain multiple interface
capable node, which maybe can't enable traffic flow handover 
between interfaces but needed, is located in the PMIP domain. 
Next step will be how to do in PMIP domain. Thus, I'd like to 
propose its working item into Netext charter, not to MIF charter. 
>From requirement/scenario to working item, in my understanding, 
that's a general process in IETF.

Also I have seen that debate at before. The opposed voices 
are similarly solution-based, e.g. existing MIP multihoming 
works, unmodified-host, etc. I won't join in. 
However, could you tell me how to deal with above 
requirement/scenario?

Thanks.
Yungui

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko at piuha.net] 
> Sent: Wednesday, April 22, 2009 11:57 PM
> To: w52006 at huawei.com
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] Draft revision of the NETEXT charter
> 
> Yungui,
> 
> > I am concerning of how MIF capable node works in PMIP domain.
> > In the charter of MIF, there is a paragraph described as below:
> > "...The group shall not assume any
> > software beyond basic IP protocol support on its peers or in network
> > nodes. No work will be done to enable traffic flows to move from one
> > interface to another. The group recognizes existing work on 
> mechanisms
> > that require peer or network support for moving traffic 
> flows such as
> > RFC 5206, RFC 4980 and the use of multiple care-of 
> addresses in Mobile
> > IPv6. This group does not work on or impact such mechanisms.  ..."
> >
> > That's, MIF capable node is dependent on network to provide 
> traffic flows 
> > moving among interfaces.
> 
> No, maybe this is a misunderstanding. MIF is really not assuming 
> anything like that happening. The charter text simply notes that such 
> work exists and that its not MIF WG's place to develop those further.
> 
> >  However, how to do traffic flows handover 
> > between interfaces in PMIP domain is not described. If MIF 
> capable node
> > is located in PMIP domain, then this feature will be disable. 
> > I am wondering if/when these works will be done in Netext(PMIP).
> > Some PS and I-D had stated these issues as below.
> > 
> http://tools.ietf.org/html/draft-devarapalli-netext-multi-inte
> rface-support-
> > 00
> > http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
> > http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
> > http://tools.ietf.org/html/draft-koodli-flow-handover-00
> > Thus, personally propose this working item is included in 
> the charter 
> > and making things progress. Thanks.
> >   
> 
> The MIF charter did not mention PMIP specifically, but the 
> list was not 
> intended to be complete. Multiple care-of address work in 
> Mobile IPv6 is 
> already being standardized, and PMIP multihoming is under 
> consideration 
> (currently heavily debated).
> 
> In any case, MIF does not rely on Mobile IPv6 or Proxy 
> version thereof. 
> Those efforts are proceeding independently.
> 
> Jari
> 

From: jari.arkko at piuha.net (Jari Arkko)
Date: Wed, 22 Apr 2009 17:57:25 +0200
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Yungui,

> I am concerning of how MIF capable node works in PMIP domain.
> In the charter of MIF, there is a paragraph described as below:
> "...The group shall not assume any
> software beyond basic IP protocol support on its peers or in network
> nodes. No work will be done to enable traffic flows to move from one
> interface to another. The group recognizes existing work on mechanisms
> that require peer or network support for moving traffic flows such as
> RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile
> IPv6. This group does not work on or impact such mechanisms.  ..."
>
> That's, MIF capable node is dependent on network to provide traffic flows 
> moving among interfaces.

No, maybe this is a misunderstanding. MIF is really not assuming 
anything like that happening. The charter text simply notes that such 
work exists and that its not MIF WG's place to develop those further.

>  However, how to do traffic flows handover 
> between interfaces in PMIP domain is not described. If MIF capable node
> is located in PMIP domain, then this feature will be disable. 
> I am wondering if/when these works will be done in Netext(PMIP).
> Some PS and I-D had stated these issues as below.
> http://tools.ietf.org/html/draft-devarapalli-netext-multi-interface-support-
> 00
> http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
> http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
> http://tools.ietf.org/html/draft-koodli-flow-handover-00
> Thus, personally propose this working item is included in the charter 
> and making things progress. Thanks.
>   

The MIF charter did not mention PMIP specifically, but the list was not 
intended to be complete. Multiple care-of address work in Mobile IPv6 is 
already being standardized, and PMIP multihoming is under consideration 
(currently heavily debated).

In any case, MIF does not rely on Mobile IPv6 or Proxy version thereof. 
Those efforts are proceeding independently.

Jari

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 22 Apr 2009 08:34:48 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Teemu,

On Wed, 22 Apr 2009, teemu.savolainen at nokia.com wrote:

> Hi Sri,
>
> Sorry for even longer delay. I believe we are in sync, so no other comments. Would the "We can always state our requirements on the host.." take a form of Informational/BCP document?
>

As you know, this topic on host requirements is being discussed. We
have to agree upon the following:

- MN notifying the attachment and handover preferences to the network,
   here the events are clear per 5213
- And additionally any flow specific preferences, if we converge on the
   new extensions
- The type of interface for this layer to achieve this and that
   determines how we specify our requirements, informative or in a
   standards track doc.

Regards
Sri

> Best regards,
>
> 	Teemu
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 16 April, 2009 00:14
>> To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>> Cc: Patil Basavaraj (Nokia-D/Dallas); netext at mail.mobileip.jp
>> Subject: RE: [Netext] next steps for netext
>>
>> Hi Teemu,
>>
>> Sorry for the delayed response. Please see inline.
>>
>>>
>>> There are many OS'es, some of which are proprietary and/or
>> used in embedded and/or strongly controlled devices - in such
>> cases it may not be possible just to run a tool or just
>> install application to do the trick even if the device is
>> based on open OS (and especially not by the end users of those
>> systems). These kinds of devices are pretty common in some
>> environments where PMIP6 is planned to be used.. Support for
>> PMIP6 based inter-access handovers would definitely be
>> considered as a change that would need to be justified,
>> implemented, and verified.
>>>
>>
>> You make good points. I agree with you and Domagoj that to be
>> able to say we have a complete solution for inter-tech
>> handoffs, there has to be some support from the host. As you
>> earlier put it, the solution has to assume few things on the
>> host, with respect configuration or might require some special
>> application support. But, before we call it a "host change",
>> lets make sure we certainly require changes to 4861 or other
>> IETF specs, as that appears to be the definition of "host
>> change", in the absence of a standard definition of "standard
>> host". We can always state our requirements on the host for
>> supporting  a given feature and move on.
>>
>> A solution such as a using virtual interface, to most part,
>> allows the host to be able to perform handoffs, between
>> interfaces. Should not be an issue. However, we might still
>> require the following, that may qualify as a "host change",
>> but depends on how the solution is built.
>>
>> - Handoff hint exchange between the network and the host. Notifying
>>   the purpose of a given attachment, handoff vs new attachment.
>>
>> - For flow management, network and the host being in sync w.r.t to
>>   what flows are being moved around.
>>
>> - Connection Manager, a common component which cant be avoided, CMIP
>>   or PMIP.
>>
>> As you pointed out to your docs, broadly the above
>> requirements should be sufficient. May be MN-AR interface doc
>> would have helped here, but we killed it.
>>
>>
>>> From my perspective the L2 changes are not very feasible approach:
>>> existing L$
>>
>> Depends on how we build that interface layer. May be an
>> application interface, or some minimal extensions to ND
>> options, need not be
>> L2 change.
>>
>>
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>> In the context of IETF - and wider - discussion, I have been
>> concerned about the message I often hear: that PMIP6 would not
>> require host changes for inter-access mobility. The problem is
>> that some actually read that message literally.
>>>
>>> In
>> http://tools.ietf.org/html/draft-premec-netlmm-intertech-handov
>> er-01 we describe at least some of the impacts (with also
>> solution considerations & proposals):
>>> - multihoming & handoffs (when the address should be moved from one
>>> access to another, when to ask for different address for different
>>> access, when to have same address on multiple accesses simultanously
>>> and also have mechahisms for flow distribution)
>>> - overlapping IPv4 address spaces (how to know if 192.168.0.1 on two
>>> interfaces is logically the same or different address)
>>> - different MTUs
>>> - zero physical interface situation (i.e. the transition period when
>>> old access goes away and before the new access comes available)
>>>
>>> From my perspective the L2 changes are not very feasible
>> approach: existing L2s would need to be changed (=very
>> difficult to get done), and future L2 developers would also
>> need to take care of this dependency. It is easier to handle
>> mobility for IP at L3.
>>>
>>> Some people have been concerned on interoperability, but I
>> don't think that is an issue: the hosts that would not
>> implement suggested host changes (virtual interfaces, possibly
>> required L3 signaling for advanced handoff scenarios) would
>> work just as they do if they don't support client mobile IP
>> either - they simply do not get seamless inter-technology
>> handovers, but will need to manage with application level
>> reconnection/multihoming techniques.
>>>
>>> Best regards,
>>>
>>> 	Teemu
>>

From: teemu.savolainen at nokia.com (teemu.savolainen at nokia.com)
Date: Wed, 22 Apr 2009 15:24:28 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,

Sorry for even longer delay. I believe we are in sync, so no other comments. Would the "We can always state our requirements on the host.." take a form of Informational/BCP document?

Best regards,

	Teemu 

>-----Original Message-----
>From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
>Sent: 16 April, 2009 00:14
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: Patil Basavaraj (Nokia-D/Dallas); netext at mail.mobileip.jp
>Subject: RE: [Netext] next steps for netext
>
>Hi Teemu,
>
>Sorry for the delayed response. Please see inline.
>
>>
>> There are many OS'es, some of which are proprietary and/or 
>used in embedded and/or strongly controlled devices - in such 
>cases it may not be possible just to run a tool or just 
>install application to do the trick even if the device is 
>based on open OS (and especially not by the end users of those 
>systems). These kinds of devices are pretty common in some 
>environments where PMIP6 is planned to be used.. Support for 
>PMIP6 based inter-access handovers would definitely be 
>considered as a change that would need to be justified, 
>implemented, and verified.
>>
>
>You make good points. I agree with you and Domagoj that to be 
>able to say we have a complete solution for inter-tech 
>handoffs, there has to be some support from the host. As you 
>earlier put it, the solution has to assume few things on the 
>host, with respect configuration or might require some special 
>application support. But, before we call it a "host change", 
>lets make sure we certainly require changes to 4861 or other 
>IETF specs, as that appears to be the definition of "host 
>change", in the absence of a standard definition of "standard 
>host". We can always state our requirements on the host for 
>supporting  a given feature and move on.
>
>A solution such as a using virtual interface, to most part, 
>allows the host to be able to perform handoffs, between 
>interfaces. Should not be an issue. However, we might still 
>require the following, that may qualify as a "host change", 
>but depends on how the solution is built.
>
>- Handoff hint exchange between the network and the host. Notifying
>   the purpose of a given attachment, handoff vs new attachment.
>
>- For flow management, network and the host being in sync w.r.t to
>   what flows are being moved around.
>
>- Connection Manager, a common component which cant be avoided, CMIP
>   or PMIP.
>
>As you pointed out to your docs, broadly the above 
>requirements should be sufficient. May be MN-AR interface doc 
>would have helped here, but we killed it.
>
>
>> From my perspective the L2 changes are not very feasible approach: 
>> existing L$
>
>Depends on how we build that interface layer. May be an 
>application interface, or some minimal extensions to ND 
>options, need not be
>L2 change.
>
>
>
>
>Regards
>Sri
>
>
>
>
>
>
>
>
>> In the context of IETF - and wider - discussion, I have been 
>concerned about the message I often hear: that PMIP6 would not 
>require host changes for inter-access mobility. The problem is 
>that some actually read that message literally.
>>
>> In 
>http://tools.ietf.org/html/draft-premec-netlmm-intertech-handov
>er-01 we describe at least some of the impacts (with also 
>solution considerations & proposals):
>> - multihoming & handoffs (when the address should be moved from one 
>> access to another, when to ask for different address for different 
>> access, when to have same address on multiple accesses simultanously 
>> and also have mechahisms for flow distribution)
>> - overlapping IPv4 address spaces (how to know if 192.168.0.1 on two 
>> interfaces is logically the same or different address)
>> - different MTUs
>> - zero physical interface situation (i.e. the transition period when 
>> old access goes away and before the new access comes available)
>>
>> From my perspective the L2 changes are not very feasible 
>approach: existing L2s would need to be changed (=very 
>difficult to get done), and future L2 developers would also 
>need to take care of this dependency. It is easier to handle 
>mobility for IP at L3.
>>
>> Some people have been concerned on interoperability, but I 
>don't think that is an issue: the hosts that would not 
>implement suggested host changes (virtual interfaces, possibly 
>required L3 signaling for advanced handoff scenarios) would 
>work just as they do if they don't support client mobile IP 
>either - they simply do not get seamless inter-technology 
>handovers, but will need to manage with application level 
>reconnection/multihoming techniques.
>>
>> Best regards,
>>
>> 	Teemu
>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Wed, 22 Apr 2009 12:34:56 +0300
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,

Some answer inline.

On Apr 22, 2009, at 11:58 AM, Yungui Wang wrote:

>
> Hi Jouni
>
> Please see inline...
>
>> -----Original Message-----
>> From: jouni korhonen [mailto:jouni.nospam at gmail.com]
>> Sent: Wednesday, April 22, 2009 2:56 PM
>> To: w52006 at huawei.com
>> Cc: 'Sri Gundavelli'; 'Vijay Devarapalli';
>> jouni.korhonen at nsn.com; netext at mail.mobileip.jp
>> Subject: Re: [Netext] LMA redirection (was RE: WG Review:
>> Network-Based MobilityExtensions (netext))
>>
>> Hi Yungui,
>>
>>
>> On Apr 22, 2009, at 5:47 AM, Yungui Wang wrote:
>>
>>> Hello Sri
>>>
>>>> Jouni's document is trying to provide a solution with the following
>>>> goals in mind:
>>>>
>>>> - Expose a single address for the entire LMA infrastructure
>>>
>>> What is the actual meaning here?
>>> In my understanding, MAG always knows the r2LMA address after
>>> PBA is received. Do you mean exposing a single address to AAA
>>> server or other? In practice, e.g. as 3GPP TS23.402 described,
>>> after PBU/PBA (reg or de-reg) processing is completed, r2LMA
>>> address et. information should be informed to HSS/AAA.
>>
>> Say, you have a number of LMA clusters (each cluster has e.g. 10
>> LMAs). Still, each individual LMA has one or more IP address. For a
>> generic LMA discovery you would only expose one rfLMA addresses per
>> cluster e.g. through DNS.  After the redirection the MAG would
>> communicate directly with the assigned r2LMA in some cluster.
>>
>
> Please see my previous mail to Sri.
> In my mind, the point 'Expose a single address for the entire LMA
> infrastructure' is not highlighted.

Righty. Currently this is somewhat vaguely said there. That is  
highlighted more to some extent in the next revision of the solution I- 
D. Once I get it submitted ;)

Anyway, how many addresses shall or will be exposed is always  
dependent on the deployment and operator configuration.

>
>>> Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
>>> redirection or overload indirection, or LMA address list from FQDN)
>>> is a good choice, at least for scenario of each LMA is separate box.
>>> This is because,
>>> on the one hand, each LMA neither needs explicit mobility
>>> management signaling to other, nor needs to know other's load info
>>> due to load info is a integrative and complex value (e.g. CPU 75%
>>> is overloading for one LMA, but not for another).
>>> on the other hand, it is consistent with basis LMA discovery
>>> mechanism.
>>
>> I don't think there needs to be any mobility signaling between LMAs.
>
> In this draft, when rfLMA redirect the MAG to a r2LMA, doesn't
> the rfLMA forward the request(PBU) to the r2LMA?

The current text in section 5.2. surface this topic and state it is  
out of scope of this specification. I guess we need to have some more  
text there but I really don't see a reason to define how rfLMA and  
r2LMA exactly exchange information/data between each other.

>>
>> Of course LMAs need to share information between each other but
>> obviously vendors have existing proprietary and standardized
>> solutions
>> for that.
>>
>>>>
>>>> - Allow the primary LMA to dynamically assign the LMA for a
>>>>  given session along the lines of RFC-4433, Dynamic Home
>>>>  Agent Assignment.
>>>
>>>> - Not require the primary LMA to be in path, once the assignment
>>>>  is done
>>>
>>> Always is it for each LMA is on the same level.
>>
>> I did not understand what you meant here.
>>
>
> Sorry. My point is, there is no primary LMA. Each LMA can do
> redirection if it is overloaded. After redirection completed, other
> LMA has taken over the corresponding session. So 'Not require
> the primary LMA to be in path' is a natural result.

It depends on the deployment and load balancer approach some decides  
to implement. So there are deployment models that would have a  
"primary LMA"/load balancer in path.. and some model where not.

Jouni

>
>
> B.R.
> Yungui
>
>>>>
>>>> - Not require multiple MIP signaling round trips after each
>>>>  assignment.
>>>
>>> It is little meaningful when LMA redirection less frequently
>>> happened.
>>
>> Cheers,
>> 	Jouni
>>
>>
>>>
>>>
>>> B.R.
>>> Yungui
>>>
>>>>
>>>> The document can certainly recognise that there are other solutions
>>>> possible, if exposed LMA stickiness is not of concern.
>>>>
>>>>
>>>> Regards
>>>> Sri
>>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>

From: w52006 at huawei.com (Yungui Wang)
Date: Wed, 22 Apr 2009 16:58:48 +0800
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni

Please see inline...

> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam at gmail.com] 
> Sent: Wednesday, April 22, 2009 2:56 PM
> To: w52006 at huawei.com
> Cc: 'Sri Gundavelli'; 'Vijay Devarapalli'; 
> jouni.korhonen at nsn.com; netext at mail.mobileip.jp
> Subject: Re: [Netext] LMA redirection (was RE: WG Review: 
> Network-Based MobilityExtensions (netext))
> 
> Hi Yungui,
> 
> 
> On Apr 22, 2009, at 5:47 AM, Yungui Wang wrote:
> 
> > Hello Sri
> >
> >> Jouni's document is trying to provide a solution with the following
> >> goals in mind:
> >>
> >> - Expose a single address for the entire LMA infrastructure
> >
> > What is the actual meaning here?
> > In my understanding, MAG always knows the r2LMA address after
> > PBA is received. Do you mean exposing a single address to AAA
> > server or other? In practice, e.g. as 3GPP TS23.402 described,
> > after PBU/PBA (reg or de-reg) processing is completed, r2LMA
> > address et. information should be informed to HSS/AAA.
> 
> Say, you have a number of LMA clusters (each cluster has e.g. 10  
> LMAs). Still, each individual LMA has one or more IP address. For a  
> generic LMA discovery you would only expose one rfLMA addresses per  
> cluster e.g. through DNS.  After the redirection the MAG would  
> communicate directly with the assigned r2LMA in some cluster.
> 

Please see my previous mail to Sri. 
In my mind, the point 'Expose a single address for the entire LMA 
infrastructure' is not highlighted.

> > Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
> > redirection or overload indirection, or LMA address list from FQDN)
> > is a good choice, at least for scenario of each LMA is separate box.
> > This is because,
> > on the one hand, each LMA neither needs explicit mobility
> > management signaling to other, nor needs to know other's load info
> > due to load info is a integrative and complex value (e.g. CPU 75%
> > is overloading for one LMA, but not for another).
> > on the other hand, it is consistent with basis LMA discovery
> > mechanism.
> 
> I don't think there needs to be any mobility signaling between LMAs.  

In this draft, when rfLMA redirect the MAG to a r2LMA, doesn't
the rfLMA forward the request(PBU) to the r2LMA?

>
> Of course LMAs need to share information between each other but  
> obviously vendors have existing proprietary and standardized 
> solutions  
> for that.
> 
> >>
> >> - Allow the primary LMA to dynamically assign the LMA for a
> >>   given session along the lines of RFC-4433, Dynamic Home
> >>   Agent Assignment.
> >
> >> - Not require the primary LMA to be in path, once the assignment
> >>   is done
> >
> > Always is it for each LMA is on the same level.
> 
> I did not understand what you meant here.
> 

Sorry. My point is, there is no primary LMA. Each LMA can do 
redirection if it is overloaded. After redirection completed, other 
LMA has taken over the corresponding session. So 'Not require 
the primary LMA to be in path' is a natural result.

B.R.
Yungui

> >>
> >> - Not require multiple MIP signaling round trips after each
> >>   assignment.
> >
> > It is little meaningful when LMA redirection less frequently
> > happened.
> 
> Cheers,
> 	Jouni
> 
> 
> >
> >
> > B.R.
> > Yungui
> >
> >>
> >> The document can certainly recognise that there are other solutions
> >> possible, if exposed LMA stickiness is not of concern.
> >>
> >>
> >> Regards
> >> Sri
> >>
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 

From: w52006 at huawei.com (Yungui Wang)
Date: Wed, 22 Apr 2009 16:05:15 +0800
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Sri

Please see inline...

> -----Original Message-----
> From: Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: Wednesday, April 22, 2009 11:15 AM
> To: Yungui Wang
> Cc: 'Vijay Devarapalli'; jouni.korhonen at nsn.com; 
> netext at mail.mobileip.jp
> Subject: RE: [Netext] LMA redirection (was RE: WG Review: 
> Network-Based MobilityExtensions (netext))
> 
> Hi Yungui,
> 
> 
> >> - Expose a single address for the entire LMA infrastructure
> >
> > What is the actual meaning here?
> > In my understanding, MAG always knows the r2LMA address after
> > PBA is received. Do you mean exposing a single address to AAA
> 
> Sure, initially expose single IP address of the primary LMA
> and upon dynamic allocation will result in exposing the
> real address. So, MAG does know the r2LMA as you say.
> Such semantic is present even in GTP, via Create PDP Context
> Response.
> 
Maybe you were mixing up something here. GTP is based on separated 
control plane and user plane. If necessary, the user plane address may
be changed sometime while the control plane address shall not be 
changed. Moreover, the user plane entity is always not exposed to SGW
(MAG) or other, that's, NO entity except control plane entity exchanges 
signaling with it. 
While, until now, PMIP doesnot support that feature (separated 
control plane and user plane). Don't you want to implement it via
LMA redirection mechanism?
However, r2LMA has been exposed to the MAG (both control plane and 
user plane). That's, 'Expose a single address for the entire LMA 
infrastructure' is not highlighted. Thus, it may have no actual meaning.

In addition, below issues such as 'multiple MIP signaling round trips'
can be easily stated out after the basis is clarified as above. 
I do not further comment it at below.

B.R.
Yungui

> > server or other? In practice, e.g. as 3GPP TS23.402 described,
> > after PBU/PBA (reg or de-reg) processing is completed, r2LMA
> > address et. information should be informed to HSS/AAA.
> > Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
> > redirection or overload indirection, or LMA address list from FQDN)
> > is a good choice, at least for scenario of each LMA is separate box.
> > This is because,
> > on the one hand, each LMA neither needs explicit mobility
> > management signaling to other, nor needs to know other's load info
> > due to load info is a integrative and complex value (e.g. CPU 75%
> > is overloading for one LMA, but not for another).
> > on the other hand, it is consistent with basis LMA discovery
> > mechanism.
> >
> 
> Did not follow completly. But, load balancing is generally not a
> CPU load factor, but is reflective of the hosted sessions. Either
> way, how the load factor is derived or shared, for that there
> are many standard techniques and is not MIP specific issue.
> 
> 
> >> - Allow the primary LMA to dynamically assign the LMA for a
> >>    given session along the lines of RFC-4433, Dynamic Home
> >>    Agent Assignment.
> >
> >> - Not require the primary LMA to be in path, once the assignment
> >>    is done
> >
> > Always is it for each LMA is on the same level.
> >
> >> - Not require multiple MIP signaling round trips after each
> >>    assignment.
> >
> > It is little meaningful when LMA redirection less frequently
> > happened.
> >
> 
> No, this is not about this approach. Rather an issue in generic
> load balancer schemes, the protocol has no mechanism for the
> load balancer to decouple it self from the signaling flows.
> The solution to this problem should be within the above parameters.
> 
>
> Sri
> 
> 
> 
> > B.R.
> > Yungui
> >
> >>
> >> The document can certainly recognise that there are other solutions
> >> possible, if exposed LMA stickiness is not of concern.
> >>
> >>
> >> Regards
> >> Sri
> >>
> >
> >
> 

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Wed, 22 Apr 2009 09:56:11 +0300
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,

On Apr 22, 2009, at 5:47 AM, Yungui Wang wrote:

> Hello Sri
>
>> Jouni's document is trying to provide a solution with the following
>> goals in mind:
>>
>> - Expose a single address for the entire LMA infrastructure
>
> What is the actual meaning here?
> In my understanding, MAG always knows the r2LMA address after
> PBA is received. Do you mean exposing a single address to AAA
> server or other? In practice, e.g. as 3GPP TS23.402 described,
> after PBU/PBA (reg or de-reg) processing is completed, r2LMA
> address et. information should be informed to HSS/AAA.

Say, you have a number of LMA clusters (each cluster has e.g. 10  
LMAs). Still, each individual LMA has one or more IP address. For a  
generic LMA discovery you would only expose one rfLMA addresses per  
cluster e.g. through DNS.  After the redirection the MAG would  
communicate directly with the assigned r2LMA in some cluster.

> Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
> redirection or overload indirection, or LMA address list from FQDN)
> is a good choice, at least for scenario of each LMA is separate box.
> This is because,
> on the one hand, each LMA neither needs explicit mobility
> management signaling to other, nor needs to know other's load info
> due to load info is a integrative and complex value (e.g. CPU 75%
> is overloading for one LMA, but not for another).
> on the other hand, it is consistent with basis LMA discovery
> mechanism.

I don't think there needs to be any mobility signaling between LMAs.  
Of course LMAs need to share information between each other but  
obviously vendors have existing proprietary and standardized solutions  
for that.

>>
>> - Allow the primary LMA to dynamically assign the LMA for a
>>   given session along the lines of RFC-4433, Dynamic Home
>>   Agent Assignment.
>
>> - Not require the primary LMA to be in path, once the assignment
>>   is done
>
> Always is it for each LMA is on the same level.

I did not understand what you meant here.

>>
>> - Not require multiple MIP signaling round trips after each
>>   assignment.
>
> It is little meaningful when LMA redirection less frequently
> happened.

Cheers,
	Jouni

>
>
> B.R.
> Yungui
>
>>
>> The document can certainly recognise that there are other solutions
>> possible, if exposed LMA stickiness is not of concern.
>>
>>
>> Regards
>> Sri
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 21 Apr 2009 20:14:40 -0700 (PDT)
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,

>> - Expose a single address for the entire LMA infrastructure
>
> What is the actual meaning here?
> In my understanding, MAG always knows the r2LMA address after
> PBA is received. Do you mean exposing a single address to AAA

Sure, initially expose single IP address of the primary LMA
and upon dynamic allocation will result in exposing the
real address. So, MAG does know the r2LMA as you say.
Such semantic is present even in GTP, via Create PDP Context
Response.

> server or other? In practice, e.g. as 3GPP TS23.402 described,
> after PBU/PBA (reg or de-reg) processing is completed, r2LMA
> address et. information should be informed to HSS/AAA.
> Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
> redirection or overload indirection, or LMA address list from FQDN)
> is a good choice, at least for scenario of each LMA is separate box.
> This is because,
> on the one hand, each LMA neither needs explicit mobility
> management signaling to other, nor needs to know other's load info
> due to load info is a integrative and complex value (e.g. CPU 75%
> is overloading for one LMA, but not for another).
> on the other hand, it is consistent with basis LMA discovery
> mechanism.
>

Did not follow completly. But, load balancing is generally not a
CPU load factor, but is reflective of the hosted sessions. Either
way, how the load factor is derived or shared, for that there
are many standard techniques and is not MIP specific issue.

>> - Allow the primary LMA to dynamically assign the LMA for a
>>    given session along the lines of RFC-4433, Dynamic Home
>>    Agent Assignment.
>
>> - Not require the primary LMA to be in path, once the assignment
>>    is done
>
> Always is it for each LMA is on the same level.
>
>> - Not require multiple MIP signaling round trips after each
>>    assignment.
>
> It is little meaningful when LMA redirection less frequently
> happened.
>

No, this is not about this approach. Rather an issue in generic
load balancer schemes, the protocol has no mechanism for the
load balancer to decouple it self from the signaling flows.
The solution to this problem should be within the above parameters.

Sri

> B.R.
> Yungui
>
>>
>> The document can certainly recognise that there are other solutions
>> possible, if exposed LMA stickiness is not of concern.
>>
>>
>> Regards
>> Sri
>>
>
>

From: w52006 at huawei.com (Yungui Wang)
Date: Wed, 22 Apr 2009 10:47:41 +0800
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Sri

> Jouni's document is trying to provide a solution with the following
> goals in mind:
> 
> - Expose a single address for the entire LMA infrastructure

What is the actual meaning here? 
In my understanding, MAG always knows the r2LMA address after 
PBA is received. Do you mean exposing a single address to AAA 
server or other? In practice, e.g. as 3GPP TS23.402 described, 
after PBU/PBA (reg or de-reg) processing is completed, r2LMA 
address et. information should be informed to HSS/AAA.
Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's 
redirection or overload indirection, or LMA address list from FQDN) 
is a good choice, at least for scenario of each LMA is separate box. 
This is because, 
on the one hand, each LMA neither needs explicit mobility 
management signaling to other, nor needs to know other's load info 
due to load info is a integrative and complex value (e.g. CPU 75%
is overloading for one LMA, but not for another). 
on the other hand, it is consistent with basis LMA discovery 
mechanism.

> - Allow the primary LMA to dynamically assign the LMA for a
>    given session along the lines of RFC-4433, Dynamic Home
>    Agent Assignment.

> - Not require the primary LMA to be in path, once the assignment
>    is done

Always is it for each LMA is on the same level.

> - Not require multiple MIP signaling round trips after each
>    assignment.

It is little meaningful when LMA redirection less frequently 
happened.

B.R.
Yungui

> 
> The document can certainly recognise that there are other solutions
> possible, if exposed LMA stickiness is not of concern.
> 
> 
> Regards
> Sri
> 

From: w52006 at huawei.com (Yungui Wang)
Date: Wed, 22 Apr 2009 09:42:33 +0800
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Jari

I am concerning of how MIF capable node works in PMIP domain.
In the charter of MIF, there is a paragraph described as below:
"...The group shall not assume any
software beyond basic IP protocol support on its peers or in network
nodes. No work will be done to enable traffic flows to move from one
interface to another. The group recognizes existing work on mechanisms
that require peer or network support for moving traffic flows such as
RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile
IPv6. This group does not work on or impact such mechanisms.  ..."

That's, MIF capable node is dependent on network to provide traffic flows 
moving among interfaces. However, how to do traffic flows handover 
between interfaces in PMIP domain is not described. If MIF capable node
is located in PMIP domain, then this feature will be disable. 
I am wondering if/when these works will be done in Netext(PMIP).
Some PS and I-D had stated these issues as below.
http://tools.ietf.org/html/draft-devarapalli-netext-multi-interface-support-
00
http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
http://tools.ietf.org/html/draft-koodli-flow-handover-00
Thus, personally propose this working item is included in the charter 
and making things progress. Thanks.

B.R.
Yungui 

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Jari Arkko
> Sent: Tuesday, April 21, 2009 5:06 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Draft revision of the NETEXT charter
> 
> I'd like to propose the following new version of the charter 
> to resolve 
> issues related to (1) host interaction wrt this charter and (2) LMA 
> redirection.
> 
> The rationale for (1) is that there seems to be universal 
> agreement that 
> the current work items do not affect hosts in any way. I 
> wanted to find 
> a compromise where the charter declares the principles under which it 
> operates but does not prejudice the outcome of the 
> discussions regarding 
> the extensions. I think it would be unfair to hold the 
> current harmless 
> extensions up just because we have not agreed upon some other 
> extensions 
> or what rules such extensions must not or may break. I 
> realize that this 
> compromise may leave some people wish a stronger statement in the 
> current. And some other people wishing that the charter did not have 
> those words. However, I hope that it is a reasonable compromise that 
> allows us to find rough consensus and move ahead.
> 
> The rationale for (2) is that after checking with some of the people 
> involved in the discussion, including LMA redirection in the charter 
> seems to be acceptable, if its scope and relation to other 
> solutions is 
> a bit clearer in the charter and the eventual specification has an 
> applicability statement that does not sell the specification as the 
> solution for all situations.
> 
> Jari
> 
> 
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-20
> 
> 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.
> 
> 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 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 have 
> been discussed in the BOF and on the list. The working group should 
> continue the discussion about 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. It is expected that 
> a decision 
> about the additional extensions is made in a timely manner.
> 
> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> July 2009 Charter revision approved for possible new 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 2009 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 21 Apr 2009 08:10:55 -0700
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I agree with Yokota-san. I would like the text to be kept in the charter.

Vijay

On 4/21/09 6:52 AM, "Hidetoshi Yokota" wrote:

> Hi Jari and Gerardo,
> 
> Jari Arkko wrote:
>> Gerardo,
>> 
>>> The above paragraph sounds very weird in a charter. It could apply to
>>> any BoF, e.g. I wonder why it is not included in the MIF charter. I
>>> think the previous paragraph which says that we can re-charter at any
>>> time to add new features leaves already room for new extensions.
>>> Therefore I would like to propose to remove the paragraph above.
>>>   
>> 
>> I do not have a strong opinion about this, but I will point out that
>> people kept asking me about this, so I felt that it might be useful to
>> be explicit.
> 
> I personally think that the proposed new charter well captured the whole
> discussions on the ML so far and sublimated them in a fine way. I might
> be worrying unduly, but some people may be very strict about the
> milestone and may object to any other discussion than the listed work
> items by considering it is just a waste of time to do so. But I believe
> it is a fact that there are quite a few people who are interested in
> more and want to discuss them in parallel. Then we can come back to this
> proposed text, which indicates that the listed work items are
> well-agreed and feasible ones that can meet the deadlines with a high
> probability and that the WG at the same time keeps the door open for
> other potential work items, which we are encouraged to discuss and may
> be able to present in the meetings if time permitting. Again, this is my
> personal opinion, but I think the pointed part signifies what we have
> discussed and it's worth keeping it.
> 
> Regards,

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 21 Apr 2009 07:56:31 -0700
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari, 

Thanks for the response. See some more minor details inline.

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko at piuha.net]
> Sent: Tuesday, April 21, 2009 3:50 AM
> To: Giaretta, Gerardo
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] Draft revision of the NETEXT charter
> 
> Gerardo,
> 
> > The above paragraph sounds very weird in a charter. It could apply to any
> BoF, e.g. I wonder why it is not included in the MIF charter. I think the
> previous paragraph which says that we can re-charter at any time to add new
> features leaves already room for new extensions. Therefore I would like to
> propose to remove the paragraph above.
> >
> 
> I do not have a strong opinion about this, but I will point out that
> people kept asking me about this, so I felt that it might be useful to
> be explicit.
>

I understand the rationale from your point of view. However this does not seem a text appropriate for a charter and will imply that we need to re-charter whatever decision we take in July/August. We already have the milestone for additional features.

 > >> Milestones
> >>
> >> May 2009 WG chartered
> >> July 2009 Initial WG draft on Bulk Refresh
> >> July 2009 Charter revision approved for possible new work items
> >>
> >
> > The date should be at least August 2009 as we should have the possibility to
> discuss this in the next IETF meeting, e.g. in another BoF. Also it is not
> clear what you mean by "charter revision approved". There may be no revised
> charter at all to approve if there is no consensus to add new items. I suggest
> to reword as "Decision on inclusion of possible new work items".
> >
> 
> I like your formulation better, thanks.
> 

Good, thanks

> July in principle includes the next IETF meeting time, too. Of course I
> hope we can solve this on the list before then. But lets see.
> 

OK, I was thinking that a consensus over mailing list after the IETF meeting will imply August but I am fine with stating July - it does not make a big difference.

Thanks
Gerardo

> Jari

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 21 Apr 2009 22:52:56 +0900
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari and Gerardo,

Jari Arkko wrote:
> Gerardo,
> 
>> The above paragraph sounds very weird in a charter. It could apply to 
>> any BoF, e.g. I wonder why it is not included in the MIF charter. I 
>> think the previous paragraph which says that we can re-charter at any 
>> time to add new features leaves already room for new extensions. 
>> Therefore I would like to propose to remove the paragraph above.
>>   
> 
> I do not have a strong opinion about this, but I will point out that 
> people kept asking me about this, so I felt that it might be useful to 
> be explicit.

I personally think that the proposed new charter well captured the whole
discussions on the ML so far and sublimated them in a fine way. I might
be worrying unduly, but some people may be very strict about the
milestone and may object to any other discussion than the listed work
items by considering it is just a waste of time to do so. But I believe
it is a fact that there are quite a few people who are interested in
more and want to discuss them in parallel. Then we can come back to this
proposed text, which indicates that the listed work items are
well-agreed and feasible ones that can meet the deadlines with a high
probability and that the WG at the same time keeps the door open for
other potential work items, which we are encouraged to discuss and may
be able to present in the meetings if time permitting. Again, this is my
personal opinion, but I think the pointed part signifies what we have
discussed and it's worth keeping it.

Regards,
-- 
Hidetoshi

>>> Milestones
>>>
>>> May 2009 WG chartered
>>> July 2009 Initial WG draft on Bulk Refresh
>>> July 2009 Charter revision approved for possible new work items
>>>     
>>
>> The date should be at least August 2009 as we should have the 
>> possibility to discuss this in the next IETF meeting, e.g. in another 
>> BoF. Also it is not clear what you mean by "charter revision 
>> approved". There may be no revised charter at all to approve if there 
>> is no consensus to add new items. I suggest to reword as "Decision on 
>> inclusion of possible new work items".
>>   
> 
> I like your formulation better, thanks.
> 
> July in principle includes the next IETF meeting time, too. Of course I 
> hope we can solve this on the list before then. But lets see.
> 
> Jari
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: jari.arkko at piuha.net (Jari Arkko)
Date: Tue, 21 Apr 2009 13:49:49 +0300
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Gerardo,

> The above paragraph sounds very weird in a charter. It could apply to any BoF, e.g. I wonder why it is not included in the MIF charter. I think the previous paragraph which says that we can re-charter at any time to add new features leaves already room for new extensions. Therefore I would like to propose to remove the paragraph above.
>   

I do not have a strong opinion about this, but I will point out that 
people kept asking me about this, so I felt that it might be useful to 
be explicit.

>> Milestones
>>
>> May 2009 WG chartered
>> July 2009 Initial WG draft on Bulk Refresh
>> July 2009 Charter revision approved for possible new work items
>>     
>
> The date should be at least August 2009 as we should have the possibility to discuss this in the next IETF meeting, e.g. in another BoF. Also it is not clear what you mean by "charter revision approved". There may be no revised charter at all to approve if there is no consensus to add new items. I suggest to reword as "Decision on inclusion of possible new work items".
>   

I like your formulation better, thanks.

July in principle includes the next IETF meeting time, too. Of course I 
hope we can solve this on the list before then. But lets see.

Jari

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Mon, 20 Apr 2009 21:56:13 -0700
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

Thanks for the updated charter. Please see some comments inline

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Jari Arkko
> Sent: Monday, April 20, 2009 2:06 PM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Draft revision of the NETEXT charter
> 
> I'd like to propose the following new version of the charter to resolve
> issues related to (1) host interaction wrt this charter and (2) LMA
> redirection.
> 
> The rationale for (1) is that there seems to be universal agreement that
> the current work items do not affect hosts in any way. I wanted to find
> a compromise where the charter declares the principles under which it
> operates but does not prejudice the outcome of the discussions regarding
> the extensions. I think it would be unfair to hold the current harmless
> extensions up just because we have not agreed upon some other extensions
> or what rules such extensions must not or may break. I realize that this
> compromise may leave some people wish a stronger statement in the
> current. And some other people wishing that the charter did not have
> those words. However, I hope that it is a reasonable compromise that
> allows us to find rough consensus and move ahead.
> 
> The rationale for (2) is that after checking with some of the people
> involved in the discussion, including LMA redirection in the charter
> seems to be acceptable, if its scope and relation to other solutions is
> a bit clearer in the charter and the eventual specification has an
> applicability statement that does not sell the specification as the
> solution for all situations.
> 
> Jari
> 
> 
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-20
> 
> 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.
> 
> 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 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 have
> been discussed in the BOF and on the list. The working group should
> continue the discussion about 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. It is expected that a decision
> about the additional extensions is made in a timely manner.
> 

The above paragraph sounds very weird in a charter. It could apply to any BoF, e.g. I wonder why it is not included in the MIF charter. I think the previous paragraph which says that we can re-charter at any time to add new features leaves already room for new extensions. Therefore I would like to propose to remove the paragraph above.

> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> July 2009 Charter revision approved for possible new work items

The date should be at least August 2009 as we should have the possibility to discuss this in the next IETF meeting, e.g. in another BoF. Also it is not clear what you mean by "charter revision approved". There may be no revised charter at all to approve if there is no consensus to add new items. I suggest to reword as "Decision on inclusion of possible new work items".

Thanks
Gerardo

> 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 2009 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 21 Apr 2009 09:32:47 +1100
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-20
> 
> 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.
> 
> 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 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).

=> Fine with me.

> 
> The proposed activity will be complementary to the existing IETF Working
> Groups, notably the NETLMM and MEXT WGs.

=> How is it completmentary to MEXT?

  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 have
> been discussed in the BOF and on the list. The working group should
> continue the discussion about possible update of its charter and
> principles under which the new work items must operate under.

=> This text is true for all WGs, I don't see a need for this text. The rest
(below)is fine with me.

Hesham

The 
> completion of the work items in the initial charter is not a requirement
> for the rechartering to become possible. It is expected that a decision
> about the additional extensions is made in a timely manner.
> 
> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> July 2009 Charter revision approved for possible new 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 2009 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: jari.arkko at piuha.net (Jari Arkko)
Date: Tue, 21 Apr 2009 00:06:27 +0300
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I'd like to propose the following new version of the charter to resolve 
issues related to (1) host interaction wrt this charter and (2) LMA 
redirection.

The rationale for (1) is that there seems to be universal agreement that 
the current work items do not affect hosts in any way. I wanted to find 
a compromise where the charter declares the principles under which it 
operates but does not prejudice the outcome of the discussions regarding 
the extensions. I think it would be unfair to hold the current harmless 
extensions up just because we have not agreed upon some other extensions 
or what rules such extensions must not or may break. I realize that this 
compromise may leave some people wish a stronger statement in the 
current. And some other people wishing that the charter did not have 
those words. However, I hope that it is a reasonable compromise that 
allows us to find rough consensus and move ahead.

The rationale for (2) is that after checking with some of the people 
involved in the discussion, including LMA redirection in the charter 
seems to be acceptable, if its scope and relation to other solutions is 
a bit clearer in the charter and the eventual specification has an 
applicability statement that does not sell the specification as the 
solution for all situations.

Jari

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

Last Modified: 2009-04-20

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.

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 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 have 
been discussed in the BOF and on the list. The working group should 
continue the discussion about 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. It is expected that a decision 
about the additional extensions is made in a timely manner.

Milestones

May 2009 WG chartered
July 2009 Initial WG draft on Bulk Refresh
July 2009 Charter revision approved for possible new 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 2009 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: yuankui.zhao at gmail.com (john.zhao)
Date: Mon, 20 Apr 2009 21:35:36 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <1240222409.5358.27.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost> <[email-masked]> <1239900013.5254.37.camel@localhost> <[email-masked]> <1240222409.5358.27.camel@localhost>
Message-ID: <[email-masked]>

Hi carlos,

2009/4/20 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> Hi John,
>> >> > I've sent another e-mail regarding this (hope there is more clear).
>> >> > Summarising, what I call a fixed point of attachment is a MAG as it is
>> >> > defined in RFC5213 that does not move. I call a mobile point of
>> >> > attachment a MAG that would also be able to move (like an MR) within the
>> >> > PMIPv6 domain.
>> >> [John.zhao]So,would you like extend the MAG capability to a moving
>> >> router,right? If thus, where is the LMA for this MAG?
>> >
>> > Well, it can be seen the other way around, to extend the MAG capability
>> > to be mobile...
>> >
>> [John.zhao]So,is it a method for moving router or MAG? And what is the
>> difference to the mobile Router to connect to the fixed or mobile
>> attachment point as you mentioned?
>
> I see it as a method for a MAG that is able to move. The key point -- as
> I see it -- is to enable network-based localised mobility domains also
> to moving platforms. By doing that, a legacy MN would be able to roam
> within a domain that compasses not only MAGs that do not change their
> point of attachment, but also MAGs that are also able to move.
>
[John.zhao]Well. From MN perspective, it should be no difference
between these difference kinds of MAGs,right? And I feel the moving
MAGs will use the PBU/PBA to help MN keep moving with LMA, right? In
another side, the moving MAG needs to consider to select a mobile
mechanism to support the mobility of itself, right?

Best Rgds,
Thanks,

John.zhao

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 20 Apr 2009 12:13:29 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost> <[email-masked]> <1239900013.5254.37.camel@localhost> <[email-masked]>
Message-ID: <1240222409.5358.27.camel@localhost>

Hi John,

El vie, 17-04-2009 a las 01:13 +0800, john.zhao escribi?:
> Hi Carlos
> 
> 2009/4/17 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> > Hi John,
> >
> > El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?:
> >> Hi Carlos,
> >>
> >> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> >> > Hi Ryuji,
> >> >        Sorry for the delayed reply. Comments below.
> >> >
> >> > El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
> >> >> Hello Carlos,
> >> >>
> >> >> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
> >> >>
> >> >> > Hi Behcet,
> >> >> >
> >> >> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> >> >> > bit beyond that, since what I want to enable is node to be able to
> >> >> > benefit from network based localised mobility support not only when
> >> >> > roaming between fixed points of attachment (this is what RFC5213 does
> >> >> > today) but also when roaming between fixed and mobile points of
> >> >> > attachment. What people do think about this scenario?
> >> >>
> >> >> I don't know what is fixed and mobile points of attachment. You can
> >> >> clarify these.
> >> >>
> >> >
> >> > I've sent another e-mail regarding this (hope there is more clear).
> >> > Summarising, what I call a fixed point of attachment is a MAG as it is
> >> > defined in RFC5213 that does not move. I call a mobile point of
> >> > attachment a MAG that would also be able to move (like an MR) within the
> >> > PMIPv6 domain.
> >> [John.zhao]So,would you like extend the MAG capability to a moving
> >> router,right? If thus, where is the LMA for this MAG?
> >
> > Well, it can be seen the other way around, to extend the MAG capability
> > to be mobile...
> >
> [John.zhao]So,is it a method for moving router or MAG? And what is the
> difference to the mobile Router to connect to the fixed or mobile
> attachment point as you mentioned?

I see it as a method for a MAG that is able to move. The key point -- as
I see it -- is to enable network-based localised mobility domains also
to moving platforms. By doing that, a legacy MN would be able to roam
within a domain that compasses not only MAGs that do not change their
point of attachment, but also MAGs that are also able to move.

Thanks,

Carlos

> 
> John.zhao
> 
> > Carlos
> >
> >>
> >>
> >>         Best Rgds,
> >> Thanks,
> >>
> >> John.zhao
> >> >
> >> > Thanks,
> >> >
> >> > Carlos
> >> >
> >> >> ryuji
> >> >>
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Carlos
> >> >> >
> >> >> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >> >> >> Hi Carlos,
> >> >> >>   Check this out:
> >> >> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
> >> >> >> support-00
> >> >> >>
> >> >> >> Regards,
> >> >> >>
> >> >> >> Behcet
> >> >> >>
> >> >> >> ________________________________
> >> >> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >> >> >> To: Jari Arkko <jari.arkko at piuha.net>
> >> >> >> Cc: netext at mail.mobileip.jp
> >> >> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
> >> >> >> Subject: Re: [Netext] next steps for netext
> >> >> >>
> >> >> >> Hi Jari, all,
> >> >> >>
> >> >> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> >> >> >> personal view on that is that it'd be nice to extend PMIPv6 to
> >> >> >> support
> >> >> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
> >> >> >> to also move (like MRs, but without even supporting RFC3963), so an
> >> >> >> MR
> >> >> >> would be able to move between fixed and mobile MAGs without changing
> >> >> >> its IP address (same support RFC5213 gives now). There are some
> >> >> >> interesting scenarios that could benefit from this.
> >> >> >>
> >> >> >> What do others think? It is interesting to work on this?
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> Carlos
> >> >> >>
> >> >> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> >> >>> Sri,
> >> >> >>>
> >> >> >>> Thanks for your input. Inline:
> >> >> >>>
> >> >> >>>> I've a concern with the planned charter. The list is too random and
> >> >> >>>> cherry picked and I dont believe proper input from all the folks
> >> >> >>>> went
> >> >> >>>> into
> >> >> >>>> this. There are many other items that are required for a reasonable
> >> >> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
> >> >> >>>> the last 2
> >> >> >>>> years, some of them that were left out in the base spec, some
> >> >> >>>> that we
> >> >> >>>> realized as gaps when compared to other SDO protocols and some as
> >> >> >>>> optimizations that we realized while implementing PMIP6, these
> >> >> >>>> items
> >> >> >>>> should be in the initial scope.
> >> >> >>>>
> >> >> >>>> I understand the charter needs to be limited in scope, but just 3
> >> >> >>>> or 4
> >> >> >>>> random items, I'm not sure if this helps in short term PMIP6
> >> >> >>>> requirements.
> >> >> >>>> I've no issue with the currently listed items, but there are
> >> >> >>>> other items
> >> >> >>>> that should get equal or higher priority.
> >> >> >>>
> >> >> >>> I have no problem with adding more. Even the charter says new
> >> >> >>> things can
> >> >> >>> be
> >> >> >>> added.
> >> >> >>>
> >> >> >>> However, from a process perspective what I did was to take the
> >> >> >>> proposal on
> >> >> >>> the table, i.e., the full BOF scope and see what parts of that we
> >> >> >>> already
> >> >> >>> have an agreement on. I didn't include other things that were not
> >> >> >>> discussed
> >> >> >>> in the BOF. Maybe that would have been useful, but they were not
> >> >> >>> on the
> >> >> >>> table.
> >> >> >>>
> >> >> >>> We could add more items now, if there's general agreement that those
> >> >> >>> things
> >> >> >>> are useful. However, I do not want to declare an open season on
> >> >> >>> doing
> >> >> >>> everything. We pick a reasonable subset of all proposed work,
> >> >> >>> based on
> >> >> >>> priorities, community agreement that they are the right things to
> >> >> >>> do,
> >> >> >>> management reasons to ensure that we are not doing too much, etc.
> >> >> >>>
> >> >> >>>> For example, item #6, is absolutely required, from the
> >> >> >>>> perspective of
> >> >> >>>> having a complete specification of 5213. There we allowed a
> >> >> >>>> mobile node
> >> >> >>>> to
> >> >> >>>> perform handoff betweek two interfaces. We defined all the hooks
> >> >> >>>> on the
> >> >> >>>> network side, but we did not provide how a terminal vendor can
> >> >> >>>> support
> >> >> >>>> that. A simple informational draft on how some one move prefixes
> >> >> >>>> between
> >> >> >>>> interfaces will greatly help. Some guidance on how to create a
> >> >> >>>> virtual
> >> >> >>>> interface and also some related notes for each platform (Linux,
> >> >> >>>> BSD,
> >> >> >>>> Android ..etc). This should not fall in the controversial
> >> >> >>>> discussion
> >> >> >>>> scope
> >> >> >>>> of same address on two interfaces etc, thats a different problem,
> >> >> >>>> or
> >> >> >>>> about
> >> >> >>>> the issue of enhancing mobile node's capabilities. This is just
> >> >> >>>> informational work, required to leverage what 5213 already
> >> >> >>>> supports.
> >> >> >>>
> >> >> >>> I suspect this is about the scoping of the handoff work. Lets try to
> >> >> >>> figure
> >> >> >>> out what makes sense (I personally believe the above item makes
> >> >> >>> sense, for
> >> >> >>> instance) and what doesn't.
> >> >> >>>
> >> >> >>> The fact that these parts were not in the charter was not a
> >> >> >>> declaration
> >> >> >>> that
> >> >> >>> we're dismissing them. Its just that we didn't finish the
> >> >> >>> discussion, but
> >> >> >>> I
> >> >> >>> still wanted to let the other things move forward.
> >> >> >>>
> >> >> >>>> Item #2, is required. The multimob BOF raised some issues, we
> >> >> >>>> need to
> >> >> >>>> show how multicast services can be enabled in PMIP network. May
> >> >> >>>> be this
> >> >> >>>> wont require extensions, a simple draft covering those aspects
> >> >> >>>> will help.
> >> >> >>>
> >> >> >>> As you may recall, in the Multimob BOF we did not have an
> >> >> >>> agreement on
> >> >> >>> what
> >> >> >>> exactly is needed, if anything. My own conclusion is that we
> >> >> >>> probably need
> >> >> >>> at least an informational document that explains how to use RFC
> >> >> >>> 5213 for
> >> >> >>> multicast. I think we discussed the possibility of doing this as
> >> >> >>> some kind
> >> >> >>> of AD sponsored document or in one of the relevant WGs, as a joint
> >> >> >>> work
> >> >> >>> between PMIP and multicast experts.
> >> >> >>>
> >> >> >>> I'm on the fence about adding this work to the charter right now,
> >> >> >>> mainly
> >> >> >>> because the BOF back then was very inconclusive. I'd be happier if
> >> >> >>> I saw
> >> >> >>> an
> >> >> >>> actual well written draft from say you and some of the multicast
> >> >> >>> experts.
> >> >> >>> There's no problem moving good documents forward, even if they are
> >> >> >>> not in
> >> >> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> >> >>> maintenance like item for this in one of the WG charters either.
> >> >> >>>
> >> >> >>>> I think, the charter should be bit more relaxed and more
> >> >> >>>> extensive. As I
> >> >> >>>> see it, atleast the folks are interested in doing the work. We
> >> >> >>>> should add
> >> >> >>>> atleast 4 or 5 more items to this list.
> >> >> >>>
> >> >> >>> Generally speaking IETF WG charters give specific work items that
> >> >> >>> the WG
> >> >> >>> should work on. I had hoped that the charter text:
> >> >> >>>
> >> >> >>> "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."
> >> >> >>>
> >> >> >>> gives an indication that we intend to do more! I am also
> >> >> >>> personally very
> >> >> >>> happy to add more items to the group's charter. All in all, I do
> >> >> >>> know that
> >> >> >>> the current charter is a bit on the thin side -- mostly because the
> >> >> >>> multihoming/interaccess issue is under discussion.
> >> >> >>>
> >> >> >>> There's also the question of general maintenance items. Some IETF
> >> >> >>> WGs have
> >> >> >>> a
> >> >> >>> general work item to fix problems and issue updates to existing
> >> >> >>> specifications. I think we need to do that for Proxy Mobile IPv6
> >> >> >>> as well.
> >> >> >>> But we have not decided whether that item should go to NETLMM or
> >> >> >>> NETEXT WG
> >> >> >>> yet. Please rest assured that the work will be possible regardless
> >> >> >>> of
> >> >> >>> this.
> >> >> >>>
> >> >> >>>> 1. Dynamic LMA Assignment
> >> >> >>>>
> >> >> >>>> In blade architecture systems or in a load balancer
> >> >> >>>> configuration, the
> >> >> >>>> PDNGW
> >> >> >>>> should have the ability to dynamically assign a LMA on the fly,
> >> >> >>>> along the
> >> >> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >> >> >>>> [RFC-4433].
> >> >> >>>> Currently, GTP provides such semantics and this is a important
> >> >> >>>> requirement
> >> >> >>>> for deployment. Here the goal is to
> >> >> >>>>
> >> >> >>>> a.) Expose a single IP address to the SGW
> >> >> >>>> b.) The exposed IP address should not be in path once the
> >> >> >>>> assignment is
> >> >> >>>> done.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> [LMA1]---
> >> >> >>>> | |
> >> >> >>>> [LMA2]--[LMA]==========[MAG]
> >> >> >>>> | |
> >> >> >>>> [LMA3]---
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Along the lines of:
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >> >> >>>
> >> >> >>> This is in the proposed NETEXT charter already.
> >> >> >>>
> >> >> >>>> 2. Multicast Support in Proxy Mobile IPv6
> >> >> >>>>
> >> >> >>>> We need an informational specification on how multicast support
> >> >> >>>> can be
> >> >> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >> >> >>>> analysis
> >> >> >>>> on
> >> >> >>>> this. This is required and critical for enabling any multicast
> >> >> >>>> services.
> >> >> >>>> However,
> >> >> >>>> Behcet may disagree with the scope of the work.
> >> >> >>>
> >> >> >>> See above.
> >> >> >>>
> >> >> >>>> 3. Bulk Registration Support
> >> >> >>>>
> >> >> >>>> This is a simple extension which helps in signaling optimization,
> >> >> >>>> along
> >> >> >>>> the
> >> >> >>>> lines of:
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >> >> >>>
> >> >> >>> This is in the charter as well.
> >> >> >>>
> >> >> >>>> 4. Partial Failover Support
> >> >> >>>>
> >> >> >>>> We need a mechanism to notify the peer on revoke a partial set of
> >> >> >>>> bindings.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> >> >> >>>> .
> >> >> >>>> txt
> >> >> >>>
> >> >> >>> Hmm. Ok. This needs more discussion.
> >> >> >>>
> >> >> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
> >> >> >>>>
> >> >> >>>> This provides a simple and a generic semantic for assigning a group
> >> >> >>>> identifier
> >> >> >>>> to a mobile node's binding. GTP has very similar semantics,
> >> >> >>>> Connexion Set
> >> >> >>>> Id.
> >> >> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
> >> >> >>>> systems
> >> >> >>>> where
> >> >> >>>> the load balancer is in path for all signaling messages, it can
> >> >> >>>> use this
> >> >> >>>> as
> >> >> >>>> a
> >> >> >>>> tag for redirecting the message.
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >> >> >>>
> >> >> >>> Since the bulk registration work is in the charter, can't you do the
> >> >> >>> sensible design (whatever it is) under that? There is no
> >> >> >>> requirement that
> >> >> >>> one charter item equals one document.
> >> >> >>>
> >> >> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >> >> >>>> handoffs:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> RFC-5213 supports handoff between two interfaces. The ability to
> >> >> >>>> move
> >> >> >>>> prefixes between interfaces. In other words address continuity is
> >> >> >>>> assured
> >> >> >>>> with any IPv6 host on the planet and with absolutely no changes.
> >> >> >>>> This
> >> >> >>>> meets
> >> >> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
> >> >> >>>> what is
> >> >> >>>> not assured is the aspect of session continuity. Which requires a
> >> >> >>>> virtual
> >> >> >>>> interface implementation on the host, by binding the address/
> >> >> >>>> prefix to a
> >> >> >>>> virtual interface and by not exposing the physical interface or
> >> >> >>>> by hiding
> >> >> >>>> the handoff events from the layer-3 stack.
> >> >> >>>>
> >> >> >>>> In essence, we need an informational specification which provides
> >> >> >>>> some
> >> >> >>>> general guidance to how to leverage the feature support provided in
> >> >> >>>> RFC-5213,
> >> >> >>>> along the lines of:
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >> >> >>>
> >> >> >>> This is part of the discussion that we need to finish. But I plan
> >> >> >>> to let
> >> >> >>> the
> >> >> >>> rest of the stuff move forward even before we have done that.
> >> >> >>>
> >> >> >>>
> >> >> >>>> 7. Route Optimization for Proxy Mobile IPv6
> >> >> >>>>
> >> >> >>>> There were atleast 4 drafts in this area on Route Optimization.
> >> >> >>>> Marco
> >> >> >>>> Liebsch
> >> >> >>>> analyzed this exensively:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> >> >> >>>> .
> >> >> >>>> txt
> >> >> >>>
> >> >> >>> This is in the charter.
> >> >> >>>
> >> >> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
> >> >> >>>>
> >> >> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
> >> >> >>>> prefixes
> >> >> >>>> to a given mobile node's interface. It might be useful to specify
> >> >> >>>> how the
> >> >> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
> >> >> >>>> Pools or
> >> >> >>>> AAA to manage this aspect. Behcet has one draft on this.
> >> >> >>>
> >> >> >>> I'm not personally sold on this particular work. But again, this
> >> >> >>> could be
> >> >> >>> something to consider.
> >> >> >>>
> >> >> >>>> 9. Partial Handoff Support
> >> >> >>>>
> >> >> >>>> We are missing some semantics in 5213 for moving a subset of the
> >> >> >>>> prefixes
> >> >> >>>> between interfaces as part of the inter-tech handoff. This is about
> >> >> >>>> defining
> >> >> >>>> a new handoff value. This allows partial flow management, but
> >> >> >>>> moving the
> >> >> >>>> flows associated to a prefix, as a whole group.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >> >> >>>
> >> >> >>> A part of the topic we still need to discuss...
> >> >> >>>
> >> >> >>>> 10. CMIPv4/PMIP Interworking
> >> >> >>>>
> >> >> >>>> This is probably required to specify how an IPv4-only can move
> >> >> >>>> between
> >> >> >>>> CMIP and PMIP environments.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >> >> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
> >> >> >>>
> >> >> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
> >> >> >>> NETLMM
> >> >> >>> charter, but this work is presumably about interaction with MIPv4.
> >> >> >>> Might
> >> >> >>> be
> >> >> >>> useful work, I wouldn't mind if this was done in NETEXT at some
> >> >> >>> point. Is
> >> >> >>> this crucial to be in the first revision of the WG's charter?
> >> >> >>>
> >> >> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >> >> >>>
> >> >> >>> Can you expand on this?
> >> >> >>>
> >> >> >>> Jari
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> 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
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > _______________________________________________
> >> >> > NetExt mailing list
> >> >> > NetExt at mail.mobileip.jp
> >> >> > http://www.mobileip.jp/mailman/listinfo/netext
> >> >>
> >> > --
> >> >   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
> >> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >
> >> > _______________________________________________
> >> > NetExt mailing list
> >> > NetExt at mail.mobileip.jp
> >> > http://www.mobileip.jp/mailman/listinfo/netext
> >> >
> >> >
> > --
> >   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
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
-- 
   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/20090420/8975316e/attachment-0001.bin>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 20 Apr 2009 12:10:36 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239838985.4695.114.camel@localhost> <[email-masked]>
Message-ID: <1240222236.5358.24.camel@localhost>

Hi Jong-Hyouk,

El jue, 16-04-2009 a las 10:26 +0900, Jong-Hyouk Lee escribi?:
> Hi. Carlos.
>  
> In the I-D, four types of scenarios are presented. All of them mainly
> focuses on the MR involving nodes hands off between MAGs or LMAs
> (intra-domain handoff and inter-domain handoff). The scenarios for the
> case you mentioned would be covered in the next version of the I-D (I
> hope).

OK, thanks.

>  
> Do you have any issues in mind for the case? 

Well, the particular scenario that I pointed out is not supported with
existing standards. That's why I proposed working on it.

Thanks,

Carlos

>  
> Cheers. 
> 
> 
> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>         Hi Jong-Hyouk,
>         
>                Sorry for the delayed reply. I'll take a look at that
>         draft and provide
>         comments. Please, let me ask a short question (before I've
>         read the
>         draft): does the I-D look at any scenario involving an MN that
>         changes
>         its point of attachment between an MR (attached to a PMIPv6
>         domain) and
>         a MAG?
>         
>                Thanks,
>         
>                Carlos
>         
>         El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
>         > Hi, Carlos.
>         >
>         > Good to see your posts in this mailing. Anyway, the
>         following document
>         > has been expired would provide some scenarios for NEMO
>         within PMIPv6
>         > networks.
>         >
>         >
>         http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01
>         >
>         > Have a good day!
>         >
>         >
>         > 2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>         >         Hi Behcet,
>         >
>         >         I've quickly checked the document. I think it does
>         address the
>         >         same
>         >         problem I was referring to. This draft addresses the
>         problem
>         >         of
>         >         delegating a prefix to a router that attaches to a
>         PMIPv6
>         >         domain, so
>         >         it can provide connectivity to nodes attached to it.
>         I think
>         >         this was
>         >         already discussed in a past meeting (a draft with
>         the problem
>         >         statement) and I mentioned that IMHO this can
>         basically be
>         >         achieved by
>         >         just using plain NEMO support on the router. The
>         only
>         >         difference in
>         >         this draft is that it doesn't impose the router to
>         be a NEMO
>         >         RFC3963
>         >         MR, although still it needs to do some additional
>         things that
>         >         a normal
>         >         router (not mobile) doesn't. Anyway, I'm not against
>         this type
>         >         of
>         >         support if there are scenarios in which it's useful.
>         >
>         >         However, the kind of NEMO+PMIPv6 support I'm
>         considering goes
>         >         a little
>         >         bit beyond that, since what I want to enable is node
>         to be
>         >         able to
>         >         benefit from network based localised mobility
>         support not only
>         >         when
>         >         roaming between fixed points of attachment (this is
>         what
>         >         RFC5213 does
>         >         today) but also when roaming between fixed and
>         mobile points
>         >         of
>         >         attachment. What people do think about this
>         scenario?
>         >
>         >         Thanks,
>         >
>         >         Carlos
>         >
>         >         2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>         >
>         >         > Hi Carlos,
>         >         >   Check this out:
>         >         >
>         >
>         http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
>         >         >
>         >         > Regards,
>         >         >
>         >         > Behcet
>         >         >
>         >         > ________________________________
>         >         > From: Carlos Jes?s Bernardos Cano
>         <cjbc at it.uc3m.es>
>         >         > To: Jari Arkko <jari.arkko at piuha.net>
>         >         > Cc: netext at mail.mobileip.jp
>         >         > Sent: Tuesday, April 7, 2009 6:15:42 AM
>         >         > Subject: Re: [Netext] next steps for netext
>         >         >
>         >         > Hi Jari, all,
>         >         >
>         >         > Regarding the NEMO topic, I don't know what Sri
>         has in mind,
>         >         but my
>         >         > personal view on that is that it'd be nice to
>         extend PMIPv6
>         >         to support
>         >         > mobile networks. What I mean here is that it'd be
>         nice to
>         >         enable MAGs
>         >         > to also move (like MRs, but without even
>         supporting
>         >         RFC3963), so an MR
>         >         > would be able to move between fixed and mobile
>         MAGs without
>         >         changing
>         >         > its IP address (same support RFC5213 gives now).
>         There are
>         >         some
>         >         > interesting scenarios that could benefit from
>         this.
>         >         >
>         >         > What do others think? It is interesting to work on
>         this?
>         >         >
>         >         > Thanks,
>         >         >
>         >         > Carlos
>         >         >
>         >         > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>         >         >> Sri,
>         >         >>
>         >         >> Thanks for your input. Inline:
>         >         >>
>         >         >>> I've a concern with the planned charter. The
>         list is too
>         >         random and
>         >         >>> cherry picked and I dont believe proper input
>         from all the
>         >         folks went
>         >         >>> into
>         >         >>> this. There are many other items that are
>         required for a
>         >         reasonable
>         >         >>> deployment of Proxy Mobile IPv6. Many items were
>         proposed
>         >         over the last 2
>         >         >>> years, some of them that were left out in the
>         base spec,
>         >         some that we
>         >         >>> realized as gaps when compared to other SDO
>         protocols and
>         >         some as
>         >         >>> optimizations that we realized while
>         implementing PMIP6,
>         >         these items
>         >         >>> should be in the initial scope.
>         >         >>>
>         >         >>> I understand the charter needs to be limited in
>         scope, but
>         >         just 3 or 4
>         >         >>> random items, I'm not sure if this helps in
>         short term
>         >         PMIP6
>         >         >>> requirements.
>         >         >>> I've no issue with the currently listed items,
>         but there
>         >         are other items
>         >         >>> that should get equal or higher priority.
>         >         >>
>         >         >> I have no problem with adding more. Even the
>         charter says
>         >         new things can
>         >         >> be
>         >         >> added.
>         >         >>
>         >         >> However, from a process perspective what I did
>         was to take
>         >         the proposal on
>         >         >> the table, i.e., the full BOF scope and see what
>         parts of
>         >         that we already
>         >         >> have an agreement on. I didn't include other
>         things that
>         >         were not
>         >         >> discussed
>         >         >> in the BOF. Maybe that would have been useful,
>         but they
>         >         were not on the
>         >         >> table.
>         >         >>
>         >         >> We could add more items now, if there's general
>         agreement
>         >         that those
>         >         >> things
>         >         >> are useful. However, I do not want to declare an
>         open
>         >         season on doing
>         >         >> everything. We pick a reasonable subset of all
>         proposed
>         >         work, based on
>         >         >> priorities, community agreement that they are the
>         right
>         >         things to do,
>         >         >> management reasons to ensure that we are not
>         doing too
>         >         much, etc.
>         >         >>
>         >         >>> For example, item #6, is absolutely required,
>         from the
>         >         perspective of
>         >         >>> having a complete specification of 5213. There
>         we allowed
>         >         a mobile node
>         >         >>> to
>         >         >>> perform handoff betweek two interfaces. We
>         defined all the
>         >         hooks on the
>         >         >>> network side, but we did not provide how a
>         terminal vendor
>         >         can support
>         >         >>> that. A simple informational draft on how some
>         one move
>         >         prefixes between
>         >         >>> interfaces will greatly help. Some guidance on
>         how to
>         >         create a virtual
>         >         >>> interface and also some related notes for each
>         platform
>         >         (Linux, BSD,
>         >         >>> Android ..etc). This should not fall in the
>         controversial
>         >         discussion
>         >         >>> scope
>         >         >>> of same address on two interfaces etc, thats a
>         different
>         >         problem, or
>         >         >>> about
>         >         >>> the issue of enhancing mobile node's
>         capabilities. This is
>         >         just
>         >         >>> informational work, required to leverage what
>         5213 already
>         >         supports.
>         >         >>
>         >         >> I suspect this is about the scoping of the
>         handoff work.
>         >         Lets try to
>         >         >> figure
>         >         >> out what makes sense (I personally believe the
>         above item
>         >         makes sense, for
>         >         >> instance) and what doesn't.
>         >         >>
>         >         >> The fact that these parts were not in the charter
>         was not a
>         >         declaration
>         >         >> that
>         >         >> we're dismissing them. Its just that we didn't
>         finish the
>         >         discussion, but
>         >         >> I
>         >         >> still wanted to let the other things move
>         forward.
>         >         >>
>         >         >>> Item #2, is required. The multimob BOF raised
>         some issues,
>         >         we need to
>         >         >>> show how multicast services can be enabled in
>         PMIP
>         >         network. May be this
>         >         >>> wont require extensions, a simple draft covering
>         those
>         >         aspects will help.
>         >         >>
>         >         >> As you may recall, in the Multimob BOF we did not
>         have an
>         >         agreement on
>         >         >> what
>         >         >> exactly is needed, if anything. My own conclusion
>         is that
>         >         we probably need
>         >         >> at least an informational document that explains
>         how to use
>         >         RFC 5213 for
>         >         >> multicast. I think we discussed the possibility
>         of doing
>         >         this as some kind
>         >         >> of AD sponsored document or in one of the
>         relevant WGs, as
>         >         a joint work
>         >         >> between PMIP and multicast experts.
>         >         >>
>         >         >> I'm on the fence about adding this work to the
>         charter
>         >         right now, mainly
>         >         >> because the BOF back then was very inconclusive.
>         I'd be
>         >         happier if I saw
>         >         >> an
>         >         >> actual well written draft from say you and some
>         of the
>         >         multicast experts.
>         >         >> There's no problem moving good documents forward,
>         even if
>         >         they are not in
>         >         >> the charter of some WG. Then again, I wouldn't
>         necessarily
>         >         mind a
>         >         >> maintenance like item for this in one of the WG
>         charters
>         >         either.
>         >         >>
>         >         >>> I think, the charter should be bit more relaxed
>         and more
>         >         extensive. As I
>         >         >>> see it, atleast the folks are interested in
>         doing the
>         >         work. We should add
>         >         >>> atleast 4 or 5 more items to this list.
>         >         >>
>         >         >> Generally speaking IETF WG charters give specific
>         work
>         >         items that the WG
>         >         >> should work on. I had hoped that the charter
>         text:
>         >         >>
>         >         >> "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."
>         >         >>
>         >         >> gives an indication that we intend to do more! I
>         am also
>         >         personally very
>         >         >> happy to add more items to the group's charter.
>         All in all,
>         >         I do know that
>         >         >> the current charter is a bit on the thin side --
>         mostly
>         >         because the
>         >         >> multihoming/interaccess issue is under
>         discussion.
>         >         >>
>         >         >> There's also the question of general maintenance
>         items.
>         >         Some IETF WGs have
>         >         >> a
>         >         >> general work item to fix problems and issue
>         updates to
>         >         existing
>         >         >> specifications. I think we need to do that for
>         Proxy Mobile
>         >         IPv6 as well.
>         >         >> But we have not decided whether that item should
>         go to
>         >         NETLMM or NETEXT WG
>         >         >> yet. Please rest assured that the work will be
>         possible
>         >         regardless of
>         >         >> this.
>         >         >>
>         >         >>> 1. Dynamic LMA Assignment
>         >         >>>
>         >         >>> In blade architecture systems or in a load
>         balancer
>         >         configuration, the
>         >         >>> PDNGW
>         >         >>> should have the ability to dynamically assign a
>         LMA on the
>         >         fly, along the
>         >         >>> lines of Mobile IPv4 Dynamic Home Agent Address
>         Assignment
>         >         support
>         >         >>> [RFC-4433].
>         >         >>> Currently, GTP provides such semantics and this
>         is a
>         >         important
>         >         >>> requirement
>         >         >>> for deployment. Here the goal is to
>         >         >>>
>         >         >>> a.) Expose a single IP address to the SGW
>         >         >>> b.) The exposed IP address should not be in path
>         once the
>         >         assignment is
>         >         >>> done.
>         >         >>>
>         >         >>>
>         >         >>>
>         >         >>> [LMA1]---
>         >         >>> | |
>         >         >>> [LMA2]--[LMA]==========[MAG]
>         >         >>> | |
>         >         >>> [LMA3]---
>         >         >>>
>         >         >>>
>         >         >>> Along the lines of:
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>         >         >>
>         >         >> This is in the proposed NETEXT charter already.
>         >         >>
>         >         >>> 2. Multicast Support in Proxy Mobile IPv6
>         >         >>>
>         >         >>> We need an informational specification on how
>         multicast
>         >         support can be
>         >         >>> enabled in Proxy Mobile IPv6 environment. Behcet
>         has done
>         >         extensive
>         >         >>> analysis
>         >         >>> on
>         >         >>> this. This is required and critical for enabling
>         any
>         >         multicast services.
>         >         >>> However,
>         >         >>> Behcet may disagree with the scope of the work.
>         >         >>
>         >         >> See above.
>         >         >>
>         >         >>> 3. Bulk Registration Support
>         >         >>>
>         >         >>> This is a simple extension which helps in
>         signaling
>         >         optimization, along
>         >         >>> the
>         >         >>> lines of:
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>         >         >>
>         >         >> This is in the charter as well.
>         >         >>
>         >         >>> 4. Partial Failover Support
>         >         >>>
>         >         >>> We need a mechanism to notify the peer on revoke
>         a partial
>         >         set of
>         >         >>> bindings.
>         >         >>>
>         >         >>>
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>         >         >>> txt
>         >         >>
>         >         >> Hmm. Ok. This needs more discussion.
>         >         >>
>         >         >>> 5. Group Identifier Support for Proxy Mobile
>         IPv6
>         >         >>>
>         >         >>> This provides a simple and a generic semantic
>         for
>         >         assigning a group
>         >         >>> identifier
>         >         >>> to a mobile node's binding. GTP has very similar
>         >         semantics, Connexion Set
>         >         >>> Id.
>         >         >>> Both #3 and #4 can leverage this. Additionally,
>         in load
>         >         balancer systems
>         >         >>> where
>         >         >>> the load balancer is in path for all signaling
>         messages,
>         >         it can use this
>         >         >>> as
>         >         >>> a
>         >         >>> tag for redirecting the message.
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>         >         >>
>         >         >> Since the bulk registration work is in the
>         charter, can't
>         >         you do the
>         >         >> sensible design (whatever it is) under that?
>         There is no
>         >         requirement that
>         >         >> one charter item equals one document.
>         >         >>
>         >         >>> 6. Virtual-Interface Support on IP host for
>         supporting
>         >         Inter-tech
>         >         >>> handoffs:
>         >         >>>
>         >         >>>
>         >         >>> RFC-5213 supports handoff between two
>         interfaces. The
>         >         ability to move
>         >         >>> prefixes between interfaces. In other words
>         address
>         >         continuity is assured
>         >         >>> with any IPv6 host on the planet and with
>         absolutely no
>         >         changes. This
>         >         >>> meets
>         >         >>> even Dave's comment, that "no changes to any
>         IETF RFC's.".
>         >         Now, what is
>         >         >>> not assured is the aspect of session continuity.
>         Which
>         >         requires a virtual
>         >         >>> interface implementation on the host, by binding
>         the
>         >         address/prefix to a
>         >         >>> virtual interface and by not exposing the
>         physical
>         >         interface or by hiding
>         >         >>> the handoff events from the layer-3 stack.
>         >         >>>
>         >         >>> In essence, we need an informational
>         specification which
>         >         provides some
>         >         >>> general guidance to how to leverage the feature
>         support
>         >         provided in
>         >         >>> RFC-5213,
>         >         >>> along the lines of:
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>         >         >>
>         >         >> This is part of the discussion that we need to
>         finish. But
>         >         I plan to let
>         >         >> the
>         >         >> rest of the stuff move forward even before we
>         have done
>         >         that.
>         >         >>
>         >         >>
>         >         >>> 7. Route Optimization for Proxy Mobile IPv6
>         >         >>>
>         >         >>> There were atleast 4 drafts in this area on
>         Route
>         >         Optimization. Marco
>         >         >>> Liebsch
>         >         >>> analyzed this exensively:
>         >         >>>
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>         >         >>>
>         >         >>>
>         >         >>>
>         >
>         http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>         
>         >         >>> txt
>         >         >>
>         >         >> This is in the charter.
>         >         >>
>         >         >>> 8. Prefix Management in Proxy Mobile IPv6
>         support
>         >         >>>
>         >         >>> Proxy Mobile IPv6 allows the assignment of
>         multiple home
>         >         network prefixes
>         >         >>> to a given mobile node's interface. It might be
>         useful to
>         >         specify how the
>         >         >>> LMA manages this aspects. It can potentially use
>         DHCP PD,
>         >         Local Pools or
>         >         >>> AAA to manage this aspect. Behcet has one draft
>         on this.
>         >         >>
>         >         >> I'm not personally sold on this particular work.
>         But again,
>         >         this could be
>         >         >> something to consider.
>         >         >>
>         >         >>> 9. Partial Handoff Support
>         >         >>>
>         >         >>> We are missing some semantics in 5213 for moving
>         a subset
>         >         of the prefixes
>         >         >>> between interfaces as part of the inter-tech
>         handoff. This
>         >         is about
>         >         >>> defining
>         >         >>> a new handoff value. This allows partial flow
>         management,
>         >         but moving the
>         >         >>> flows associated to a prefix, as a whole group.
>         >         >>>
>         >         >>>
>         >         >>>
>         >
>         http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>         >         >>
>         >         >> A part of the topic we still need to discuss...
>         >         >>
>         >         >>> 10. CMIPv4/PMIP Interworking
>         >         >>>
>         >         >>> This is probably required to specify how an
>         IPv4-only can
>         >         move between
>         >         >>> CMIP and PMIP environments.
>         >         >>>
>         >         >>>
>         >         >>>
>         >         >>>
>         >
>         http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>         >         >>> meghana-netlmm-pmipv6-mipv4-00.txt
>         >         >>
>         >         >> Client MIPv6 and Proxy MIPv6 interoperability is
>         already in
>         >         the NETLMM
>         >         >> charter, but this work is presumably about
>         interaction with
>         >         MIPv4. Might
>         >         >> be
>         >         >> useful work, I wouldn't mind if this was done in
>         NETEXT at
>         >         some point. Is
>         >         >> this crucial to be in the first revision of the
>         WG's
>         >         charter?
>         >         >>
>         >         >>> 11. NEMO/Prefix delegation to Mobile Node in
>         Proxy Mobile
>         >         IPv6
>         >         >>
>         >         >> Can you expand on this?
>         >         >>
>         >         >> Jari
>         >         >>
>         >         >> _______________________________________________
>         >         >> 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
>         >         >
>         >         >
>         >
>         >         _______________________________________________
>         >         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/
>         --
>           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
>         +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
> 
> -- 
> Internet Management Technology Lab, Sungkyunkwan University. 
> Jong-Hyouk Lee.
> 
> #email: jonghyouk (at) gmail (dot) com 
> #webpage: http://hurryon.googlepages.com/
-- 
   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/20090420/64fb5528/attachment.bin>

From: admin at ultimatecoachinginternational.com (Ultimate Coaching International)
Date: Mon, 20 Apr 2009 18:09:48 +0800
Subject: [Netext] <Adv> Become an ICF-Certified Professional Coach and be trained personally by the Founder of Erickson College International
Message-ID: <[email-masked]>

To All Professionals

For 2009 Only :  *Early Birds :  less S$200 per module,  plus S$50 book voucher. 

*Registered and Paid before 2 May 09 

Arts & Science of Coaching 

Incorporating 2 very powerful brain-based Behavior-Change Techniques :   Solution-Focused Methods and NLP 

For 2009 Only,  all modules will be personally conducted by Dr Marilyn Atkinson, PhD,  Founder of Erickson Coaching International 

Venue :   a Hotel in Singapore (To be Advised) 

Full Fee of entire 16-Day program (4 Modules)   :  S$7,500 payable by 4 Installments of S$1,880   (No GST Required) 

Module 1 :  30 May 09 ? 2 Jun 09 

Module 2 :  10-13 Sep 09 

Module 3 and 4 :  28 Nov 09 ? 6 Dec 09 

This ICF-Approved Professional Qualification training by Erickson College International can guide you to becoming highly skillful in self-coaching, coaching your friends/family,  influencing your clients/colleagues/bosses.    Complete the rigorous skills requirement set up by "International Coaching Federation" & you will be on your way to becoming a world-recognized "Professional Accredited Life Coach".    www.coachfederation.org/ICF 

Erickson Coaching International?s  Arts & Science of Coaching is very popular in Canada, Europe, Russia and China.   www.erickson.edu 
The comprehensive program is specially designed by Dr Marilyn Atkinson, PhD,  over 25 years as a therapist and coaching experience. 
This course will definitely be a ?lives-changing? experience for you, it is specially designed for deep change. 

Best Regards, 
Joanne Ng, Tel (65) 6546 5801 
Ultimate Coaching International     
23 Loyang View  Singapore 507247 
joanne at UltimateCoachingInternational.com 

To UnSubscribe,  simply reply to this email with Subject : UnSubscribe 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090420/6f9a13e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2452 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090420/6f9a13e7/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 4090 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090420/6f9a13e7/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Registrationform.doc
Type: application/msword
Size: 34816 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090420/6f9a13e7/attachment-0001.doc>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Fri, 17 Apr 2009 22:46:41 +0200
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

On 4/17/09 10:33 AM, "ext Marco Liebsch" <marco.liebsch at nw.neclab.eu> wrote:

>> 
>> If you refer to AAA & DNS as the out of band signaling approach e.g.
>> to solve load balancing, I think I stated already multiple times that
>> it does not really work well enough. "LMA" / load balancer is the node
>> with most up to date information of the load situation. You don't want
>> to 1) deploy a new MAG-LMA interface without interoperability
>> guarantees to keep the MAG informed about the LMA status, 2) rely on
>> completely un-deterministic route via DNS/AAA or 3) always depend on
>> external infrastructure support.
> Do you consider also protocol work between LMAs in scope of NetExt to learn
> about other LMAs load situation? I think an LMA needs to know where to
> refer to.
> Or where does this information come from?

I don't know if we want to specify how LMAs learn about the load-conditions
of other LMAs. This could be left unspecified and expect that there is some
OOB means by which an LMA knows the target LMA to which to refer a PBU to.

-Raj

> 
> marco
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 17 Apr 2009 11:37:21 -0700 (PDT)
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

On Fri, 17 Apr 2009, Marco Liebsch wrote:

> Do you consider also protocol work between LMAs in scope of NetExt to learn
> about other LMAs load situation? I think an LMA needs to know where to refer 
> to.
> Or where does this information come from?
>

I think there are other protocols such as DFP (Dynamic Feedback Protocol)
for such load representation. That are vendor specific solutions, or
other standards protocols, can also be used. The LMA Redirect semantic
should have little dependency on that.

Regards
Sri

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 17 Apr 2009 11:35:35 -0700 (PDT)
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Vijay:

On Fri, 17 Apr 2009, Vijay Devarapalli wrote:

> Well, the bottom line is that there are many of ways doing this load
> balancing. If we are talking about load balancing across application
> blades in a chassis, there is no way an explicit redirect can be
> superior to a solution that does not expose this load balancing to any
> external entity, including the MAG. So that's my main issue with the
> "Standards Track" status for this document.
>

I think I told earlier, there is no load balancing solution
possible without requiring the exposed LMA to be in path.
These are the missing semantics. We need the ability for the
LMA to redirect the session.

W.r.t your comment that this should not be on "standard track".
I've a problem with your stand:

- We have a HA Reliability Work, this is on standard track.
   You are authoring this.

- We have HA Switchover Spec [RFC-5142], this is on standards track.
   You authored this. All though, for this any vendor would support
   Active/Standby model, for servicing the HA or rebooting the HA,
   you dont need this to be exposed to the MN. We have HA Redundancy
   solution for atleast 10 years.

- We have RFC-4433, a similar solution for Mobile IPv4. Its used in
   CDMA world. This is on Standards Track doc.

Now, I wonder, what is your argument basis, to say, this one item
stands out and should not be on Standards Track ? Please explain !

The issue, we are missing the semantics in Proxy Mobile IPv6,
for dynamically assigning an LMA and redirecting a session. Also,
PMIP similar GTP protocol has such semantics.

> At the minimum, the document has to clearly explain what it is trying to
> solve. And it has to recognize that there are other solutions possible
> for the load balancing.
>

Jouni's document is trying to provide a solution with the following
goals in mind:

- Expose a single address for the entire LMA infrastructure
- Allow the primary LMA to dynamically assign the LMA for a
   given session along the lines of RFC-4433, Dynamic Home
   Agent Assignment.
- Not require the primary LMA to be in path, once the assignment
   is done
- Not require multiple MIP signaling round trips after each
   assignment.

The document can certainly recognise that there are other solutions
possible, if exposed LMA stickiness is not of concern.

Regards
Sri

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Fri, 17 Apr 2009 14:10:41 -0400
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Well, the bottom line is that there are many of ways doing this load
balancing. If we are talking about load balancing across application
blades in a chassis, there is no way an explicit redirect can be
superior to a solution that does not expose this load balancing to any
external entity, including the MAG. So that's my main issue with the
"Standards Track" status for this document.

At the minimum, the document has to clearly explain what it is trying to
solve. And it has to recognize that there are other solutions possible
for the load balancing.

Vijay 

> -----Original Message-----
> From: Yungui Wang [mailto:w52006 at huawei.com] 
> Sent: Wednesday, April 15, 2009 7:44 PM
> To: Vijay Devarapalli; 'Sri Gundavelli'
> Cc: netext at mail.mobileip.jp
> Subject: RE: [Netext] LMA redirection (was RE: WG Review: 
> Network-Based MobilityExtensions (netext))
> 
> 
> Hello,
> 
> This topic is interesting. Regarding of implementation, you 
> both mentioned 
> mechanisms are feasible and deployed somewhere. However, whether 
> transparently or using explicit redirect message, I think, is 
> mostly fited
> to the 
> case of blades(LMA) in a chassis. If each LMA is a separate 
> box,  another 
> mechanism that MAG re-selects LMA may be more common.  Propose that 
> is reflected into the charter or draft as well.
> 
> B.R.
> Yungui 
>   
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Vijay 
> > Devarapalli
> > Sent: Thursday, April 16, 2009 6:15 AM
> > To: Sri Gundavelli
> > Cc: netext at mail.mobileip.jp
> > Subject: [Netext] LMA redirection (was RE: WG Review: 
> > Network-Based MobilityExtensions (netext))
> > 
> > Hi Sri, 
> > 
> > > Ok. How can we prove it either way. Lets hear from the
> > > WG, if how many other folks have concerns keeping it on
> > > standards track.
> > > 
> > > Either way, as I was told the planned charter evolved
> > > based on the BOF WG feedback.
> > 
> > There was less than 5 minutes for this presentation. I 
> > couldn't even go
> > to the mike and saying something. But I had already given 
> feedback on
> > this to the authors, to the chairs and to you offline before 
> > and during
> > the IETF meeting. 
> > 
> > Before the BoF, there hasn't been any discussion on this on 
> > the mailing
> > list. 
> > 
> > I was actually surprised to see this on the charter.
> > 
> > > >> and we need a ratified well thought out
> > > >> solution and not with the purpose of gathering more practical
> > > >> data via experimental track.
> > > >
> > > > An experimental RFC does not mean it is intended for 
> > > testbeds and such.
> > > > It just means we are not sure if this is *the* solution.
> > > >
> > > 
> > > But, I'm sure we need this :), just as you are not sure.
> > 
> > FWIW, there a lot of vendors who already do this kind of load 
> > balancing
> > across blades in a chassis without modifying the protocol exchanges.
> > What more proof do you need?
> > 
> > Vijay
> > 
> > > 
> > > Lets hear from the WG ...
> > > 
> > > Thanks
> > > Sri
> > > 
> > > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Fri, 17 Apr 2009 17:33:12 +0200
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni,

jouni korhonen schrieb:
> Hi Marco,
>
> Thanks for your views on this topic.
>
> On Apr 17, 2009, at 11:41 AM, Marco Liebsch wrote:
>
>> Hi Sri, Vijay, all,
>>
>> as more opinions have been requested, I'd like to refer to my 
>> comments from 4th March
>> about the associated PS. For deployment of PMIPv6, I see the need for 
>> functions such as
>> load balancing, failure recovery, etc. to care about scalability and 
>> availability.
>> What's being discussed and planned for NetExt seems to have a very 
>> dedicated use case to
>> handle redirection on the fly. For load balancing, failure recovery, 
>> etc, I see some backend
>> mechanisms doing that. Load balancing is being done at initial 
>> registration. Failure recovery,
>> well, a PMIPv6 extension won't work in case the originally assigned 
>> LMA is dead. I am sure
>> that there is some useful case where the planned PMIPv6 extension can 
>> be used. But I have
>> the feeling that this use case can be handled also by some external 
>> mechanisms, i.e. out of
>> band signaling. If there is sufficient support and valid arguments 
>> why a PMIPv6 extension needs
>> to handle this, I am ok with such work.
>
> If you refer to AAA & DNS as the out of band signaling approach e.g. 
> to solve load balancing, I think I stated already multiple times that 
> it does not really work well enough. "LMA" / load balancer is the node 
> with most up to date information of the load situation. You don't want 
> to 1) deploy a new MAG-LMA interface without interoperability 
> guarantees to keep the MAG informed about the LMA status, 2) rely on 
> completely un-deterministic route via DNS/AAA or 3) always depend on 
> external infrastructure support.
Do you consider also protocol work between LMAs in scope of NetExt to learn
about other LMAs load situation? I think an LMA needs to know where to 
refer to.
Or where does this information come from?

marco

>
>
> Cheers,
>     Jouni
>
>
>
>>
>>
>> Just my 2 cents,
>> marco.
>>
>>
>> Vijay Devarapalli schrieb:
>>> Hi Sri,
>>>
>>>> Ok. How can we prove it either way. Lets hear from the
>>>> WG, if how many other folks have concerns keeping it on
>>>> standards track.
>>>>
>>>> Either way, as I was told the planned charter evolved
>>>> based on the BOF WG feedback.
>>>>
>>>
>>> There was less than 5 minutes for this presentation. I couldn't even go
>>> to the mike and saying something. But I had already given feedback on
>>> this to the authors, to the chairs and to you offline before and during
>>> the IETF meeting.
>>> Before the BoF, there hasn't been any discussion on this on the mailing
>>> list.
>>> I was actually surprised to see this on the charter.
>>>
>>>
>>>>>> and we need a ratified well thought out
>>>>>> solution and not with the purpose of gathering more practical
>>>>>> data via experimental track.
>>>>>>
>>>>> An experimental RFC does not mean it is intended for
>>>> testbeds and such.
>>>>
>>>>> It just means we are not sure if this is *the* solution.
>>>>>
>>>>>
>>>> But, I'm sure we need this :), just as you are not sure.
>>>>
>>>
>>> FWIW, there a lot of vendors who already do this kind of load balancing
>>> across blades in a chassis without modifying the protocol exchanges.
>>> What more proof do you need?
>>>
>>> Vijay
>>>
>>>
>>>> Lets hear from the WG ...
>>>>
>>>> Thanks
>>>> Sri
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Fri, 17 Apr 2009 13:47:39 +0300
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Thanks for your views on this topic.

On Apr 17, 2009, at 11:41 AM, Marco Liebsch wrote:

> Hi Sri, Vijay, all,
>
> as more opinions have been requested, I'd like to refer to my  
> comments from 4th March
> about the associated PS. For deployment of PMIPv6, I see the need  
> for functions such as
> load balancing, failure recovery, etc. to care about scalability and  
> availability.
> What's being discussed and planned for NetExt seems to have a very  
> dedicated use case to
> handle redirection on the fly. For load balancing, failure recovery,  
> etc, I see some backend
> mechanisms doing that. Load balancing is being done at initial  
> registration. Failure recovery,
> well, a PMIPv6 extension won't work in case the originally assigned  
> LMA is dead. I am sure
> that there is some useful case where the planned PMIPv6 extension  
> can be used. But I have
> the feeling that this use case can be handled also by some external  
> mechanisms, i.e. out of
> band signaling. If there is sufficient support and valid arguments  
> why a PMIPv6 extension needs
> to handle this, I am ok with such work.

If you refer to AAA & DNS as the out of band signaling approach e.g.  
to solve load balancing, I think I stated already multiple times that  
it does not really work well enough. "LMA" / load balancer is the node  
with most up to date information of the load situation. You don't want  
to 1) deploy a new MAG-LMA interface without interoperability  
guarantees to keep the MAG informed about the LMA status, 2) rely on  
completely un-deterministic route via DNS/AAA or 3) always depend on  
external infrastructure support.

Cheers,
	Jouni

>
>
> Just my 2 cents,
> marco.
>
>
> Vijay Devarapalli schrieb:
>> Hi Sri,
>>
>>> Ok. How can we prove it either way. Lets hear from the
>>> WG, if how many other folks have concerns keeping it on
>>> standards track.
>>>
>>> Either way, as I was told the planned charter evolved
>>> based on the BOF WG feedback.
>>>
>>
>> There was less than 5 minutes for this presentation. I couldn't  
>> even go
>> to the mike and saying something. But I had already given feedback on
>> this to the authors, to the chairs and to you offline before and  
>> during
>> the IETF meeting.
>> Before the BoF, there hasn't been any discussion on this on the  
>> mailing
>> list.
>> I was actually surprised to see this on the charter.
>>
>>
>>>>> and we need a ratified well thought out
>>>>> solution and not with the purpose of gathering more practical
>>>>> data via experimental track.
>>>>>
>>>> An experimental RFC does not mean it is intended for
>>> testbeds and such.
>>>
>>>> It just means we are not sure if this is *the* solution.
>>>>
>>>>
>>> But, I'm sure we need this :), just as you are not sure.
>>>
>>
>> FWIW, there a lot of vendors who already do this kind of load  
>> balancing
>> across blades in a chassis without modifying the protocol exchanges.
>> What more proof do you need?
>>
>> Vijay
>>
>>
>>> Lets hear from the WG ...
>>>
>>> Thanks
>>> Sri
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Fri, 17 Apr 2009 10:41:15 +0200
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri, Vijay, all,

as more opinions have been requested, I'd like to refer to my comments 
from 4th March
about the associated PS. For deployment of PMIPv6, I see the need for 
functions such as
load balancing, failure recovery, etc. to care about scalability and 
availability.
What's being discussed and planned for NetExt seems to have a very 
dedicated use case to
handle redirection on the fly. For load balancing, failure recovery, 
etc, I see some backend
mechanisms doing that. Load balancing is being done at initial 
registration. Failure recovery,
well, a PMIPv6 extension won't work in case the originally assigned LMA 
is dead. I am sure
that there is some useful case where the planned PMIPv6 extension can be 
used. But I have
the feeling that this use case can be handled also by some external 
mechanisms, i.e. out of
band signaling. If there is sufficient support and valid arguments why a 
PMIPv6 extension needs
to handle this, I am ok with such work.

Just my 2 cents,
marco.

Vijay Devarapalli schrieb:
> Hi Sri, 
>
>   
>> Ok. How can we prove it either way. Lets hear from the
>> WG, if how many other folks have concerns keeping it on
>> standards track.
>>
>> Either way, as I was told the planned charter evolved
>> based on the BOF WG feedback.
>>     
>
> There was less than 5 minutes for this presentation. I couldn't even go
> to the mike and saying something. But I had already given feedback on
> this to the authors, to the chairs and to you offline before and during
> the IETF meeting. 
>
> Before the BoF, there hasn't been any discussion on this on the mailing
> list. 
>
> I was actually surprised to see this on the charter.
>
>   
>>>> and we need a ratified well thought out
>>>> solution and not with the purpose of gathering more practical
>>>> data via experimental track.
>>>>         
>>> An experimental RFC does not mean it is intended for 
>>>       
>> testbeds and such.
>>     
>>> It just means we are not sure if this is *the* solution.
>>>
>>>       
>> But, I'm sure we need this :), just as you are not sure.
>>     
>
> FWIW, there a lot of vendors who already do this kind of load balancing
> across blades in a chassis without modifying the protocol exchanges.
> What more proof do you need?
>
> Vijay
>
>   
>> Lets hear from the WG ...
>>
>> Thanks
>> Sri
>>
>>
>>     
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Thu, 16 Apr 2009 15:11:04 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <1239900013.5254.37.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost> <[email-masked]> <1239900013.5254.37.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,
? As I was saying before what you want is to have the MAG to be MR. Then MAG would move.
? The idea is conceptually fine maybe it could even work. Just write a draft about it.

Regards,

Behcet

________________________________
From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
To: john.zhao <yuankui.zhao at gmail.com>
Cc: netext at mail.mobileip.jp
Sent: Thursday, April 16, 2009 11:40:13 AM
Subject: Re: [Netext] next steps for netext

Hi John,

El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?:
> Hi Carlos,
> 
> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> > Hi Ryuji,
> >? ? ? ? Sorry for the delayed reply. Comments below.
> >
> > El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
> >> Hello Carlos,
> >>
> >> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
> >>
> >> > Hi Behcet,
> >> >
> >> > I've quickly checked the document. I think it does address the same
> >> > problem I was referring to. This draft addresses the problem of
> >> > delegating a prefix to a router that attaches to a PMIPv6 domain, so
> >> > it can provide connectivity to nodes attached to it. I think this was
> >> > already discussed in a past meeting (a draft with the problem
> >> > statement)
> [John.zhao]Yes.http://tools.ietf.org/html/draft-zhao-nemo-limitations-ps-00.
> 
> >> > and I mentioned that IMHO this can basically be achieved by
> >> > just using plain NEMO support on the router. The only difference in
> >> > this draft is that it doesn't impose the router to be a NEMO RFC3963
> >> > MR, although still it needs to do some additional things that a normal
> >> > router (not mobile) doesn't. Anyway, I'm not against this type of
> >> > support if there are scenarios in which it's useful.
> >>
> >> In the doc, we just specify how to get mobile network prefix from DHCP-
> >> DR.
> >> DHCP-PD is that normal router does, right?
> >
> > Yes, my point was more related with the benefits of doing this instead
> > of just using NEMO.
> [John.zhao]My two cents. About the benefits for doing this, it is for
> PMIPv6 domian control as mentioned in Page 8 of this draft."This
> document recommends that Proxy Mobile IPv6 controls the prefix
> management ......". That is from network perspective. On the
> contrary,customers can use router without NEMO enble under both of
> fixed network and pmip network.? Of course, NEMO can make router be
> benefited if it would like to be roamed. But no one can claim network
> must support the NEMO.
> >
> >>
> >> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> >> > bit beyond that, since what I want to enable is node to be able to
> >> > benefit from network based localised mobility support not only when
> >> > roaming between fixed points of attachment (this is what RFC5213 does
> >> > today) but also when roaming between fixed and mobile points of
> >> > attachment. What people do think about this scenario?
> >>
> >> I don't know what is fixed and mobile points of attachment. You can
> >> clarify these.
> >>
> >
> > I've sent another e-mail regarding this (hope there is more clear).
> > Summarising, what I call a fixed point of attachment is a MAG as it is
> > defined in RFC5213 that does not move. I call a mobile point of
> > attachment a MAG that would also be able to move (like an MR) within the
> > PMIPv6 domain.
> [John.zhao]So,would you like extend the MAG capability to a moving
> router,right? If thus, where is the LMA for this MAG?

Well, it can be seen the other way around, to extend the MAG capability
to be mobile...

Carlos

> 
> 
>? ? ? ? Best Rgds,
> Thanks,
> 
> John.zhao
> >
> > Thanks,
> >
> > Carlos
> >
> >> ryuji
> >>
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Carlos
> >> >
> >> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >> >> Hi Carlos,
> >> >>? Check this out:
> >> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
> >> >> support-00
> >> >>
> >> >> Regards,
> >> >>
> >> >> Behcet
> >> >>
> >> >> ________________________________
> >> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >> >> To: Jari Arkko <jari.arkko at piuha.net>
> >> >> Cc: netext at mail.mobileip.jp
> >> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
> >> >> Subject: Re: [Netext] next steps for netext
> >> >>
> >> >> Hi Jari, all,
> >> >>
> >> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> >> >> personal view on that is that it'd be nice to extend PMIPv6 to
> >> >> support
> >> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
> >> >> to also move (like MRs, but without even supporting RFC3963), so an
> >> >> MR
> >> >> would be able to move between fixed and mobile MAGs without changing
> >> >> its IP address (same support RFC5213 gives now). There are some
> >> >> interesting scenarios that could benefit from this.
> >> >>
> >> >> What do others think? It is interesting to work on this?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Carlos
> >> >>
> >> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> >>> Sri,
> >> >>>
> >> >>> Thanks for your input. Inline:
> >> >>>
> >> >>>> I've a concern with the planned charter. The list is too random and
> >> >>>> cherry picked and I dont believe proper input from all the folks
> >> >>>> went
> >> >>>> into
> >> >>>> this. There are many other items that are required for a reasonable
> >> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
> >> >>>> the last 2
> >> >>>> years, some of them that were left out in the base spec, some
> >> >>>> that we
> >> >>>> realized as gaps when compared to other SDO protocols and some as
> >> >>>> optimizations that we realized while implementing PMIP6, these
> >> >>>> items
> >> >>>> should be in the initial scope.
> >> >>>>
> >> >>>> I understand the charter needs to be limited in scope, but just 3
> >> >>>> or 4
> >> >>>> random items, I'm not sure if this helps in short term PMIP6
> >> >>>> requirements.
> >> >>>> I've no issue with the currently listed items, but there are
> >> >>>> other items
> >> >>>> that should get equal or higher priority.
> >> >>>
> >> >>> I have no problem with adding more. Even the charter says new
> >> >>> things can
> >> >>> be
> >> >>> added.
> >> >>>
> >> >>> However, from a process perspective what I did was to take the
> >> >>> proposal on
> >> >>> the table, i.e., the full BOF scope and see what parts of that we
> >> >>> already
> >> >>> have an agreement on. I didn't include other things that were not
> >> >>> discussed
> >> >>> in the BOF. Maybe that would have been useful, but they were not
> >> >>> on the
> >> >>> table.
> >> >>>
> >> >>> We could add more items now, if there's general agreement that those
> >> >>> things
> >> >>> are useful. However, I do not want to declare an open season on
> >> >>> doing
> >> >>> everything. We pick a reasonable subset of all proposed work,
> >> >>> based on
> >> >>> priorities, community agreement that they are the right things to
> >> >>> do,
> >> >>> management reasons to ensure that we are not doing too much, etc.
> >> >>>
> >> >>>> For example, item #6, is absolutely required, from the
> >> >>>> perspective of
> >> >>>> having a complete specification of 5213. There we allowed a
> >> >>>> mobile node
> >> >>>> to
> >> >>>> perform handoff betweek two interfaces. We defined all the hooks
> >> >>>> on the
> >> >>>> network side, but we did not provide how a terminal vendor can
> >> >>>> support
> >> >>>> that. A simple informational draft on how some one move prefixes
> >> >>>> between
> >> >>>> interfaces will greatly help. Some guidance on how to create a
> >> >>>> virtual
> >> >>>> interface and also some related notes for each platform (Linux,
> >> >>>> BSD,
> >> >>>> Android ..etc). This should not fall in the controversial
> >> >>>> discussion
> >> >>>> scope
> >> >>>> of same address on two interfaces etc, thats a different problem,
> >> >>>> or
> >> >>>> about
> >> >>>> the issue of enhancing mobile node's capabilities. This is just
> >> >>>> informational work, required to leverage what 5213 already
> >> >>>> supports.
> >> >>>
> >> >>> I suspect this is about the scoping of the handoff work. Lets try to
> >> >>> figure
> >> >>> out what makes sense (I personally believe the above item makes
> >> >>> sense, for
> >> >>> instance) and what doesn't.
> >> >>>
> >> >>> The fact that these parts were not in the charter was not a
> >> >>> declaration
> >> >>> that
> >> >>> we're dismissing them. Its just that we didn't finish the
> >> >>> discussion, but
> >> >>> I
> >> >>> still wanted to let the other things move forward.
> >> >>>
> >> >>>> Item #2, is required. The multimob BOF raised some issues, we
> >> >>>> need to
> >> >>>> show how multicast services can be enabled in PMIP network. May
> >> >>>> be this
> >> >>>> wont require extensions, a simple draft covering those aspects
> >> >>>> will help.
> >> >>>
> >> >>> As you may recall, in the Multimob BOF we did not have an
> >> >>> agreement on
> >> >>> what
> >> >>> exactly is needed, if anything. My own conclusion is that we
> >> >>> probably need
> >> >>> at least an informational document that explains how to use RFC
> >> >>> 5213 for
> >> >>> multicast. I think we discussed the possibility of doing this as
> >> >>> some kind
> >> >>> of AD sponsored document or in one of the relevant WGs, as a joint
> >> >>> work
> >> >>> between PMIP and multicast experts.
> >> >>>
> >> >>> I'm on the fence about adding this work to the charter right now,
> >> >>> mainly
> >> >>> because the BOF back then was very inconclusive. I'd be happier if
> >> >>> I saw
> >> >>> an
> >> >>> actual well written draft from say you and some of the multicast
> >> >>> experts.
> >> >>> There's no problem moving good documents forward, even if they are
> >> >>> not in
> >> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> >>> maintenance like item for this in one of the WG charters either.
> >> >>>
> >> >>>> I think, the charter should be bit more relaxed and more
> >> >>>> extensive. As I
> >> >>>> see it, atleast the folks are interested in doing the work. We
> >> >>>> should add
> >> >>>> atleast 4 or 5 more items to this list.
> >> >>>
> >> >>> Generally speaking IETF WG charters give specific work items that
> >> >>> the WG
> >> >>> should work on. I had hoped that the charter text:
> >> >>>
> >> >>> "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."
> >> >>>
> >> >>> gives an indication that we intend to do more! I am also
> >> >>> personally very
> >> >>> happy to add more items to the group's charter. All in all, I do
> >> >>> know that
> >> >>> the current charter is a bit on the thin side -- mostly because the
> >> >>> multihoming/interaccess issue is under discussion.
> >> >>>
> >> >>> There's also the question of general maintenance items. Some IETF
> >> >>> WGs have
> >> >>> a
> >> >>> general work item to fix problems and issue updates to existing
> >> >>> specifications. I think we need to do that for Proxy Mobile IPv6
> >> >>> as well.
> >> >>> But we have not decided whether that item should go to NETLMM or
> >> >>> NETEXT WG
> >> >>> yet. Please rest assured that the work will be possible regardless
> >> >>> of
> >> >>> this.
> >> >>>
> >> >>>> 1. Dynamic LMA Assignment
> >> >>>>
> >> >>>> In blade architecture systems or in a load balancer
> >> >>>> configuration, the
> >> >>>> PDNGW
> >> >>>> should have the ability to dynamically assign a LMA on the fly,
> >> >>>> along the
> >> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >> >>>> [RFC-4433].
> >> >>>> Currently, GTP provides such semantics and this is a important
> >> >>>> requirement
> >> >>>> for deployment. Here the goal is to
> >> >>>>
> >> >>>> a.) Expose a single IP address to the SGW
> >> >>>> b.) The exposed IP address should not be in path once the
> >> >>>> assignment is
> >> >>>> done.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> [LMA1]---
> >> >>>> | |
> >> >>>> [LMA2]--[LMA]==========[MAG]
> >> >>>> | |
> >> >>>> [LMA3]---
> >> >>>>
> >> >>>>
> >> >>>> Along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >> >>>
> >> >>> This is in the proposed NETEXT charter already.
> >> >>>
> >> >>>> 2. Multicast Support in Proxy Mobile IPv6
> >> >>>>
> >> >>>> We need an informational specification on how multicast support
> >> >>>> can be
> >> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >> >>>> analysis
> >> >>>> on
> >> >>>> this. This is required and critical for enabling any multicast
> >> >>>> services.
> >> >>>> However,
> >> >>>> Behcet may disagree with the scope of the work.
> >> >>>
> >> >>> See above.
> >> >>>
> >> >>>> 3. Bulk Registration Support
> >> >>>>
> >> >>>> This is a simple extension which helps in signaling optimization,
> >> >>>> along
> >> >>>> the
> >> >>>> lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >> >>>
> >> >>> This is in the charter as well.
> >> >>>
> >> >>>> 4. Partial Failover Support
> >> >>>>
> >> >>>> We need a mechanism to notify the peer on revoke a partial set of
> >> >>>> bindings.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> Hmm. Ok. This needs more discussion.
> >> >>>
> >> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
> >> >>>>
> >> >>>> This provides a simple and a generic semantic for assigning a group
> >> >>>> identifier
> >> >>>> to a mobile node's binding. GTP has very similar semantics,
> >> >>>> Connexion Set
> >> >>>> Id.
> >> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
> >> >>>> systems
> >> >>>> where
> >> >>>> the load balancer is in path for all signaling messages, it can
> >> >>>> use this
> >> >>>> as
> >> >>>> a
> >> >>>> tag for redirecting the message.
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >> >>>
> >> >>> Since the bulk registration work is in the charter, can't you do the
> >> >>> sensible design (whatever it is) under that? There is no
> >> >>> requirement that
> >> >>> one charter item equals one document.
> >> >>>
> >> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >> >>>> handoffs:
> >> >>>>
> >> >>>>
> >> >>>> RFC-5213 supports handoff between two interfaces. The ability to
> >> >>>> move
> >> >>>> prefixes between interfaces. In other words address continuity is
> >> >>>> assured
> >> >>>> with any IPv6 host on the planet and with absolutely no changes.
> >> >>>> This
> >> >>>> meets
> >> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
> >> >>>> what is
> >> >>>> not assured is the aspect of session continuity. Which requires a
> >> >>>> virtual
> >> >>>> interface implementation on the host, by binding the address/
> >> >>>> prefix to a
> >> >>>> virtual interface and by not exposing the physical interface or
> >> >>>> by hiding
> >> >>>> the handoff events from the layer-3 stack.
> >> >>>>
> >> >>>> In essence, we need an informational specification which provides
> >> >>>> some
> >> >>>> general guidance to how to leverage the feature support provided in
> >> >>>> RFC-5213,
> >> >>>> along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >> >>>
> >> >>> This is part of the discussion that we need to finish. But I plan
> >> >>> to let
> >> >>> the
> >> >>> rest of the stuff move forward even before we have done that.
> >> >>>
> >> >>>
> >> >>>> 7. Route Optimization for Proxy Mobile IPv6
> >> >>>>
> >> >>>> There were atleast 4 drafts in this area on Route Optimization.
> >> >>>> Marco
> >> >>>> Liebsch
> >> >>>> analyzed this exensively:
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >> >>>>
> >> >>>>
> >> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> This is in the charter.
> >> >>>
> >> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
> >> >>>>
> >> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
> >> >>>> prefixes
> >> >>>> to a given mobile node's interface. It might be useful to specify
> >> >>>> how the
> >> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
> >> >>>> Pools or
> >> >>>> AAA to manage this aspect. Behcet has one draft on this.
> >> >>>
> >> >>> I'm not personally sold on this particular work. But again, this
> >> >>> could be
> >> >>> something to consider.
> >> >>>
> >> >>>> 9. Partial Handoff Support
> >> >>>>
> >> >>>> We are missing some semantics in 5213 for moving a subset of the
> >> >>>> prefixes
> >> >>>> between interfaces as part of the inter-tech handoff. This is about
> >> >>>> defining
> >> >>>> a new handoff value. This allows partial flow management, but
> >> >>>> moving the
> >> >>>> flows associated to a prefix, as a whole group.
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >> >>>
> >> >>> A part of the topic we still need to discuss...
> >> >>>
> >> >>>> 10. CMIPv4/PMIP Interworking
> >> >>>>
> >> >>>> This is probably required to specify how an IPv4-only can move
> >> >>>> between
> >> >>>> CMIP and PMIP environments.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
> >> >>>
> >> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
> >> >>> NETLMM
> >> >>> charter, but this work is presumably about interaction with MIPv4.
> >> >>> Might
> >> >>> be
> >> >>> useful work, I wouldn't mind if this was done in NETEXT at some
> >> >>> point. Is
> >> >>> this crucial to be in the first revision of the WG's charter?
> >> >>>
> >> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >> >>>
> >> >>> Can you expand on this?
> >> >>>
> >> >>> Jari
> >> >>>
> >> >>> _______________________________________________
> >> >>> 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
> >> >>
> >> >>
> >> >
> >> > _______________________________________________
> >> > NetExt mailing list
> >> > NetExt at mail.mobileip.jp
> >> > http://www.mobileip.jp/mailman/listinfo/netext
> >>
> > --
> >? 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
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
-- 
? 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090416/fb673a01/attachment-0001.html>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Thu, 16 Apr 2009 22:57:33 +0200
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marcelo,

On 4/15/09 5:30 AM, "Marcelo Bagnulo" <marcelo at it.uc3m.es> wrote:

> Qin Wu escribi?:
>> Hi, Maro ,George and all:
>> I tend to agree with Marco's point.
>> No MN involvement means MN does not involve in network layer/IP layer moblity
>> management.However it does not restrict MN to involve in out of band
>> signaling.
>> On the other hand, no MN involvement does not mean no host change.  Host
>> changes can be divided into changes in different levels,e.g., IP stack level
>> change, application level change, etc. For some case without MN involvement,
>> the host changes below or over the IP layer can be allowed. So I think we
>> should be careful to interpret it if we include "no MN involvement" in the
>> current charter.
 
> 
> right
> but once we accept that we can do changes in the MN (whcih was out of
> the scope for netlmm), then we need to open the discssion for what
> changes are better. On possible change is to include a MIP
> implementation in the node and there seems to be evidence that that
> approach works.

I don't think anyone is suggesting implementing a Mobile IP client on the
host in the context of this discussion as a solution. Instead what is being
debated is the degree of host involvement or changes that may be able to
solve the problem. We are in no way suggesting that a new protocol between
the MN and MAG be defined to solve the mutihoming/flow-mobility/inter-tech
HO problems. However there are things that fall between defining a new
protocol specification between the MN and MAG to enhancing L2s that can be
looked at.

-Raj

> 
> Regards, marcelo
> 
>> Regards!
>> -Qin

From: yuankui.zhao at gmail.com (john.zhao)
Date: Fri, 17 Apr 2009 01:13:43 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <1239900013.5254.37.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost> <[email-masked]> <1239900013.5254.37.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos

2009/4/17 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> Hi John,
>
> El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?:
>> Hi Carlos,
>>
>> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
>> > Hi Ryuji,
>> > ? ? ? ?Sorry for the delayed reply. Comments below.
>> >
>> > El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
>> >> Hello Carlos,
>> >>
>> >> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
>> >>
>> >> > Hi Behcet,
>> >> >
>> >> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
>> >> > bit beyond that, since what I want to enable is node to be able to
>> >> > benefit from network based localised mobility support not only when
>> >> > roaming between fixed points of attachment (this is what RFC5213 does
>> >> > today) but also when roaming between fixed and mobile points of
>> >> > attachment. What people do think about this scenario?
>> >>
>> >> I don't know what is fixed and mobile points of attachment. You can
>> >> clarify these.
>> >>
>> >
>> > I've sent another e-mail regarding this (hope there is more clear).
>> > Summarising, what I call a fixed point of attachment is a MAG as it is
>> > defined in RFC5213 that does not move. I call a mobile point of
>> > attachment a MAG that would also be able to move (like an MR) within the
>> > PMIPv6 domain.
>> [John.zhao]So,would you like extend the MAG capability to a moving
>> router,right? If thus, where is the LMA for this MAG?
>
> Well, it can be seen the other way around, to extend the MAG capability
> to be mobile...
>
[John.zhao]So,is it a method for moving router or MAG? And what is the
difference to the mobile Router to connect to the fixed or mobile
attachment point as you mentioned?

John.zhao

> Carlos
>
>>
>>
>> ? ? ? ? Best Rgds,
>> Thanks,
>>
>> John.zhao
>> >
>> > Thanks,
>> >
>> > Carlos
>> >
>> >> ryuji
>> >>
>> >> >
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Carlos
>> >> >
>> >> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>> >> >> Hi Carlos,
>> >> >> ? Check this out:
>> >> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
>> >> >> support-00
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Behcet
>> >> >>
>> >> >> ________________________________
>> >> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>> >> >> To: Jari Arkko <jari.arkko at piuha.net>
>> >> >> Cc: netext at mail.mobileip.jp
>> >> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
>> >> >> Subject: Re: [Netext] next steps for netext
>> >> >>
>> >> >> Hi Jari, all,
>> >> >>
>> >> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
>> >> >> personal view on that is that it'd be nice to extend PMIPv6 to
>> >> >> support
>> >> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
>> >> >> to also move (like MRs, but without even supporting RFC3963), so an
>> >> >> MR
>> >> >> would be able to move between fixed and mobile MAGs without changing
>> >> >> its IP address (same support RFC5213 gives now). There are some
>> >> >> interesting scenarios that could benefit from this.
>> >> >>
>> >> >> What do others think? It is interesting to work on this?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Carlos
>> >> >>
>> >> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>> >> >>> Sri,
>> >> >>>
>> >> >>> Thanks for your input. Inline:
>> >> >>>
>> >> >>>> I've a concern with the planned charter. The list is too random and
>> >> >>>> cherry picked and I dont believe proper input from all the folks
>> >> >>>> went
>> >> >>>> into
>> >> >>>> this. There are many other items that are required for a reasonable
>> >> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
>> >> >>>> the last 2
>> >> >>>> years, some of them that were left out in the base spec, some
>> >> >>>> that we
>> >> >>>> realized as gaps when compared to other SDO protocols and some as
>> >> >>>> optimizations that we realized while implementing PMIP6, these
>> >> >>>> items
>> >> >>>> should be in the initial scope.
>> >> >>>>
>> >> >>>> I understand the charter needs to be limited in scope, but just 3
>> >> >>>> or 4
>> >> >>>> random items, I'm not sure if this helps in short term PMIP6
>> >> >>>> requirements.
>> >> >>>> I've no issue with the currently listed items, but there are
>> >> >>>> other items
>> >> >>>> that should get equal or higher priority.
>> >> >>>
>> >> >>> I have no problem with adding more. Even the charter says new
>> >> >>> things can
>> >> >>> be
>> >> >>> added.
>> >> >>>
>> >> >>> However, from a process perspective what I did was to take the
>> >> >>> proposal on
>> >> >>> the table, i.e., the full BOF scope and see what parts of that we
>> >> >>> already
>> >> >>> have an agreement on. I didn't include other things that were not
>> >> >>> discussed
>> >> >>> in the BOF. Maybe that would have been useful, but they were not
>> >> >>> on the
>> >> >>> table.
>> >> >>>
>> >> >>> We could add more items now, if there's general agreement that those
>> >> >>> things
>> >> >>> are useful. However, I do not want to declare an open season on
>> >> >>> doing
>> >> >>> everything. We pick a reasonable subset of all proposed work,
>> >> >>> based on
>> >> >>> priorities, community agreement that they are the right things to
>> >> >>> do,
>> >> >>> management reasons to ensure that we are not doing too much, etc.
>> >> >>>
>> >> >>>> For example, item #6, is absolutely required, from the
>> >> >>>> perspective of
>> >> >>>> having a complete specification of 5213. There we allowed a
>> >> >>>> mobile node
>> >> >>>> to
>> >> >>>> perform handoff betweek two interfaces. We defined all the hooks
>> >> >>>> on the
>> >> >>>> network side, but we did not provide how a terminal vendor can
>> >> >>>> support
>> >> >>>> that. A simple informational draft on how some one move prefixes
>> >> >>>> between
>> >> >>>> interfaces will greatly help. Some guidance on how to create a
>> >> >>>> virtual
>> >> >>>> interface and also some related notes for each platform (Linux,
>> >> >>>> BSD,
>> >> >>>> Android ..etc). This should not fall in the controversial
>> >> >>>> discussion
>> >> >>>> scope
>> >> >>>> of same address on two interfaces etc, thats a different problem,
>> >> >>>> or
>> >> >>>> about
>> >> >>>> the issue of enhancing mobile node's capabilities. This is just
>> >> >>>> informational work, required to leverage what 5213 already
>> >> >>>> supports.
>> >> >>>
>> >> >>> I suspect this is about the scoping of the handoff work. Lets try to
>> >> >>> figure
>> >> >>> out what makes sense (I personally believe the above item makes
>> >> >>> sense, for
>> >> >>> instance) and what doesn't.
>> >> >>>
>> >> >>> The fact that these parts were not in the charter was not a
>> >> >>> declaration
>> >> >>> that
>> >> >>> we're dismissing them. Its just that we didn't finish the
>> >> >>> discussion, but
>> >> >>> I
>> >> >>> still wanted to let the other things move forward.
>> >> >>>
>> >> >>>> Item #2, is required. The multimob BOF raised some issues, we
>> >> >>>> need to
>> >> >>>> show how multicast services can be enabled in PMIP network. May
>> >> >>>> be this
>> >> >>>> wont require extensions, a simple draft covering those aspects
>> >> >>>> will help.
>> >> >>>
>> >> >>> As you may recall, in the Multimob BOF we did not have an
>> >> >>> agreement on
>> >> >>> what
>> >> >>> exactly is needed, if anything. My own conclusion is that we
>> >> >>> probably need
>> >> >>> at least an informational document that explains how to use RFC
>> >> >>> 5213 for
>> >> >>> multicast. I think we discussed the possibility of doing this as
>> >> >>> some kind
>> >> >>> of AD sponsored document or in one of the relevant WGs, as a joint
>> >> >>> work
>> >> >>> between PMIP and multicast experts.
>> >> >>>
>> >> >>> I'm on the fence about adding this work to the charter right now,
>> >> >>> mainly
>> >> >>> because the BOF back then was very inconclusive. I'd be happier if
>> >> >>> I saw
>> >> >>> an
>> >> >>> actual well written draft from say you and some of the multicast
>> >> >>> experts.
>> >> >>> There's no problem moving good documents forward, even if they are
>> >> >>> not in
>> >> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
>> >> >>> maintenance like item for this in one of the WG charters either.
>> >> >>>
>> >> >>>> I think, the charter should be bit more relaxed and more
>> >> >>>> extensive. As I
>> >> >>>> see it, atleast the folks are interested in doing the work. We
>> >> >>>> should add
>> >> >>>> atleast 4 or 5 more items to this list.
>> >> >>>
>> >> >>> Generally speaking IETF WG charters give specific work items that
>> >> >>> the WG
>> >> >>> should work on. I had hoped that the charter text:
>> >> >>>
>> >> >>> "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."
>> >> >>>
>> >> >>> gives an indication that we intend to do more! I am also
>> >> >>> personally very
>> >> >>> happy to add more items to the group's charter. All in all, I do
>> >> >>> know that
>> >> >>> the current charter is a bit on the thin side -- mostly because the
>> >> >>> multihoming/interaccess issue is under discussion.
>> >> >>>
>> >> >>> There's also the question of general maintenance items. Some IETF
>> >> >>> WGs have
>> >> >>> a
>> >> >>> general work item to fix problems and issue updates to existing
>> >> >>> specifications. I think we need to do that for Proxy Mobile IPv6
>> >> >>> as well.
>> >> >>> But we have not decided whether that item should go to NETLMM or
>> >> >>> NETEXT WG
>> >> >>> yet. Please rest assured that the work will be possible regardless
>> >> >>> of
>> >> >>> this.
>> >> >>>
>> >> >>>> 1. Dynamic LMA Assignment
>> >> >>>>
>> >> >>>> In blade architecture systems or in a load balancer
>> >> >>>> configuration, the
>> >> >>>> PDNGW
>> >> >>>> should have the ability to dynamically assign a LMA on the fly,
>> >> >>>> along the
>> >> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>> >> >>>> [RFC-4433].
>> >> >>>> Currently, GTP provides such semantics and this is a important
>> >> >>>> requirement
>> >> >>>> for deployment. Here the goal is to
>> >> >>>>
>> >> >>>> a.) Expose a single IP address to the SGW
>> >> >>>> b.) The exposed IP address should not be in path once the
>> >> >>>> assignment is
>> >> >>>> done.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> [LMA1]---
>> >> >>>> | |
>> >> >>>> [LMA2]--[LMA]==========[MAG]
>> >> >>>> | |
>> >> >>>> [LMA3]---
>> >> >>>>
>> >> >>>>
>> >> >>>> Along the lines of:
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>> >> >>>
>> >> >>> This is in the proposed NETEXT charter already.
>> >> >>>
>> >> >>>> 2. Multicast Support in Proxy Mobile IPv6
>> >> >>>>
>> >> >>>> We need an informational specification on how multicast support
>> >> >>>> can be
>> >> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>> >> >>>> analysis
>> >> >>>> on
>> >> >>>> this. This is required and critical for enabling any multicast
>> >> >>>> services.
>> >> >>>> However,
>> >> >>>> Behcet may disagree with the scope of the work.
>> >> >>>
>> >> >>> See above.
>> >> >>>
>> >> >>>> 3. Bulk Registration Support
>> >> >>>>
>> >> >>>> This is a simple extension which helps in signaling optimization,
>> >> >>>> along
>> >> >>>> the
>> >> >>>> lines of:
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>> >> >>>
>> >> >>> This is in the charter as well.
>> >> >>>
>> >> >>>> 4. Partial Failover Support
>> >> >>>>
>> >> >>>> We need a mechanism to notify the peer on revoke a partial set of
>> >> >>>> bindings.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
>> >> >>>> .
>> >> >>>> txt
>> >> >>>
>> >> >>> Hmm. Ok. This needs more discussion.
>> >> >>>
>> >> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
>> >> >>>>
>> >> >>>> This provides a simple and a generic semantic for assigning a group
>> >> >>>> identifier
>> >> >>>> to a mobile node's binding. GTP has very similar semantics,
>> >> >>>> Connexion Set
>> >> >>>> Id.
>> >> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
>> >> >>>> systems
>> >> >>>> where
>> >> >>>> the load balancer is in path for all signaling messages, it can
>> >> >>>> use this
>> >> >>>> as
>> >> >>>> a
>> >> >>>> tag for redirecting the message.
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>> >> >>>
>> >> >>> Since the bulk registration work is in the charter, can't you do the
>> >> >>> sensible design (whatever it is) under that? There is no
>> >> >>> requirement that
>> >> >>> one charter item equals one document.
>> >> >>>
>> >> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>> >> >>>> handoffs:
>> >> >>>>
>> >> >>>>
>> >> >>>> RFC-5213 supports handoff between two interfaces. The ability to
>> >> >>>> move
>> >> >>>> prefixes between interfaces. In other words address continuity is
>> >> >>>> assured
>> >> >>>> with any IPv6 host on the planet and with absolutely no changes.
>> >> >>>> This
>> >> >>>> meets
>> >> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
>> >> >>>> what is
>> >> >>>> not assured is the aspect of session continuity. Which requires a
>> >> >>>> virtual
>> >> >>>> interface implementation on the host, by binding the address/
>> >> >>>> prefix to a
>> >> >>>> virtual interface and by not exposing the physical interface or
>> >> >>>> by hiding
>> >> >>>> the handoff events from the layer-3 stack.
>> >> >>>>
>> >> >>>> In essence, we need an informational specification which provides
>> >> >>>> some
>> >> >>>> general guidance to how to leverage the feature support provided in
>> >> >>>> RFC-5213,
>> >> >>>> along the lines of:
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>> >> >>>
>> >> >>> This is part of the discussion that we need to finish. But I plan
>> >> >>> to let
>> >> >>> the
>> >> >>> rest of the stuff move forward even before we have done that.
>> >> >>>
>> >> >>>
>> >> >>>> 7. Route Optimization for Proxy Mobile IPv6
>> >> >>>>
>> >> >>>> There were atleast 4 drafts in this area on Route Optimization.
>> >> >>>> Marco
>> >> >>>> Liebsch
>> >> >>>> analyzed this exensively:
>> >> >>>>
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>> >> >>>>
>> >> >>>>
>> >> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
>> >> >>>> .
>> >> >>>> txt
>> >> >>>
>> >> >>> This is in the charter.
>> >> >>>
>> >> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
>> >> >>>>
>> >> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
>> >> >>>> prefixes
>> >> >>>> to a given mobile node's interface. It might be useful to specify
>> >> >>>> how the
>> >> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
>> >> >>>> Pools or
>> >> >>>> AAA to manage this aspect. Behcet has one draft on this.
>> >> >>>
>> >> >>> I'm not personally sold on this particular work. But again, this
>> >> >>> could be
>> >> >>> something to consider.
>> >> >>>
>> >> >>>> 9. Partial Handoff Support
>> >> >>>>
>> >> >>>> We are missing some semantics in 5213 for moving a subset of the
>> >> >>>> prefixes
>> >> >>>> between interfaces as part of the inter-tech handoff. This is about
>> >> >>>> defining
>> >> >>>> a new handoff value. This allows partial flow management, but
>> >> >>>> moving the
>> >> >>>> flows associated to a prefix, as a whole group.
>> >> >>>>
>> >> >>>>
>> >> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>> >> >>>
>> >> >>> A part of the topic we still need to discuss...
>> >> >>>
>> >> >>>> 10. CMIPv4/PMIP Interworking
>> >> >>>>
>> >> >>>> This is probably required to specify how an IPv4-only can move
>> >> >>>> between
>> >> >>>> CMIP and PMIP environments.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>> >> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
>> >> >>>
>> >> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
>> >> >>> NETLMM
>> >> >>> charter, but this work is presumably about interaction with MIPv4.
>> >> >>> Might
>> >> >>> be
>> >> >>> useful work, I wouldn't mind if this was done in NETEXT at some
>> >> >>> point. Is
>> >> >>> this crucial to be in the first revision of the WG's charter?
>> >> >>>
>> >> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>> >> >>>
>> >> >>> Can you expand on this?
>> >> >>>
>> >> >>> Jari
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> 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
>> >> >>
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > NetExt mailing list
>> >> > NetExt at mail.mobileip.jp
>> >> > http://www.mobileip.jp/mailman/listinfo/netext
>> >>
>> > --
>> > ? 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
>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > _______________________________________________
>> > NetExt mailing list
>> > NetExt at mail.mobileip.jp
>> > http://www.mobileip.jp/mailman/listinfo/netext
>> >
>> >
> --
> ? 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
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 16 Apr 2009 18:40:13 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost> <[email-masked]>
Message-ID: <1239900013.5254.37.camel@localhost>

Hi John,

El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?:
> Hi Carlos,
> 
> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> > Hi Ryuji,
> >        Sorry for the delayed reply. Comments below.
> >
> > El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
> >> Hello Carlos,
> >>
> >> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
> >>
> >> > Hi Behcet,
> >> >
> >> > I've quickly checked the document. I think it does address the same
> >> > problem I was referring to. This draft addresses the problem of
> >> > delegating a prefix to a router that attaches to a PMIPv6 domain, so
> >> > it can provide connectivity to nodes attached to it. I think this was
> >> > already discussed in a past meeting (a draft with the problem
> >> > statement)
> [John.zhao]Yes.http://tools.ietf.org/html/draft-zhao-nemo-limitations-ps-00.
> 
> >> > and I mentioned that IMHO this can basically be achieved by
> >> > just using plain NEMO support on the router. The only difference in
> >> > this draft is that it doesn't impose the router to be a NEMO RFC3963
> >> > MR, although still it needs to do some additional things that a normal
> >> > router (not mobile) doesn't. Anyway, I'm not against this type of
> >> > support if there are scenarios in which it's useful.
> >>
> >> In the doc, we just specify how to get mobile network prefix from DHCP-
> >> DR.
> >> DHCP-PD is that normal router does, right?
> >
> > Yes, my point was more related with the benefits of doing this instead
> > of just using NEMO.
> [John.zhao]My two cents. About the benefits for doing this, it is for
> PMIPv6 domian control as mentioned in Page 8 of this draft."This
> document recommends that Proxy Mobile IPv6 controls the prefix
> management ......". That is from network perspective. On the
> contrary,customers can use router without NEMO enble under both of
> fixed network and pmip network.  Of course, NEMO can make router be
> benefited if it would like to be roamed. But no one can claim network
> must support the NEMO.
> >
> >>
> >> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> >> > bit beyond that, since what I want to enable is node to be able to
> >> > benefit from network based localised mobility support not only when
> >> > roaming between fixed points of attachment (this is what RFC5213 does
> >> > today) but also when roaming between fixed and mobile points of
> >> > attachment. What people do think about this scenario?
> >>
> >> I don't know what is fixed and mobile points of attachment. You can
> >> clarify these.
> >>
> >
> > I've sent another e-mail regarding this (hope there is more clear).
> > Summarising, what I call a fixed point of attachment is a MAG as it is
> > defined in RFC5213 that does not move. I call a mobile point of
> > attachment a MAG that would also be able to move (like an MR) within the
> > PMIPv6 domain.
> [John.zhao]So,would you like extend the MAG capability to a moving
> router,right? If thus, where is the LMA for this MAG?

Well, it can be seen the other way around, to extend the MAG capability
to be mobile...

Carlos

> 
> 
>         Best Rgds,
> Thanks,
> 
> John.zhao
> >
> > Thanks,
> >
> > Carlos
> >
> >> ryuji
> >>
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Carlos
> >> >
> >> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >> >> Hi Carlos,
> >> >>   Check this out:
> >> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
> >> >> support-00
> >> >>
> >> >> Regards,
> >> >>
> >> >> Behcet
> >> >>
> >> >> ________________________________
> >> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >> >> To: Jari Arkko <jari.arkko at piuha.net>
> >> >> Cc: netext at mail.mobileip.jp
> >> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
> >> >> Subject: Re: [Netext] next steps for netext
> >> >>
> >> >> Hi Jari, all,
> >> >>
> >> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> >> >> personal view on that is that it'd be nice to extend PMIPv6 to
> >> >> support
> >> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
> >> >> to also move (like MRs, but without even supporting RFC3963), so an
> >> >> MR
> >> >> would be able to move between fixed and mobile MAGs without changing
> >> >> its IP address (same support RFC5213 gives now). There are some
> >> >> interesting scenarios that could benefit from this.
> >> >>
> >> >> What do others think? It is interesting to work on this?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Carlos
> >> >>
> >> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> >>> Sri,
> >> >>>
> >> >>> Thanks for your input. Inline:
> >> >>>
> >> >>>> I've a concern with the planned charter. The list is too random and
> >> >>>> cherry picked and I dont believe proper input from all the folks
> >> >>>> went
> >> >>>> into
> >> >>>> this. There are many other items that are required for a reasonable
> >> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
> >> >>>> the last 2
> >> >>>> years, some of them that were left out in the base spec, some
> >> >>>> that we
> >> >>>> realized as gaps when compared to other SDO protocols and some as
> >> >>>> optimizations that we realized while implementing PMIP6, these
> >> >>>> items
> >> >>>> should be in the initial scope.
> >> >>>>
> >> >>>> I understand the charter needs to be limited in scope, but just 3
> >> >>>> or 4
> >> >>>> random items, I'm not sure if this helps in short term PMIP6
> >> >>>> requirements.
> >> >>>> I've no issue with the currently listed items, but there are
> >> >>>> other items
> >> >>>> that should get equal or higher priority.
> >> >>>
> >> >>> I have no problem with adding more. Even the charter says new
> >> >>> things can
> >> >>> be
> >> >>> added.
> >> >>>
> >> >>> However, from a process perspective what I did was to take the
> >> >>> proposal on
> >> >>> the table, i.e., the full BOF scope and see what parts of that we
> >> >>> already
> >> >>> have an agreement on. I didn't include other things that were not
> >> >>> discussed
> >> >>> in the BOF. Maybe that would have been useful, but they were not
> >> >>> on the
> >> >>> table.
> >> >>>
> >> >>> We could add more items now, if there's general agreement that those
> >> >>> things
> >> >>> are useful. However, I do not want to declare an open season on
> >> >>> doing
> >> >>> everything. We pick a reasonable subset of all proposed work,
> >> >>> based on
> >> >>> priorities, community agreement that they are the right things to
> >> >>> do,
> >> >>> management reasons to ensure that we are not doing too much, etc.
> >> >>>
> >> >>>> For example, item #6, is absolutely required, from the
> >> >>>> perspective of
> >> >>>> having a complete specification of 5213. There we allowed a
> >> >>>> mobile node
> >> >>>> to
> >> >>>> perform handoff betweek two interfaces. We defined all the hooks
> >> >>>> on the
> >> >>>> network side, but we did not provide how a terminal vendor can
> >> >>>> support
> >> >>>> that. A simple informational draft on how some one move prefixes
> >> >>>> between
> >> >>>> interfaces will greatly help. Some guidance on how to create a
> >> >>>> virtual
> >> >>>> interface and also some related notes for each platform (Linux,
> >> >>>> BSD,
> >> >>>> Android ..etc). This should not fall in the controversial
> >> >>>> discussion
> >> >>>> scope
> >> >>>> of same address on two interfaces etc, thats a different problem,
> >> >>>> or
> >> >>>> about
> >> >>>> the issue of enhancing mobile node's capabilities. This is just
> >> >>>> informational work, required to leverage what 5213 already
> >> >>>> supports.
> >> >>>
> >> >>> I suspect this is about the scoping of the handoff work. Lets try to
> >> >>> figure
> >> >>> out what makes sense (I personally believe the above item makes
> >> >>> sense, for
> >> >>> instance) and what doesn't.
> >> >>>
> >> >>> The fact that these parts were not in the charter was not a
> >> >>> declaration
> >> >>> that
> >> >>> we're dismissing them. Its just that we didn't finish the
> >> >>> discussion, but
> >> >>> I
> >> >>> still wanted to let the other things move forward.
> >> >>>
> >> >>>> Item #2, is required. The multimob BOF raised some issues, we
> >> >>>> need to
> >> >>>> show how multicast services can be enabled in PMIP network. May
> >> >>>> be this
> >> >>>> wont require extensions, a simple draft covering those aspects
> >> >>>> will help.
> >> >>>
> >> >>> As you may recall, in the Multimob BOF we did not have an
> >> >>> agreement on
> >> >>> what
> >> >>> exactly is needed, if anything. My own conclusion is that we
> >> >>> probably need
> >> >>> at least an informational document that explains how to use RFC
> >> >>> 5213 for
> >> >>> multicast. I think we discussed the possibility of doing this as
> >> >>> some kind
> >> >>> of AD sponsored document or in one of the relevant WGs, as a joint
> >> >>> work
> >> >>> between PMIP and multicast experts.
> >> >>>
> >> >>> I'm on the fence about adding this work to the charter right now,
> >> >>> mainly
> >> >>> because the BOF back then was very inconclusive. I'd be happier if
> >> >>> I saw
> >> >>> an
> >> >>> actual well written draft from say you and some of the multicast
> >> >>> experts.
> >> >>> There's no problem moving good documents forward, even if they are
> >> >>> not in
> >> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> >>> maintenance like item for this in one of the WG charters either.
> >> >>>
> >> >>>> I think, the charter should be bit more relaxed and more
> >> >>>> extensive. As I
> >> >>>> see it, atleast the folks are interested in doing the work. We
> >> >>>> should add
> >> >>>> atleast 4 or 5 more items to this list.
> >> >>>
> >> >>> Generally speaking IETF WG charters give specific work items that
> >> >>> the WG
> >> >>> should work on. I had hoped that the charter text:
> >> >>>
> >> >>> "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."
> >> >>>
> >> >>> gives an indication that we intend to do more! I am also
> >> >>> personally very
> >> >>> happy to add more items to the group's charter. All in all, I do
> >> >>> know that
> >> >>> the current charter is a bit on the thin side -- mostly because the
> >> >>> multihoming/interaccess issue is under discussion.
> >> >>>
> >> >>> There's also the question of general maintenance items. Some IETF
> >> >>> WGs have
> >> >>> a
> >> >>> general work item to fix problems and issue updates to existing
> >> >>> specifications. I think we need to do that for Proxy Mobile IPv6
> >> >>> as well.
> >> >>> But we have not decided whether that item should go to NETLMM or
> >> >>> NETEXT WG
> >> >>> yet. Please rest assured that the work will be possible regardless
> >> >>> of
> >> >>> this.
> >> >>>
> >> >>>> 1. Dynamic LMA Assignment
> >> >>>>
> >> >>>> In blade architecture systems or in a load balancer
> >> >>>> configuration, the
> >> >>>> PDNGW
> >> >>>> should have the ability to dynamically assign a LMA on the fly,
> >> >>>> along the
> >> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >> >>>> [RFC-4433].
> >> >>>> Currently, GTP provides such semantics and this is a important
> >> >>>> requirement
> >> >>>> for deployment. Here the goal is to
> >> >>>>
> >> >>>> a.) Expose a single IP address to the SGW
> >> >>>> b.) The exposed IP address should not be in path once the
> >> >>>> assignment is
> >> >>>> done.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> [LMA1]---
> >> >>>> | |
> >> >>>> [LMA2]--[LMA]==========[MAG]
> >> >>>> | |
> >> >>>> [LMA3]---
> >> >>>>
> >> >>>>
> >> >>>> Along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >> >>>
> >> >>> This is in the proposed NETEXT charter already.
> >> >>>
> >> >>>> 2. Multicast Support in Proxy Mobile IPv6
> >> >>>>
> >> >>>> We need an informational specification on how multicast support
> >> >>>> can be
> >> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >> >>>> analysis
> >> >>>> on
> >> >>>> this. This is required and critical for enabling any multicast
> >> >>>> services.
> >> >>>> However,
> >> >>>> Behcet may disagree with the scope of the work.
> >> >>>
> >> >>> See above.
> >> >>>
> >> >>>> 3. Bulk Registration Support
> >> >>>>
> >> >>>> This is a simple extension which helps in signaling optimization,
> >> >>>> along
> >> >>>> the
> >> >>>> lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >> >>>
> >> >>> This is in the charter as well.
> >> >>>
> >> >>>> 4. Partial Failover Support
> >> >>>>
> >> >>>> We need a mechanism to notify the peer on revoke a partial set of
> >> >>>> bindings.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> Hmm. Ok. This needs more discussion.
> >> >>>
> >> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
> >> >>>>
> >> >>>> This provides a simple and a generic semantic for assigning a group
> >> >>>> identifier
> >> >>>> to a mobile node's binding. GTP has very similar semantics,
> >> >>>> Connexion Set
> >> >>>> Id.
> >> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
> >> >>>> systems
> >> >>>> where
> >> >>>> the load balancer is in path for all signaling messages, it can
> >> >>>> use this
> >> >>>> as
> >> >>>> a
> >> >>>> tag for redirecting the message.
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >> >>>
> >> >>> Since the bulk registration work is in the charter, can't you do the
> >> >>> sensible design (whatever it is) under that? There is no
> >> >>> requirement that
> >> >>> one charter item equals one document.
> >> >>>
> >> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >> >>>> handoffs:
> >> >>>>
> >> >>>>
> >> >>>> RFC-5213 supports handoff between two interfaces. The ability to
> >> >>>> move
> >> >>>> prefixes between interfaces. In other words address continuity is
> >> >>>> assured
> >> >>>> with any IPv6 host on the planet and with absolutely no changes.
> >> >>>> This
> >> >>>> meets
> >> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
> >> >>>> what is
> >> >>>> not assured is the aspect of session continuity. Which requires a
> >> >>>> virtual
> >> >>>> interface implementation on the host, by binding the address/
> >> >>>> prefix to a
> >> >>>> virtual interface and by not exposing the physical interface or
> >> >>>> by hiding
> >> >>>> the handoff events from the layer-3 stack.
> >> >>>>
> >> >>>> In essence, we need an informational specification which provides
> >> >>>> some
> >> >>>> general guidance to how to leverage the feature support provided in
> >> >>>> RFC-5213,
> >> >>>> along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >> >>>
> >> >>> This is part of the discussion that we need to finish. But I plan
> >> >>> to let
> >> >>> the
> >> >>> rest of the stuff move forward even before we have done that.
> >> >>>
> >> >>>
> >> >>>> 7. Route Optimization for Proxy Mobile IPv6
> >> >>>>
> >> >>>> There were atleast 4 drafts in this area on Route Optimization.
> >> >>>> Marco
> >> >>>> Liebsch
> >> >>>> analyzed this exensively:
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >> >>>>
> >> >>>>
> >> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> This is in the charter.
> >> >>>
> >> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
> >> >>>>
> >> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
> >> >>>> prefixes
> >> >>>> to a given mobile node's interface. It might be useful to specify
> >> >>>> how the
> >> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
> >> >>>> Pools or
> >> >>>> AAA to manage this aspect. Behcet has one draft on this.
> >> >>>
> >> >>> I'm not personally sold on this particular work. But again, this
> >> >>> could be
> >> >>> something to consider.
> >> >>>
> >> >>>> 9. Partial Handoff Support
> >> >>>>
> >> >>>> We are missing some semantics in 5213 for moving a subset of the
> >> >>>> prefixes
> >> >>>> between interfaces as part of the inter-tech handoff. This is about
> >> >>>> defining
> >> >>>> a new handoff value. This allows partial flow management, but
> >> >>>> moving the
> >> >>>> flows associated to a prefix, as a whole group.
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >> >>>
> >> >>> A part of the topic we still need to discuss...
> >> >>>
> >> >>>> 10. CMIPv4/PMIP Interworking
> >> >>>>
> >> >>>> This is probably required to specify how an IPv4-only can move
> >> >>>> between
> >> >>>> CMIP and PMIP environments.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
> >> >>>
> >> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
> >> >>> NETLMM
> >> >>> charter, but this work is presumably about interaction with MIPv4.
> >> >>> Might
> >> >>> be
> >> >>> useful work, I wouldn't mind if this was done in NETEXT at some
> >> >>> point. Is
> >> >>> this crucial to be in the first revision of the WG's charter?
> >> >>>
> >> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >> >>>
> >> >>> Can you expand on this?
> >> >>>
> >> >>> Jari
> >> >>>
> >> >>> _______________________________________________
> >> >>> 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
> >> >>
> >> >>
> >> >
> >> > _______________________________________________
> >> > NetExt mailing list
> >> > NetExt at mail.mobileip.jp
> >> > http://www.mobileip.jp/mailman/listinfo/netext
> >>
> > --
> >   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
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
-- 
   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/20090416/abba16a4/attachment.bin>

From: yuankui.zhao at gmail.com (john.zhao)
Date: Fri, 17 Apr 2009 00:25:22 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <1239839006.4695.116.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239839006.4695.116.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> Hi Ryuji,
> ? ? ? ?Sorry for the delayed reply. Comments below.
>
> El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
>> Hello Carlos,
>>
>> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
>>
>> > Hi Behcet,
>> >
>> > I've quickly checked the document. I think it does address the same
>> > problem I was referring to. This draft addresses the problem of
>> > delegating a prefix to a router that attaches to a PMIPv6 domain, so
>> > it can provide connectivity to nodes attached to it. I think this was
>> > already discussed in a past meeting (a draft with the problem
>> > statement)
[John.zhao]Yes.http://tools.ietf.org/html/draft-zhao-nemo-limitations-ps-00.

>> > and I mentioned that IMHO this can basically be achieved by
>> > just using plain NEMO support on the router. The only difference in
>> > this draft is that it doesn't impose the router to be a NEMO RFC3963
>> > MR, although still it needs to do some additional things that a normal
>> > router (not mobile) doesn't. Anyway, I'm not against this type of
>> > support if there are scenarios in which it's useful.
>>
>> In the doc, we just specify how to get mobile network prefix from DHCP-
>> DR.
>> DHCP-PD is that normal router does, right?
>
> Yes, my point was more related with the benefits of doing this instead
> of just using NEMO.
[John.zhao]My two cents. About the benefits for doing this, it is for
PMIPv6 domian control as mentioned in Page 8 of this draft."This
document recommends that Proxy Mobile IPv6 controls the prefix
management ......". That is from network perspective. On the
contrary,customers can use router without NEMO enble under both of
fixed network and pmip network.  Of course, NEMO can make router be
benefited if it would like to be roamed. But no one can claim network
must support the NEMO.
>
>>
>> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
>> > bit beyond that, since what I want to enable is node to be able to
>> > benefit from network based localised mobility support not only when
>> > roaming between fixed points of attachment (this is what RFC5213 does
>> > today) but also when roaming between fixed and mobile points of
>> > attachment. What people do think about this scenario?
>>
>> I don't know what is fixed and mobile points of attachment. You can
>> clarify these.
>>
>
> I've sent another e-mail regarding this (hope there is more clear).
> Summarising, what I call a fixed point of attachment is a MAG as it is
> defined in RFC5213 that does not move. I call a mobile point of
> attachment a MAG that would also be able to move (like an MR) within the
> PMIPv6 domain.
[John.zhao]So,would you like extend the MAG capability to a moving
router,right? If thus, where is the LMA for this MAG?

        Best Rgds,
Thanks,

John.zhao
>
> Thanks,
>
> Carlos
>
>> ryuji
>>
>> >
>> >
>> > Thanks,
>> >
>> > Carlos
>> >
>> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>> >> Hi Carlos,
>> >> ? Check this out:
>> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
>> >> support-00
>> >>
>> >> Regards,
>> >>
>> >> Behcet
>> >>
>> >> ________________________________
>> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>> >> To: Jari Arkko <jari.arkko at piuha.net>
>> >> Cc: netext at mail.mobileip.jp
>> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
>> >> Subject: Re: [Netext] next steps for netext
>> >>
>> >> Hi Jari, all,
>> >>
>> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
>> >> personal view on that is that it'd be nice to extend PMIPv6 to
>> >> support
>> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
>> >> to also move (like MRs, but without even supporting RFC3963), so an
>> >> MR
>> >> would be able to move between fixed and mobile MAGs without changing
>> >> its IP address (same support RFC5213 gives now). There are some
>> >> interesting scenarios that could benefit from this.
>> >>
>> >> What do others think? It is interesting to work on this?
>> >>
>> >> Thanks,
>> >>
>> >> Carlos
>> >>
>> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>> >>> Sri,
>> >>>
>> >>> Thanks for your input. Inline:
>> >>>
>> >>>> I've a concern with the planned charter. The list is too random and
>> >>>> cherry picked and I dont believe proper input from all the folks
>> >>>> went
>> >>>> into
>> >>>> this. There are many other items that are required for a reasonable
>> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
>> >>>> the last 2
>> >>>> years, some of them that were left out in the base spec, some
>> >>>> that we
>> >>>> realized as gaps when compared to other SDO protocols and some as
>> >>>> optimizations that we realized while implementing PMIP6, these
>> >>>> items
>> >>>> should be in the initial scope.
>> >>>>
>> >>>> I understand the charter needs to be limited in scope, but just 3
>> >>>> or 4
>> >>>> random items, I'm not sure if this helps in short term PMIP6
>> >>>> requirements.
>> >>>> I've no issue with the currently listed items, but there are
>> >>>> other items
>> >>>> that should get equal or higher priority.
>> >>>
>> >>> I have no problem with adding more. Even the charter says new
>> >>> things can
>> >>> be
>> >>> added.
>> >>>
>> >>> However, from a process perspective what I did was to take the
>> >>> proposal on
>> >>> the table, i.e., the full BOF scope and see what parts of that we
>> >>> already
>> >>> have an agreement on. I didn't include other things that were not
>> >>> discussed
>> >>> in the BOF. Maybe that would have been useful, but they were not
>> >>> on the
>> >>> table.
>> >>>
>> >>> We could add more items now, if there's general agreement that those
>> >>> things
>> >>> are useful. However, I do not want to declare an open season on
>> >>> doing
>> >>> everything. We pick a reasonable subset of all proposed work,
>> >>> based on
>> >>> priorities, community agreement that they are the right things to
>> >>> do,
>> >>> management reasons to ensure that we are not doing too much, etc.
>> >>>
>> >>>> For example, item #6, is absolutely required, from the
>> >>>> perspective of
>> >>>> having a complete specification of 5213. There we allowed a
>> >>>> mobile node
>> >>>> to
>> >>>> perform handoff betweek two interfaces. We defined all the hooks
>> >>>> on the
>> >>>> network side, but we did not provide how a terminal vendor can
>> >>>> support
>> >>>> that. A simple informational draft on how some one move prefixes
>> >>>> between
>> >>>> interfaces will greatly help. Some guidance on how to create a
>> >>>> virtual
>> >>>> interface and also some related notes for each platform (Linux,
>> >>>> BSD,
>> >>>> Android ..etc). This should not fall in the controversial
>> >>>> discussion
>> >>>> scope
>> >>>> of same address on two interfaces etc, thats a different problem,
>> >>>> or
>> >>>> about
>> >>>> the issue of enhancing mobile node's capabilities. This is just
>> >>>> informational work, required to leverage what 5213 already
>> >>>> supports.
>> >>>
>> >>> I suspect this is about the scoping of the handoff work. Lets try to
>> >>> figure
>> >>> out what makes sense (I personally believe the above item makes
>> >>> sense, for
>> >>> instance) and what doesn't.
>> >>>
>> >>> The fact that these parts were not in the charter was not a
>> >>> declaration
>> >>> that
>> >>> we're dismissing them. Its just that we didn't finish the
>> >>> discussion, but
>> >>> I
>> >>> still wanted to let the other things move forward.
>> >>>
>> >>>> Item #2, is required. The multimob BOF raised some issues, we
>> >>>> need to
>> >>>> show how multicast services can be enabled in PMIP network. May
>> >>>> be this
>> >>>> wont require extensions, a simple draft covering those aspects
>> >>>> will help.
>> >>>
>> >>> As you may recall, in the Multimob BOF we did not have an
>> >>> agreement on
>> >>> what
>> >>> exactly is needed, if anything. My own conclusion is that we
>> >>> probably need
>> >>> at least an informational document that explains how to use RFC
>> >>> 5213 for
>> >>> multicast. I think we discussed the possibility of doing this as
>> >>> some kind
>> >>> of AD sponsored document or in one of the relevant WGs, as a joint
>> >>> work
>> >>> between PMIP and multicast experts.
>> >>>
>> >>> I'm on the fence about adding this work to the charter right now,
>> >>> mainly
>> >>> because the BOF back then was very inconclusive. I'd be happier if
>> >>> I saw
>> >>> an
>> >>> actual well written draft from say you and some of the multicast
>> >>> experts.
>> >>> There's no problem moving good documents forward, even if they are
>> >>> not in
>> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
>> >>> maintenance like item for this in one of the WG charters either.
>> >>>
>> >>>> I think, the charter should be bit more relaxed and more
>> >>>> extensive. As I
>> >>>> see it, atleast the folks are interested in doing the work. We
>> >>>> should add
>> >>>> atleast 4 or 5 more items to this list.
>> >>>
>> >>> Generally speaking IETF WG charters give specific work items that
>> >>> the WG
>> >>> should work on. I had hoped that the charter text:
>> >>>
>> >>> "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."
>> >>>
>> >>> gives an indication that we intend to do more! I am also
>> >>> personally very
>> >>> happy to add more items to the group's charter. All in all, I do
>> >>> know that
>> >>> the current charter is a bit on the thin side -- mostly because the
>> >>> multihoming/interaccess issue is under discussion.
>> >>>
>> >>> There's also the question of general maintenance items. Some IETF
>> >>> WGs have
>> >>> a
>> >>> general work item to fix problems and issue updates to existing
>> >>> specifications. I think we need to do that for Proxy Mobile IPv6
>> >>> as well.
>> >>> But we have not decided whether that item should go to NETLMM or
>> >>> NETEXT WG
>> >>> yet. Please rest assured that the work will be possible regardless
>> >>> of
>> >>> this.
>> >>>
>> >>>> 1. Dynamic LMA Assignment
>> >>>>
>> >>>> In blade architecture systems or in a load balancer
>> >>>> configuration, the
>> >>>> PDNGW
>> >>>> should have the ability to dynamically assign a LMA on the fly,
>> >>>> along the
>> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>> >>>> [RFC-4433].
>> >>>> Currently, GTP provides such semantics and this is a important
>> >>>> requirement
>> >>>> for deployment. Here the goal is to
>> >>>>
>> >>>> a.) Expose a single IP address to the SGW
>> >>>> b.) The exposed IP address should not be in path once the
>> >>>> assignment is
>> >>>> done.
>> >>>>
>> >>>>
>> >>>>
>> >>>> [LMA1]---
>> >>>> | |
>> >>>> [LMA2]--[LMA]==========[MAG]
>> >>>> | |
>> >>>> [LMA3]---
>> >>>>
>> >>>>
>> >>>> Along the lines of:
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>> >>>
>> >>> This is in the proposed NETEXT charter already.
>> >>>
>> >>>> 2. Multicast Support in Proxy Mobile IPv6
>> >>>>
>> >>>> We need an informational specification on how multicast support
>> >>>> can be
>> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>> >>>> analysis
>> >>>> on
>> >>>> this. This is required and critical for enabling any multicast
>> >>>> services.
>> >>>> However,
>> >>>> Behcet may disagree with the scope of the work.
>> >>>
>> >>> See above.
>> >>>
>> >>>> 3. Bulk Registration Support
>> >>>>
>> >>>> This is a simple extension which helps in signaling optimization,
>> >>>> along
>> >>>> the
>> >>>> lines of:
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>> >>>
>> >>> This is in the charter as well.
>> >>>
>> >>>> 4. Partial Failover Support
>> >>>>
>> >>>> We need a mechanism to notify the peer on revoke a partial set of
>> >>>> bindings.
>> >>>>
>> >>>>
>> >>>>
>> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
>> >>>> .
>> >>>> txt
>> >>>
>> >>> Hmm. Ok. This needs more discussion.
>> >>>
>> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
>> >>>>
>> >>>> This provides a simple and a generic semantic for assigning a group
>> >>>> identifier
>> >>>> to a mobile node's binding. GTP has very similar semantics,
>> >>>> Connexion Set
>> >>>> Id.
>> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
>> >>>> systems
>> >>>> where
>> >>>> the load balancer is in path for all signaling messages, it can
>> >>>> use this
>> >>>> as
>> >>>> a
>> >>>> tag for redirecting the message.
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>> >>>
>> >>> Since the bulk registration work is in the charter, can't you do the
>> >>> sensible design (whatever it is) under that? There is no
>> >>> requirement that
>> >>> one charter item equals one document.
>> >>>
>> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>> >>>> handoffs:
>> >>>>
>> >>>>
>> >>>> RFC-5213 supports handoff between two interfaces. The ability to
>> >>>> move
>> >>>> prefixes between interfaces. In other words address continuity is
>> >>>> assured
>> >>>> with any IPv6 host on the planet and with absolutely no changes.
>> >>>> This
>> >>>> meets
>> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
>> >>>> what is
>> >>>> not assured is the aspect of session continuity. Which requires a
>> >>>> virtual
>> >>>> interface implementation on the host, by binding the address/
>> >>>> prefix to a
>> >>>> virtual interface and by not exposing the physical interface or
>> >>>> by hiding
>> >>>> the handoff events from the layer-3 stack.
>> >>>>
>> >>>> In essence, we need an informational specification which provides
>> >>>> some
>> >>>> general guidance to how to leverage the feature support provided in
>> >>>> RFC-5213,
>> >>>> along the lines of:
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>> >>>
>> >>> This is part of the discussion that we need to finish. But I plan
>> >>> to let
>> >>> the
>> >>> rest of the stuff move forward even before we have done that.
>> >>>
>> >>>
>> >>>> 7. Route Optimization for Proxy Mobile IPv6
>> >>>>
>> >>>> There were atleast 4 drafts in this area on Route Optimization.
>> >>>> Marco
>> >>>> Liebsch
>> >>>> analyzed this exensively:
>> >>>>
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>> >>>>
>> >>>>
>> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
>> >>>> .
>> >>>> txt
>> >>>
>> >>> This is in the charter.
>> >>>
>> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
>> >>>>
>> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
>> >>>> prefixes
>> >>>> to a given mobile node's interface. It might be useful to specify
>> >>>> how the
>> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
>> >>>> Pools or
>> >>>> AAA to manage this aspect. Behcet has one draft on this.
>> >>>
>> >>> I'm not personally sold on this particular work. But again, this
>> >>> could be
>> >>> something to consider.
>> >>>
>> >>>> 9. Partial Handoff Support
>> >>>>
>> >>>> We are missing some semantics in 5213 for moving a subset of the
>> >>>> prefixes
>> >>>> between interfaces as part of the inter-tech handoff. This is about
>> >>>> defining
>> >>>> a new handoff value. This allows partial flow management, but
>> >>>> moving the
>> >>>> flows associated to a prefix, as a whole group.
>> >>>>
>> >>>>
>> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>> >>>
>> >>> A part of the topic we still need to discuss...
>> >>>
>> >>>> 10. CMIPv4/PMIP Interworking
>> >>>>
>> >>>> This is probably required to specify how an IPv4-only can move
>> >>>> between
>> >>>> CMIP and PMIP environments.
>> >>>>
>> >>>>
>> >>>>
>> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
>> >>>
>> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
>> >>> NETLMM
>> >>> charter, but this work is presumably about interaction with MIPv4.
>> >>> Might
>> >>> be
>> >>> useful work, I wouldn't mind if this was done in NETEXT at some
>> >>> point. Is
>> >>> this crucial to be in the first revision of the WG's charter?
>> >>>
>> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>> >>>
>> >>> Can you expand on this?
>> >>>
>> >>> Jari
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>
>> >>
>> >
>> > _______________________________________________
>> > NetExt mailing list
>> > NetExt at mail.mobileip.jp
>> > http://www.mobileip.jp/mailman/listinfo/netext
>>
> --
> ? 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
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 16 Apr 2009 18:27:49 +0300
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ryuji,

> I support netext WG, but I need one clarification.

OK

> Once we have netext WG, the current NETLMM will be shutted down?
> The proposed items is only minor modifications to PMIP,
> do we need separate WG to discuss this?
> If we will have multihoming topic which will require certain 
> modifications to PMIP,
> it does make sense to have a separate WG.

If we had nothing else on the table right now, I might have asked the 
NETLMM WG to take this on. However, as we know there are other things 
being discussed, and I suspect there will be even more over time.

Also, NETLMM is still trying to complete everything that they have on 
their charter. This will take some time. After discussion with the 
chairs, the current feeling is that we do not want to recharter the 
NETLMM for new functionality. We also need to think about maintaining 
the existing specifications, e.g., RFC 5213bis might be needed at some 
point. I have not decided whether this is something that NETLMM WG 
should be kept alive for once they complete their current charter, or if 
it is something that NETEXT could take over.

In any case, closing NETLMM WG once their work is completed is a 
possibility. In most cases we should not keep WGs around for ever, and 
significant new work needs to go through public debate in a BOF.

Jari

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 16 Apr 2009 17:27:00 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239838985.4695.114.camel@localhost> <[email-masked]>
Message-ID: <1239895620.5254.33.camel@localhost>

Hi Behcet,

El jue, 16-04-2009 a las 07:35 -0700, Behcet Sarikaya escribi?:
> Hi Carlos,
>   According to Ryuji's draft MN is the MR. Also in RFC 3963 MR is also
> MN for HA. So this architecture is consistent with the original Nemo
> BSP design.

	Agree.

>   It seems like you have a different architecture in mind. I think
> that's where the confusion comes.

	Well, I tried to describe what I have in mind, which is different from
what Ryuji is addressing. Not sure if this time I was more clear.

	Thanks,

	Carlos

>  
> Regards,
>  
> Behcet
> 
> 
> 
> ______________________________________________________________________
> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> To: Jong-Hyouk Lee <jonghyouk at gmail.com>
> Cc: netext at mail.mobileip.jp
> Sent: Wednesday, April 15, 2009 6:43:05 PM
> Subject: Re: [Netext] next steps for netext
> 
> Hi Jong-Hyouk,
> 
>     Sorry for the delayed reply. I'll take a look at that draft and
> provide
> comments. Please, let me ask a short question (before I've read the
> draft): does the I-D look at any scenario involving an MN that changes
> its point of attachment between an MR (attached to a PMIPv6 domain)
> and
> a MAG?
> 
>     Thanks,
> 
>     Carlos
> 
> El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
> > Hi, Carlos. 
> >  
> > Good to see your posts in this mailing.. Anyway, the following
> document
> > has been expired would provide some scenarios for NEMO within PMIPv6
> > networks.
> >  
> > http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01
> >  
> > Have a good day!
> > 
> > 
> > 2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >        Hi Behcet,
> >        
> >        I've quickly checked the document. I think it does address
> the
> >        same
> >        problem I was referring to. This draft addresses the problem
> >        of
> >        delegating a prefix to a router that attaches to a PMIPv6
> >        domain, so
> >        it can provide connectivity to nodes attached to it. I think
> >        this was
> >        already discussed in a past meeting (a draft with the problem
> >        statement) and I mentioned that IMHO this can basically be
> >        achieved by
> >        just using plain NEMO support on the router. The only
> >        difference in
> >        this draft is that it doesn't impose the router to be a NEMO
> >        RFC3963
> >        MR, although still it needs to do some additional things that
> >        a normal
> >        router (not mobile) doesn't. Anyway, I'm not against this
> type
> >        of
> >        support if there are scenarios in which it's useful.
> >        
> >        However, the kind of NEMO+PMIPv6 support I'm considering goes
> >        a little
> >        bit beyond that, since what I want to enable is node to be
> >        able to
> >        benefit from network based localised mobility support not
> only
> >        when
> >        roaming between fixed points of attachment (this is what
> >        RFC5213 does
> >        today) but also when roaming between fixed and mobile points
> >        of
> >        attachment. What people do think about this scenario?
> >        
> >        Thanks,
> >        
> >        Carlos
> >        
> >        2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >        
> >        > Hi Carlos,
> >        >  Check this out:
> >        >
> >
> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
> >        >
> >        > Regards,
> >        >
> >        > Behcet
> >        >
> >        > ________________________________
> >        > From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >        > To: Jari Arkko <jari.arkko at piuha..net>
> >        > Cc: netext at mail.mobileip.jp
> >        > Sent: Tuesday, April 7, 2009 6:15:42 AM
> >        > Subject: Re: [Netext] next steps for netext
> >        >
> >        > Hi Jari, all,
> >        >
> >        > Regarding the NEMO topic, I don't know what Sri has in
> mind,
> >        but my
> >        > personal view on that is that it'd be nice to extend PMIPv6
> >        to support
> >        > mobile networks. What I mean here is that it'd be nice to
> >        enable MAGs
> >        > to also move (like MRs, but without even supporting
> >        RFC3963), so an MR
> >        > would be able to move between fixed and mobile MAGs without
> >        changing
> >        > its IP address (same support RFC5213 gives now). There are
> >        some
> >        > interesting scenarios that could benefit from this.
> >        >
> >        > What do others think? It is interesting to work on this?
> >        >
> >        > Thanks,
> >        >
> >        > Carlos
> >        >
> >        > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >        >> Sri,
> >        >>
> >        >> Thanks for your input. Inline:
> >        >>
> >        >>> I've a concern with the planned charter. The list is too
> >        random and
> >        >>> cherry picked and I dont believe proper input from all
> the
> >        folks went
> >        >>> into
> >        >>> this. There are many other items that are required for a
> >        reasonable
> >        >>> deployment of Proxy Mobile IPv6. Many items were proposed
> >        over the last 2
> >        >>> years, some of them that were left out in the base spec,
> >        some that we
> >        >>> realized as gaps when compared to other SDO protocols and
> >        some as
> >        >>> optimizations that we realized while implementing PMIP6,
> >        these items
> >        >>> should be in the initial scope.
> >        >>>
> >        >>> I understand the charter needs to be limited in scope,
> but
> >        just 3 or 4
> >        >>> random items, I'm not sure if this helps in short term
> >        PMIP6
> >        >>> requirements.
> >        >>> I've no issue with the currently listed items, but there
> >        are other items
> >        >>> that should get equal or higher priority.
> >        >>
> >        >> I have no problem with adding more. Even the charter says
> >        new things can
> >        >> be
> >        >> added.
> >        >>
> >        >> However, from a process perspective what I did was to take
> >        the proposal on
> >        >> the table, i.e., the full BOF scope and see what parts of
> >        that we already
> >        >> have an agreement on. I didn't include other things that
> >        were not
> >        >> discussed
> >        >> in the BOF. Maybe that would have been useful, but they
> >        were not on the
> >        >> table.
> >        >>
> >        >> We could add more items now, if there's general agreement
> >        that those
> >        >> things
> >        >> are useful. However, I do not want to declare an open
> >        season on doing
> >        >> everything. We pick a reasonable subset of all proposed
> >        work, based on
> >        >> priorities, community agreement that they are the right
> >        things to do,
> >        >> management reasons to ensure that we are not doing too
> >        much, etc.
> >        >>
> >        >>> For example, item #6, is absolutely required, from the
> >        perspective of
> >        >>> having a complete specification of 5213. There we allowed
> >        a mobile node
> >        >>> to
> >        >>> perform handoff betweek two interfaces. We defined all
> the
> >        hooks on the
> >        >>> network side, but we did not provide how a terminal
> vendor
> >        can support
> >        >>> that. A simple informational draft on how some one move
> >        prefixes between
> >        >>> interfaces will greatly help. Some guidance on how to
> >        create a virtual
> >        >>> interface and also some related notes for each platform
> >        (Linux, BSD,
> >        >>> Android ..etc). This should not fall in the controversial
> >        discussion
> >        >>> scope
> >        >>> of same address on two interfaces etc, thats a different
> >        problem, or
> >        >>> about
> >        >>> the issue of enhancing mobile node's capabilities. This
> is
> >        just
> >        >>> informational work, required to leverage what 5213
> already
> >        supports.
> >        >>
> >        >> I suspect this is about the scoping of the handoff work.
> >        Lets try to
> >        >> figure
> >        >> out what makes sense (I personally believe the above item
> >        makes sense, for
> >        >> instance) and what doesn't.
> >        >>
> >        >> The fact that these parts were not in the charter was not
> a
> >        declaration
> >        >> that
> >        >> we're dismissing them. Its just that we didn't finish the
> >        discussion, but
> >        >> I
> >        >> still wanted to let the other things move forward.
> >        >>
> >        >>> Item #2, is required. The multimob BOF raised some
> issues,
> >        we need to
> >        >>> show how multicast services can be enabled in PMIP
> >        network. May be this
> >        >>> wont require extensions, a simple draft covering those
> >        aspects will help.
> >        >>
> >        >> As you may recall, in the Multimob BOF we did not have an
> >        agreement on
> >        >> what
> >        >> exactly is needed, if anything. My own conclusion is that
> >        we probably need
> >        >> at least an informational document that explains how to
> use
> >        RFC 5213 for
> >        >> multicast. I think we discussed the possibility of doing
> >        this as some kind
> >        >> of AD sponsored document or in one of the relevant WGs, as
> >        a joint work
> >        >> between PMIP and multicast experts.
> >        >>
> >        >> I'm on the fence about adding this work to the charter
> >        right now, mainly
> >        >> because the BOF back then was very inconclusive. I'd be
> >        happier if I saw
> >        >> an
> >        >> actual well written draft from say you and some of the
> >        multicast experts.
> >        >> There's no problem moving good documents forward, even if
> >        they are not in
> >        >> the charter of some WG. Then again, I wouldn't necessarily
> >        mind a
> >        >> maintenance like item for this in one of the WG charters
> >        either.
> >        >>
> >        >>> I think, the charter should be bit more relaxed and more
> >        extensive. As I
> >        >>> see it, atleast the folks are interested in doing the
> >        work. We should add
> >        >>> atleast 4 or 5 more items to this list.
> >        >>
> >        >> Generally speaking IETF WG charters give specific work
> >        items that the WG
> >        >> should work on. I had hoped that the charter text:
> >        >>
> >        >> "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."
> >        >>
> >        >> gives an indication that we intend to do more! I am also
> >        personally very
> >        >> happy to add more items to the group's charter. All in
> all,
> >        I do know that
> >        >> the current charter is a bit on the thin side -- mostly
> >        because the
> >        >> multihoming/interaccess issue is under discussion.
> >        >>
> >        >> There's also the question of general maintenance items.
> >        Some IETF WGs have
> >        >> a
> >        >> general work item to fix problems and issue updates to
> >        existing
> >        >> specifications. I think we need to do that for Proxy
> Mobile
> >        IPv6 as well.
> >        >> But we have not decided whether that item should go to
> >        NETLMM or NETEXT WG
> >        >> yet. Please rest assured that the work will be possible
> >        regardless of
> >        >> this.
> >        >>
> >        >>> 1. Dynamic LMA Assignment
> >        >>>
> >        >>> In blade architecture systems or in a load balancer
> >        configuration, the
> >        >>> PDNGW
> >        >>> should have the ability to dynamically assign a LMA on
> the
> >        fly, along the
> >        >>> lines of Mobile IPv4 Dynamic Home Agent Address
> Assignment
> >        support
> >        >>> [RFC-4433].
> >        >>> Currently, GTP provides such semantics and this is a
> >        important
> >        >>> requirement
> >        >>> for deployment. Here the goal is to
> >        >>>
> >        >>> a.) Expose a single IP address to the SGW
> >        >>> b.) The exposed IP address should not be in path once the
> >        assignment is
> >        >>> done.
> >        >>>
> >        >>>
> >        >>>
> >        >>> [LMA1]---
> >        >>> | |
> >        >>> [LMA2]--[LMA]==========[MAG]
> >        >>> | |
> >        >>> [LMA3]---
> >        >>>
> >        >>>
> >        >>> Along the lines of:
> >        >>>
> >        >>>
> >        http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >        >>
> >        >> This is in the proposed NETEXT charter already.
> >        >>
> >        >>> 2. Multicast Support in Proxy Mobile IPv6
> >        >>>
> >        >>> We need an informational specification on how multicast
> >        support can be
> >        >>> enabled in Proxy Mobile IPv6 environment. Behcet has done
> >        extensive
> >        >>> analysis
> >        >>> on
> >        >>> this. This is required and critical for enabling any
> >        multicast services.
> >        >>> However,
> >        >>> Behcet may disagree with the scope of the work.
> >        >>
> >        >> See above.
> >        >>
> >        >>> 3. Bulk Registration Support
> >        >>>
> >        >>> This is a simple extension which helps in signaling
> >        optimization, along
> >        >>> the
> >        >>> lines of:
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >        >>
> >        >> This is in the charter as well.
> >        >>
> >        >>> 4. Partial Failover Support
> >        >>>
> >        >>> We need a mechanism to notify the peer on revoke a
> partial
> >        set of
> >        >>> bindings.
> >        >>>
> >        >>>
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
> >        >>> txt
> >        >>
> >        >> Hmm. Ok.. This needs more discussion.
> >        >>
> >        >>> 5. Group Identifier Support for Proxy Mobile IPv6
> >        >>>
> >        >>> This provides a simple and a generic semantic for
> >        assigning a group
> >        >>> identifier
> >        >>> to a mobile node's binding. GTP has very similar
> >        semantics, Connexion Set
> >        >>> Id.
> >        >>> Both #3 and #4 can leverage this. Additionally, in load
> >        balancer systems
> >        >>> where
> >        >>> the load balancer is in path for all signaling messages,
> >        it can use this
> >        >>> as
> >        >>> a
> >        >>> tag for redirecting the message.
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >        >>
> >        >> Since the bulk registration work is in the charter, can't
> >        you do the
> >        >> sensible design (whatever it is) under that? There is no
> >        requirement that
> >        >> one charter item equals one document.
> >        >>
> >        >>> 6. Virtual-Interface Support on IP host for supporting
> >        Inter-tech
> >        >>> handoffs:
> >        >>>
> >        >>>
> >        >>> RFC-5213 supports handoff between two interfaces. The
> >        ability to move
> >        >>> prefixes between interfaces. In other words address
> >        continuity is assured
> >        >>> with any IPv6 host on the planet and with absolutely no
> >        changes. This
> >        >>> meets
> >        >>> even Dave's comment, that "no changes to any IETF
> RFC's."..
> >        Now, what is
> >        >>> not assured is the aspect of session continuity. Which
> >        requires a virtual
> >        >>> interface implementation on the host, by binding the
> >        address/prefix to a
> >        >>> virtual interface and by not exposing the physical
> >        interface or by hiding
> >        >>> the handoff events from the layer-3 stack.
> >        >>>
> >        >>> In essence, we need an informational specification which
> >        provides some
> >        >>> general guidance to how to leverage the feature support
> >        provided in
> >        >>> RFC-5213,
> >        >>> along the lines of:
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >        >>
> >        >> This is part of the discussion that we need to finish. But
> >        I plan to let
> >        >> the
> >        >> rest of the stuff move forward even before we have done
> >        that.
> >        >>
> >        >>
> >        >>> 7. Route Optimization for Proxy Mobile IPv6
> >        >>>
> >        >>> There were atleast 4 drafts in this area on Route
> >        Optimization. Marco
> >        >>> Liebsch
> >        >>> analyzed this exensively:
> >        >>>
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >        >>>
> >        >>>
> >        >>>
> >
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
> >        >>> txt
> >        >>
> >        >> This is in the charter.
> >        >>
> >        >>> 8. Prefix Management in Proxy Mobile IPv6 support
> >        >>>
> >        >>> Proxy Mobile IPv6 allows the assignment of multiple home
> >        network prefixes
> >        >>> to a given mobile node's interface. It might be useful to
> >        specify how the
> >        >>> LMA manages this aspects. It can potentially use DHCP PD,
> >        Local Pools or
> >        >>> AAA to manage this aspect. Behcet has one draft on this.
> >        >>
> >        >> I'm not personally sold on this particular work. But
> again,
> >        this could be
> >        >> something to consider.
> >        >>
> >        >>> 9. Partial Handoff Support
> >        >>>
> >        >>> We are missing some semantics in 5213 for moving a subset
> >        of the prefixes
> >        >>> between interfaces as part of the inter-tech handoff.
> This
> >        is about
> >        >>> defining
> >        >>> a new handoff value. This allows partial flow management,
> >        but moving the
> >        >>> flows associated to a prefix, as a whole group.
> >        >>>
> >        >>>
> >        >>>
> >
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >        >>
> >        >> A part of the topic we still need to discuss...
> >        >>
> >        >>> 10. CMIPv4/PMIP Interworking
> >        >>>
> >        >>> This is probably required to specify how an IPv4-only can
> >        move between
> >        >>> CMIP and PMIP environments.
> >        >>>
> >        >>>
> >        >>>
> >        >>>
> >
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >        >>> meghana-netlmm-pmipv6-mipv4-00.txt
> >        >>
> >        >> Client MIPv6 and Proxy MIPv6 interoperability is already
> in
> >        the NETLMM
> >        >> charter, but this work is presumably about interaction
> with
> >        MIPv4. Might
> >        >> be
> >        >> useful work, I wouldn't mind if this was done in NETEXT at
> >        some point. Is
> >        >> this crucial to be in the first revision of the WG's
> >        charter?
> >        >>
> >        >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile
> >        IPv6
> >        >>
> >        >> Can you expand on this?
> >        >>
> >        >> Jari
> >        >>
> >        >> _______________________________________________
> >        >> 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
> >        >
> >        >
> >        
> >        _______________________________________________
> >        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/
> -- 
>   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 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
-- 
   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/20090416/86afae7c/attachment.bin>

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Thu, 16 Apr 2009 07:35:49 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <1239838985.4695.114.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239838985.4695.114.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,
? According to Ryuji's draft MN is the MR. Also in RFC 3963 MR is also MN for HA. So this architecture is consistent with the original Nemo BSP design.
? It seems like you have a different architecture in mind. I think that's where the confusion comes.

Regards,

Behcet

________________________________
From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
To: Jong-Hyouk Lee <jonghyouk at gmail.com>
Cc: netext at mail.mobileip.jp
Sent: Wednesday, April 15, 2009 6:43:05 PM
Subject: Re: [Netext] next steps for netext

Hi Jong-Hyouk,

??? Sorry for the delayed reply. I'll take a look at that draft and provide
comments. Please, let me ask a short question (before I've read the
draft): does the I-D look at any scenario involving an MN that changes
its point of attachment between an MR (attached to a PMIPv6 domain) and
a MAG?

??? Thanks,

??? Carlos

El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
> Hi, Carlos. 
>? 
> Good to see your posts in this mailing. Anyway, the following document
> has been expired would provide some scenarios for NEMO within PMIPv6
> networks.
>? 
> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01
>? 
> Have a good day!
> 
> 
> 2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>? ? ? ? Hi Behcet,
>? ? ? ? 
>? ? ? ? I've quickly checked the document. I think it does address the
>? ? ? ? same
>? ? ? ? problem I was referring to. This draft addresses the problem
>? ? ? ? of
>? ? ? ? delegating a prefix to a router that attaches to a PMIPv6
>? ? ? ? domain, so
>? ? ? ? it can provide connectivity to nodes attached to it. I think
>? ? ? ? this was
>? ? ? ? already discussed in a past meeting (a draft with the problem
>? ? ? ? statement) and I mentioned that IMHO this can basically be
>? ? ? ? achieved by
>? ? ? ? just using plain NEMO support on the router. The only
>? ? ? ? difference in
>? ? ? ? this draft is that it doesn't impose the router to be a NEMO
>? ? ? ? RFC3963
>? ? ? ? MR, although still it needs to do some additional things that
>? ? ? ? a normal
>? ? ? ? router (not mobile) doesn't. Anyway, I'm not against this type
>? ? ? ? of
>? ? ? ? support if there are scenarios in which it's useful.
>? ? ? ? 
>? ? ? ? However, the kind of NEMO+PMIPv6 support I'm considering goes
>? ? ? ? a little
>? ? ? ? bit beyond that, since what I want to enable is node to be
>? ? ? ? able to
>? ? ? ? benefit from network based localised mobility support not only
>? ? ? ? when
>? ? ? ? roaming between fixed points of attachment (this is what
>? ? ? ? RFC5213 does
>? ? ? ? today) but also when roaming between fixed and mobile points
>? ? ? ? of
>? ? ? ? attachment. What people do think about this scenario?
>? ? ? ? 
>? ? ? ? Thanks,
>? ? ? ? 
>? ? ? ? Carlos
>? ? ? ? 
>? ? ? ? 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>? ? ? ? 
>? ? ? ? > Hi Carlos,
>? ? ? ? >? Check this out:
>? ? ? ? >
>? ? ? ? http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
>? ? ? ? >
>? ? ? ? > Regards,
>? ? ? ? >
>? ? ? ? > Behcet
>? ? ? ? >
>? ? ? ? > ________________________________
>? ? ? ? > From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>? ? ? ? > To: Jari Arkko <jari.arkko at piuha.net>
>? ? ? ? > Cc: netext at mail.mobileip.jp
>? ? ? ? > Sent: Tuesday, April 7, 2009 6:15:42 AM
>? ? ? ? > Subject: Re: [Netext] next steps for netext
>? ? ? ? >
>? ? ? ? > Hi Jari, all,
>? ? ? ? >
>? ? ? ? > Regarding the NEMO topic, I don't know what Sri has in mind,
>? ? ? ? but my
>? ? ? ? > personal view on that is that it'd be nice to extend PMIPv6
>? ? ? ? to support
>? ? ? ? > mobile networks. What I mean here is that it'd be nice to
>? ? ? ? enable MAGs
>? ? ? ? > to also move (like MRs, but without even supporting
>? ? ? ? RFC3963), so an MR
>? ? ? ? > would be able to move between fixed and mobile MAGs without
>? ? ? ? changing
>? ? ? ? > its IP address (same support RFC5213 gives now). There are
>? ? ? ? some
>? ? ? ? > interesting scenarios that could benefit from this.
>? ? ? ? >
>? ? ? ? > What do others think? It is interesting to work on this?
>? ? ? ? >
>? ? ? ? > Thanks,
>? ? ? ? >
>? ? ? ? > Carlos
>? ? ? ? >
>? ? ? ? > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>? ? ? ? >> Sri,
>? ? ? ? >>
>? ? ? ? >> Thanks for your input. Inline:
>? ? ? ? >>
>? ? ? ? >>> I've a concern with the planned charter. The list is too
>? ? ? ? random and
>? ? ? ? >>> cherry picked and I dont believe proper input from all the
>? ? ? ? folks went
>? ? ? ? >>> into
>? ? ? ? >>> this. There are many other items that are required for a
>? ? ? ? reasonable
>? ? ? ? >>> deployment of Proxy Mobile IPv6. Many items were proposed
>? ? ? ? over the last 2
>? ? ? ? >>> years, some of them that were left out in the base spec,
>? ? ? ? some that we
>? ? ? ? >>> realized as gaps when compared to other SDO protocols and
>? ? ? ? some as
>? ? ? ? >>> optimizations that we realized while implementing PMIP6,
>? ? ? ? these items
>? ? ? ? >>> should be in the initial scope.
>? ? ? ? >>>
>? ? ? ? >>> I understand the charter needs to be limited in scope, but
>? ? ? ? just 3 or 4
>? ? ? ? >>> random items, I'm not sure if this helps in short term
>? ? ? ? PMIP6
>? ? ? ? >>> requirements.
>? ? ? ? >>> I've no issue with the currently listed items, but there
>? ? ? ? are other items
>? ? ? ? >>> that should get equal or higher priority.
>? ? ? ? >>
>? ? ? ? >> I have no problem with adding more. Even the charter says
>? ? ? ? new things can
>? ? ? ? >> be
>? ? ? ? >> added.
>? ? ? ? >>
>? ? ? ? >> However, from a process perspective what I did was to take
>? ? ? ? the proposal on
>? ? ? ? >> the table, i.e., the full BOF scope and see what parts of
>? ? ? ? that we already
>? ? ? ? >> have an agreement on. I didn't include other things that
>? ? ? ? were not
>? ? ? ? >> discussed
>? ? ? ? >> in the BOF. Maybe that would have been useful, but they
>? ? ? ? were not on the
>? ? ? ? >> table.
>? ? ? ? >>
>? ? ? ? >> We could add more items now, if there's general agreement
>? ? ? ? that those
>? ? ? ? >> things
>? ? ? ? >> are useful. However, I do not want to declare an open
>? ? ? ? season on doing
>? ? ? ? >> everything. We pick a reasonable subset of all proposed
>? ? ? ? work, based on
>? ? ? ? >> priorities, community agreement that they are the right
>? ? ? ? things to do,
>? ? ? ? >> management reasons to ensure that we are not doing too
>? ? ? ? much, etc.
>? ? ? ? >>
>? ? ? ? >>> For example, item #6, is absolutely required, from the
>? ? ? ? perspective of
>? ? ? ? >>> having a complete specification of 5213. There we allowed
>? ? ? ? a mobile node
>? ? ? ? >>> to
>? ? ? ? >>> perform handoff betweek two interfaces. We defined all the
>? ? ? ? hooks on the
>? ? ? ? >>> network side, but we did not provide how a terminal vendor
>? ? ? ? can support
>? ? ? ? >>> that. A simple informational draft on how some one move
>? ? ? ? prefixes between
>? ? ? ? >>> interfaces will greatly help. Some guidance on how to
>? ? ? ? create a virtual
>? ? ? ? >>> interface and also some related notes for each platform
>? ? ? ? (Linux, BSD,
>? ? ? ? >>> Android ..etc). This should not fall in the controversial
>? ? ? ? discussion
>? ? ? ? >>> scope
>? ? ? ? >>> of same address on two interfaces etc, thats a different
>? ? ? ? problem, or
>? ? ? ? >>> about
>? ? ? ? >>> the issue of enhancing mobile node's capabilities. This is
>? ? ? ? just
>? ? ? ? >>> informational work, required to leverage what 5213 already
>? ? ? ? supports.
>? ? ? ? >>
>? ? ? ? >> I suspect this is about the scoping of the handoff work.
>? ? ? ? Lets try to
>? ? ? ? >> figure
>? ? ? ? >> out what makes sense (I personally believe the above item
>? ? ? ? makes sense, for
>? ? ? ? >> instance) and what doesn't.
>? ? ? ? >>
>? ? ? ? >> The fact that these parts were not in the charter was not a
>? ? ? ? declaration
>? ? ? ? >> that
>? ? ? ? >> we're dismissing them. Its just that we didn't finish the
>? ? ? ? discussion, but
>? ? ? ? >> I
>? ? ? ? >> still wanted to let the other things move forward.
>? ? ? ? >>
>? ? ? ? >>> Item #2, is required. The multimob BOF raised some issues,
>? ? ? ? we need to
>? ? ? ? >>> show how multicast services can be enabled in PMIP
>? ? ? ? network. May be this
>? ? ? ? >>> wont require extensions, a simple draft covering those
>? ? ? ? aspects will help.
>? ? ? ? >>
>? ? ? ? >> As you may recall, in the Multimob BOF we did not have an
>? ? ? ? agreement on
>? ? ? ? >> what
>? ? ? ? >> exactly is needed, if anything. My own conclusion is that
>? ? ? ? we probably need
>? ? ? ? >> at least an informational document that explains how to use
>? ? ? ? RFC 5213 for
>? ? ? ? >> multicast. I think we discussed the possibility of doing
>? ? ? ? this as some kind
>? ? ? ? >> of AD sponsored document or in one of the relevant WGs, as
>? ? ? ? a joint work
>? ? ? ? >> between PMIP and multicast experts.
>? ? ? ? >>
>? ? ? ? >> I'm on the fence about adding this work to the charter
>? ? ? ? right now, mainly
>? ? ? ? >> because the BOF back then was very inconclusive. I'd be
>? ? ? ? happier if I saw
>? ? ? ? >> an
>? ? ? ? >> actual well written draft from say you and some of the
>? ? ? ? multicast experts.
>? ? ? ? >> There's no problem moving good documents forward, even if
>? ? ? ? they are not in
>? ? ? ? >> the charter of some WG. Then again, I wouldn't necessarily
>? ? ? ? mind a
>? ? ? ? >> maintenance like item for this in one of the WG charters
>? ? ? ? either.
>? ? ? ? >>
>? ? ? ? >>> I think, the charter should be bit more relaxed and more
>? ? ? ? extensive. As I
>? ? ? ? >>> see it, atleast the folks are interested in doing the
>? ? ? ? work. We should add
>? ? ? ? >>> atleast 4 or 5 more items to this list.
>? ? ? ? >>
>? ? ? ? >> Generally speaking IETF WG charters give specific work
>? ? ? ? items that the WG
>? ? ? ? >> should work on. I had hoped that the charter text:
>? ? ? ? >>
>? ? ? ? >> "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."
>? ? ? ? >>
>? ? ? ? >> gives an indication that we intend to do more! I am also
>? ? ? ? personally very
>? ? ? ? >> happy to add more items to the group's charter. All in all,
>? ? ? ? I do know that
>? ? ? ? >> the current charter is a bit on the thin side -- mostly
>? ? ? ? because the
>? ? ? ? >> multihoming/interaccess issue is under discussion.
>? ? ? ? >>
>? ? ? ? >> There's also the question of general maintenance items.
>? ? ? ? Some IETF WGs have
>? ? ? ? >> a
>? ? ? ? >> general work item to fix problems and issue updates to
>? ? ? ? existing
>? ? ? ? >> specifications. I think we need to do that for Proxy Mobile
>? ? ? ? IPv6 as well.
>? ? ? ? >> But we have not decided whether that item should go to
>? ? ? ? NETLMM or NETEXT WG
>? ? ? ? >> yet. Please rest assured that the work will be possible
>? ? ? ? regardless of
>? ? ? ? >> this.
>? ? ? ? >>
>? ? ? ? >>> 1. Dynamic LMA Assignment
>? ? ? ? >>>
>? ? ? ? >>> In blade architecture systems or in a load balancer
>? ? ? ? configuration, the
>? ? ? ? >>> PDNGW
>? ? ? ? >>> should have the ability to dynamically assign a LMA on the
>? ? ? ? fly, along the
>? ? ? ? >>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment
>? ? ? ? support
>? ? ? ? >>> [RFC-4433].
>? ? ? ? >>> Currently, GTP provides such semantics and this is a
>? ? ? ? important
>? ? ? ? >>> requirement
>? ? ? ? >>> for deployment. Here the goal is to
>? ? ? ? >>>
>? ? ? ? >>> a.) Expose a single IP address to the SGW
>? ? ? ? >>> b.) The exposed IP address should not be in path once the
>? ? ? ? assignment is
>? ? ? ? >>> done.
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>> [LMA1]---
>? ? ? ? >>> | |
>? ? ? ? >>> [LMA2]--[LMA]==========[MAG]
>? ? ? ? >>> | |
>? ? ? ? >>> [LMA3]---
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>> Along the lines of:
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>? ? ? ? >>
>? ? ? ? >> This is in the proposed NETEXT charter already.
>? ? ? ? >>
>? ? ? ? >>> 2. Multicast Support in Proxy Mobile IPv6
>? ? ? ? >>>
>? ? ? ? >>> We need an informational specification on how multicast
>? ? ? ? support can be
>? ? ? ? >>> enabled in Proxy Mobile IPv6 environment. Behcet has done
>? ? ? ? extensive
>? ? ? ? >>> analysis
>? ? ? ? >>> on
>? ? ? ? >>> this. This is required and critical for enabling any
>? ? ? ? multicast services.
>? ? ? ? >>> However,
>? ? ? ? >>> Behcet may disagree with the scope of the work.
>? ? ? ? >>
>? ? ? ? >> See above.
>? ? ? ? >>
>? ? ? ? >>> 3. Bulk Registration Support
>? ? ? ? >>>
>? ? ? ? >>> This is a simple extension which helps in signaling
>? ? ? ? optimization, along
>? ? ? ? >>> the
>? ? ? ? >>> lines of:
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>? ? ? ? >>
>? ? ? ? >> This is in the charter as well.
>? ? ? ? >>
>? ? ? ? >>> 4. Partial Failover Support
>? ? ? ? >>>
>? ? ? ? >>> We need a mechanism to notify the peer on revoke a partial
>? ? ? ? set of
>? ? ? ? >>> bindings.
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>? ? ? ? >>> txt
>? ? ? ? >>
>? ? ? ? >> Hmm. Ok. This needs more discussion.
>? ? ? ? >>
>? ? ? ? >>> 5. Group Identifier Support for Proxy Mobile IPv6
>? ? ? ? >>>
>? ? ? ? >>> This provides a simple and a generic semantic for
>? ? ? ? assigning a group
>? ? ? ? >>> identifier
>? ? ? ? >>> to a mobile node's binding. GTP has very similar
>? ? ? ? semantics, Connexion Set
>? ? ? ? >>> Id.
>? ? ? ? >>> Both #3 and #4 can leverage this.. Additionally, in load
>? ? ? ? balancer systems
>? ? ? ? >>> where
>? ? ? ? >>> the load balancer is in path for all signaling messages,
>? ? ? ? it can use this
>? ? ? ? >>> as
>? ? ? ? >>> a
>? ? ? ? >>> tag for redirecting the message.
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>? ? ? ? >>
>? ? ? ? >> Since the bulk registration work is in the charter, can't
>? ? ? ? you do the
>? ? ? ? >> sensible design (whatever it is) under that? There is no
>? ? ? ? requirement that
>? ? ? ? >> one charter item equals one document.
>? ? ? ? >>
>? ? ? ? >>> 6. Virtual-Interface Support on IP host for supporting
>? ? ? ? Inter-tech
>? ? ? ? >>> handoffs:
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>> RFC-5213 supports handoff between two interfaces. The
>? ? ? ? ability to move
>? ? ? ? >>> prefixes between interfaces. In other words address
>? ? ? ? continuity is assured
>? ? ? ? >>> with any IPv6 host on the planet and with absolutely no
>? ? ? ? changes. This
>? ? ? ? >>> meets
>? ? ? ? >>> even Dave's comment, that "no changes to any IETF RFC's.".
>? ? ? ? Now, what is
>? ? ? ? >>> not assured is the aspect of session continuity. Which
>? ? ? ? requires a virtual
>? ? ? ? >>> interface implementation on the host, by binding the
>? ? ? ? address/prefix to a
>? ? ? ? >>> virtual interface and by not exposing the physical
>? ? ? ? interface or by hiding
>? ? ? ? >>> the handoff events from the layer-3 stack.
>? ? ? ? >>>
>? ? ? ? >>> In essence, we need an informational specification which
>? ? ? ? provides some
>? ? ? ? >>> general guidance to how to leverage the feature support
>? ? ? ? provided in
>? ? ? ? >>> RFC-5213,
>? ? ? ? >>> along the lines of:
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>? ? ? ? >>
>? ? ? ? >> This is part of the discussion that we need to finish. But
>? ? ? ? I plan to let
>? ? ? ? >> the
>? ? ? ? >> rest of the stuff move forward even before we have done
>? ? ? ? that.
>? ? ? ? >>
>? ? ? ? >>
>? ? ? ? >>> 7. Route Optimization for Proxy Mobile IPv6
>? ? ? ? >>>
>? ? ? ? >>> There were atleast 4 drafts in this area on Route
>? ? ? ? Optimization. Marco
>? ? ? ? >>> Liebsch
>? ? ? ? >>> analyzed this exensively:
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>? ? ? ? >>> txt
>? ? ? ? >>
>? ? ? ? >> This is in the charter.
>? ? ? ? >>
>? ? ? ? >>> 8. Prefix Management in Proxy Mobile IPv6 support
>? ? ? ? >>>
>? ? ? ? >>> Proxy Mobile IPv6 allows the assignment of multiple home
>? ? ? ? network prefixes
>? ? ? ? >>> to a given mobile node's interface. It might be useful to
>? ? ? ? specify how the
>? ? ? ? >>> LMA manages this aspects. It can potentially use DHCP PD,
>? ? ? ? Local Pools or
>? ? ? ? >>> AAA to manage this aspect. Behcet has one draft on this.
>? ? ? ? >>
>? ? ? ? >> I'm not personally sold on this particular work. But again,
>? ? ? ? this could be
>? ? ? ? >> something to consider.
>? ? ? ? >>
>? ? ? ? >>> 9. Partial Handoff Support
>? ? ? ? >>>
>? ? ? ? >>> We are missing some semantics in 5213 for moving a subset
>? ? ? ? of the prefixes
>? ? ? ? >>> between interfaces as part of the inter-tech handoff. This
>? ? ? ? is about
>? ? ? ? >>> defining
>? ? ? ? >>> a new handoff value. This allows partial flow management,
>? ? ? ? but moving the
>? ? ? ? >>> flows associated to a prefix, as a whole group.
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>? ? ? ? >>
>? ? ? ? >> A part of the topic we still need to discuss...
>? ? ? ? >>
>? ? ? ? >>> 10. CMIPv4/PMIP Interworking
>? ? ? ? >>>
>? ? ? ? >>> This is probably required to specify how an IPv4-only can
>? ? ? ? move between
>? ? ? ? >>> CMIP and PMIP environments.
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? >>>
>? ? ? ? http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>? ? ? ? >>> meghana-netlmm-pmipv6-mipv4-00.txt
>? ? ? ? >>
>? ? ? ? >> Client MIPv6 and Proxy MIPv6 interoperability is already in
>? ? ? ? the NETLMM
>? ? ? ? >> charter, but this work is presumably about interaction with
>? ? ? ? MIPv4. Might
>? ? ? ? >> be
>? ? ? ? >> useful work, I wouldn't mind if this was done in NETEXT at
>? ? ? ? some point. Is
>? ? ? ? >> this crucial to be in the first revision of the WG's
>? ? ? ? charter?
>? ? ? ? >>
>? ? ? ? >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile
>? ? ? ? IPv6
>? ? ? ? >>
>? ? ? ? >> Can you expand on this?
>? ? ? ? >>
>? ? ? ? >> Jari
>? ? ? ? >>
>? ? ? ? >> _______________________________________________
>? ? ? ? >> 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
>? ? ? ? >
>? ? ? ? >
>? ? ? ? 
>? ? ? ? _______________________________________________
>? ? ? ? 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/
-- 
? 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090416/97048a7a/attachment-0001.html>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Thu, 16 Apr 2009 14:26:43 +0300
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

On Apr 16, 2009, at 12:10 AM, Vijay Devarapalli wrote:

> Hi Jouni,
>
> Experimental RFC does not mean it is intended for experiments in a  
> lab. :)
>
> FWIW, Standards Track means that the IETF thinks that this is the  
> best possible solution for a particular problem. This is not true in  
> this case, as many vendors already do LMA load balancing in an  
> implementation specific manner transparently without modifying the  
> protocol exchange with the MAG.

This is an interesting definition of STD Track and differs my  
understanding of BCP9. I wouldn't regard LMA redirection as a "part of  
some research or development effort" that needs to be documented "as  
an archival record of the work" ;)  Anyway, regarding the transparent  
load balancers. It is what folks do, including us (me..? hmm  
whatever). If you reach the point where you think that such solution  
is not adequate for foreseen deployments, then one approach is to add  
a protocol level support as several other protocols have done. Both  
approaches can co-exist in the same deployment.

Cheers,
	Jouni

> If it turns out that this LMA redirect mechanism does get  
> implemented and used widely, we can revise the experimental RFC and  
> get it published as a Standards Track document. We have done this  
> for a number of a documents in the path.
>
> More inline...
>
> jouni wrote:
>> Hi Vijay,
>> On Apr 15, 2009, at 9:06 PM, Vijay Devarapalli wrote:
>>> Hello,
>>>
>>> I have a comment on one of the items proposed.
>>>
>>> IESG Secretary wrote:
>>>
>>>> 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, and is complementary to the initial LMA discovery work  
>>>> in the
>>>> NETLMM WG.
>>>> January 2009 Submit LMA Redirection to IESG for publication as a
>>>> Proposed Standard RFC
>>>
>>> I would like to see this as an Experimental RFC.
>>>
>>> Based on the discussions I had with the authors on this draft, the  
>>> main motivation for this work seems to be the need for load  
>>> balancing across multiple application blades in a multi-blade  
>>> chassis platform for the LMA. Typically, when you have a multi- 
>>> blade chassis, load balancing or the distribution of sessions  
>>> across blades, as I like to call it, is done transparently. This  
>>> is not visible to any external node. The whole chassis appears as  
>>> a one LMA to the external network. Folks are trying to use the  
>>> redirect mechanism, basically telling the MAG to go to another  
>>> blade, during session setup for load balancing. This introduces an  
>>> additional round trip for most sessions.
>> Whether a LMA is a blade in a chassis or a separate box has no  
>> difference what we are trying to achieve. It is true that you can  
>> do load balancing "transparently" but in that case the traffic will  
>> always go through the "visible LMA" that was initially exposed to  
>> MAGs.. and at least I want to avoid that.
>
> This is not an issue for many deployments.
>
>> Relocating LMA at the protocol level seems the most solid way of  
>> doing it.
>
> Sorry, I don't agree with this.
>
> Vijay
>
> Also, there are no additional roundtrips
>> during the mobility session setup at the protocol level. That is  
>> also one of the goals we are trying to achieve.
>> Im my opinion LMA redirection needs to be standards track. It is  
>> not targeted for any experimental testing but deployments where  
>> scalability is a real concern.
>> Cheers,
>>    Jouni
>>>
>>>
>>> I had some reservations on this work item from the beginning. We  
>>> unfortunately couldn't discuss this in the BoF as there was very  
>>> little time for this. But I do acknowledge that there is some  
>>> interest in seeing this extension standardized.
>>>
>>> Having this redirect mechanism on Standards Track is not something  
>>> I am comfortable with right now. Load balancing across multiple  
>>> blades can be done in an implementation specific manner.
>>>
>>> Vijay
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Thu, 16 Apr 2009 11:38:39 +0100
Subject: [Netext] Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This draft is relevant to the discussion regarding the more
controversial proposed extensions of PMIPv6.

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-controversy-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

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 16 Apr 2009 15:41:22 +0800
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi George,

Thanks for putting forward some of your thoughts. 

But I really cant agree on the fact that the Netxt charter should state "no MN involvement". Yes, it made sense in the NetLMM WG because the goal of that working group is to support unmodified host. I cant see any document that says protocols that can interwork with PMIPv6 to support inter accesstechnology handoff or multihoming MUST not be explored by IETF.
Agree, MIP6 can achieve this but as many of us feel, there are other ways
and why not explore. 

Anyway, the goal of Netext is to look at possible feature add on including inter access technlogy handoff and multihoming(controversial ones currently) and the already accepted ones. So definitely we should not have this kind of mandate as no MN involvement in the charter. Anyway we had MIP6 initially and we then worked on HMIP by introducing a new local mobility anchor in the network. So, it is perfectly fine to explore how to achieve multihoming, inter access handoff when there is a network based mobility management support in the cornetowrk which is PMIP. 

As Rajeev mentioned MIP6 is one way, but there is nothing stopping from exploring more.

Thanks.
BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
> Sent: Wednesday, April 15, 2009 4:59 AM
> To: Jari Arkko
> Cc: netext at mail.mobileip.jp; iesg at ietf.org
> Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions
> (netext)
> 
> Hi Jari et.al.,
> 
> I think the work items listed reflect the current level of agreement
> on this work, but I would like to see the following limitation in the
> charter.
> 
> I would suggest that a statement reaffirming the "no MN involvement"
> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
> Charter, and which is still the basis for the existence of PMIPv6, is
> still valid in this new WG, tasked with extending it.
> 
> Just for people who do not remember, the NETLMM charter states (in
> multiple places) that:
> "  ...all features defined must work with unmodified IP nodes.
> Specifying any changes to mobile nodes is out of scope of the current
> charter".
> 
> I suggest that the same clause is added in the NETEXT charter, at
> least in this version of the charter, and at least until the
> discussion about the more controversial work items (inter-technology
> handoffs and multihoming) concludes.
> 
> Regards
> George
> 
> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary <iesg-secretary at ietf.org>
> wrote:
> > A new IETF working group has been proposed in the Internet Area. ?The
> IESG
> > has not made any determination as yet. ?The following draft charter was
> > submitted, and is provided for informational purposes only. ?Please send
> > your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, April
> > 21, 2009.
> >
> > Network-Based Mobility Extensions (netext)
> > -------------------------------------------------------------
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts
> > are not affected, as they still send and receive their packets via the
> > MAG.
> >
> > 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, and is complementary to the initial LMA discovery work in the
> > NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009 WG chartered
> > July 2009 Initial WG draft on Bulk Refresh
> > 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 2009 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
> > _______________________________________________
> > 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

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Thu, 16 Apr 2009 02:15:57 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

I support netext WG, but I need one clarification.

Once we have netext WG, the current NETLMM will be shutted down?
The proposed items is only minor modifications to PMIP,
do we need separate WG to discuss this?
If we will have multihoming topic which will require certain  
modifications to PMIP,
it does make sense to have a separate WG.

thanks,
ryuji

On 2009/04/14, at 16:00, IESG Secretary wrote:

> A new IETF working group has been proposed in the Internet Area.   
> The IESG
> has not made any determination as yet.  The following draft charter  
> was
> submitted, and is provided for informational purposes only.  Please  
> send
> your comments to the IESG mailing list (iesg at ietf.org) by Tuesday,  
> April
> 21, 2009.
>
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
>
> Last Modified: 2009-04-03
>
> 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. Hosts
> are not affected, as they still send and receive their packets via the
> MAG.
>
> 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, and is complementary to the initial LMA discovery work in  
> the
> NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> 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 2009 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
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Thu, 16 Apr 2009 02:11:34 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay and Sri,

The scalability issue of LMA is somewhat important, however, as Vijay  
mentioned, there are several ways to achieve scaling LMA.
If we will discuss LMA load-balancing and other related topics (LMA  
failure recovery like HA reliability discussed in MEXT),
we need a standard-track solution. I would like to see more complete  
solution covering similar issues (load-balancing, failure recovery,  
etc).

regards,
ryuji

On 2009/04/15, at 14:55, Vijay Devarapalli wrote:

> Hello Sri,
>
> The scalability problem as you mentioned below can be done in an
> implementation specific manner. Many vendors already have solutions
> where scalability is handled in a multi-blade chassis architecture
> transparently without modifying the Proxy BU/Proxy BAck signaling with
> the MAG.
>
> We can't have solutions that address limitations in scaling in some
> vendor's platform architecture on the Standards Track in the IETF.
>
> Vijay
>
>
>> -----Original Message-----
>> From: Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: Wednesday, April 15, 2009 11:35 AM
>> To: Vijay Devarapalli
>> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>> Extensions (netext)
>>
>> It has to be more generic. If the serving LMA's are configured on
>> individual blades, in a blade architecture system, or if the
>> blades are standalone systems, is upto the given deployment.
>>
>> As I see it, it requires each of the serving LMA to be reachable  
>> using
>> an IP address, so for all practical purposes they are
>> indivual nodes. If
>> these nodes endup as blades, that is fine and the solution is still
>> generic enough.
>>
>> This should be on standards track, it addresses a practical  
>> deployment
>> or scalability problem.
>>
>> Sri
>>
>>
>> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
>>
>>> Hello,
>>>
>>> I have a comment on one of the items proposed.
>>>
>>> IESG Secretary wrote:
>>>
>>>> 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, and is complementary to the initial LMA
>> discovery work in the
>>>> NETLMM WG.
>>>>
>>>> January 2009 Submit LMA Redirection to IESG for publication as a
>>>> Proposed Standard RFC
>>>
>>> I would like to see this as an Experimental RFC.
>>>
>>> Based on the discussions I had with the authors on this
>> draft, the main
>>> motivation for this work seems to be the need for load
>> balancing across
>>> multiple application blades in a multi-blade chassis
>> platform for the LMA.
>>> Typically, when you have a multi-blade chassis, load
>> balancing or the
>>> distribution of sessions across blades, as I like to call
>> it, is done
>>> transparently. This is not visible to any external node.
>> The whole chassis
>>> appears as a one LMA to the external network. Folks are
>> trying to use the
>>> redirect mechanism, basically telling the MAG to go to
>> another blade, during
>>> session setup for load balancing. This introduces an
>> additional round trip
>>> for most sessions.
>>>
>>> I had some reservations on this work item from the beginning. We
>>> unfortunately couldn't discuss this in the BoF as there was
>> very little time
>>> for this. But I do acknowledge that there is some interest
>> in seeing this
>>> extension standardized.
>>>
>>> Having this redirect mechanism on Standards Track is not
>> something I am
>>> comfortable with right now. Load balancing across multiple
>> blades can be done
>>> in an implementation specific manner.
>>>
>>> Vijay
>>>
>>> _______________________________________________
>>> 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

From: w52006 at huawei.com (Yungui Wang)
Date: Thu, 16 Apr 2009 10:44:20 +0800
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

This topic is interesting. Regarding of implementation, you both mentioned 
mechanisms are feasible and deployed somewhere. However, whether 
transparently or using explicit redirect message, I think, is mostly fited
to the 
case of blades(LMA) in a chassis. If each LMA is a separate box,  another 
mechanism that MAG re-selects LMA may be more common.  Propose that 
is reflected into the charter or draft as well.

B.R.
Yungui 

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Vijay 
> Devarapalli
> Sent: Thursday, April 16, 2009 6:15 AM
> To: Sri Gundavelli
> Cc: netext at mail.mobileip.jp
> Subject: [Netext] LMA redirection (was RE: WG Review: 
> Network-Based MobilityExtensions (netext))
> 
> Hi Sri, 
> 
> > Ok. How can we prove it either way. Lets hear from the
> > WG, if how many other folks have concerns keeping it on
> > standards track.
> > 
> > Either way, as I was told the planned charter evolved
> > based on the BOF WG feedback.
> 
> There was less than 5 minutes for this presentation. I 
> couldn't even go
> to the mike and saying something. But I had already given feedback on
> this to the authors, to the chairs and to you offline before 
> and during
> the IETF meeting. 
> 
> Before the BoF, there hasn't been any discussion on this on 
> the mailing
> list. 
> 
> I was actually surprised to see this on the charter.
> 
> > >> and we need a ratified well thought out
> > >> solution and not with the purpose of gathering more practical
> > >> data via experimental track.
> > >
> > > An experimental RFC does not mean it is intended for 
> > testbeds and such.
> > > It just means we are not sure if this is *the* solution.
> > >
> > 
> > But, I'm sure we need this :), just as you are not sure.
> 
> FWIW, there a lot of vendors who already do this kind of load 
> balancing
> across blades in a chassis without modifying the protocol exchanges.
> What more proof do you need?
> 
> Vijay
> 
> > 
> > Lets hear from the WG ...
> > 
> > Thanks
> > Sri
> > 
> > 
> 
> _______________________________________________
> 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: Thu, 16 Apr 2009 09:58:21 +0800
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

Thanks for proposing WG. However,

- Inter-Tech handoffs and multihoming should be there. Industry needs
this work and there is lot of support for this work as we have seen in
the ML.
IETF needs to work on this.

Thanks again.
BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of IESG Secretary
> Sent: Wednesday, April 15, 2009 4:00 AM
> To: ietf-announce at ietf.org
> Cc: netext at mail.mobileip.jp
> Subject: [Netext] WG Review: Network-Based Mobility Extensions
(netext)
> 
> A new IETF working group has been proposed in the Internet Area.  The
IESG
> has not made any determination as yet.  The following draft charter
was
> submitted, and is provided for informational purposes only.  Please
send
> your comments to the IESG mailing list (iesg at ietf.org) by Tuesday,
April
> 21, 2009.
> 
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts
> are not affected, as they still send and receive their packets via the
> MAG.
> 
> 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, and is complementary to the initial LMA discovery work in
the
> NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> 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 2009 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
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Thu, 16 Apr 2009 10:26:03 +0900
Subject: [Netext] next steps for netext
In-Reply-To: <1239838985.4695.114.camel@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <1239838985.4695.114.camel@localhost>
Message-ID: <[email-masked]>

Hi. Carlos.

In the I-D, four types of scenarios are presented. All of them mainly
focuses on the MR involving nodes hands off between MAGs or LMAs
(intra-domain handoff and inter-domain handoff). The scenarios for the
case you mentioned would be covered in the next version of the I-D (I hope).

Do you have any issues in mind for the case?

Cheers.

2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>

> Hi Jong-Hyouk,
>
>        Sorry for the delayed reply. I'll take a look at that draft and
> provide
> comments. Please, let me ask a short question (before I've read the
> draft): does the I-D look at any scenario involving an MN that changes
> its point of attachment between an MR (attached to a PMIPv6 domain) and
> a MAG?
>
>        Thanks,
>
>        Carlos
>
> El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
> > Hi, Carlos.
> >
> > Good to see your posts in this mailing. Anyway, the following document
> > has been expired would provide some scenarios for NEMO within PMIPv6
> > networks.
> >
> > http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01
> >
> > Have a good day!
> >
> >
> > 2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >         Hi Behcet,
> >
> >         I've quickly checked the document. I think it does address the
> >         same
> >         problem I was referring to. This draft addresses the problem
> >         of
> >         delegating a prefix to a router that attaches to a PMIPv6
> >         domain, so
> >         it can provide connectivity to nodes attached to it. I think
> >         this was
> >         already discussed in a past meeting (a draft with the problem
> >         statement) and I mentioned that IMHO this can basically be
> >         achieved by
> >         just using plain NEMO support on the router. The only
> >         difference in
> >         this draft is that it doesn't impose the router to be a NEMO
> >         RFC3963
> >         MR, although still it needs to do some additional things that
> >         a normal
> >         router (not mobile) doesn't. Anyway, I'm not against this type
> >         of
> >         support if there are scenarios in which it's useful.
> >
> >         However, the kind of NEMO+PMIPv6 support I'm considering goes
> >         a little
> >         bit beyond that, since what I want to enable is node to be
> >         able to
> >         benefit from network based localised mobility support not only
> >         when
> >         roaming between fixed points of attachment (this is what
> >         RFC5213 does
> >         today) but also when roaming between fixed and mobile points
> >         of
> >         attachment. What people do think about this scenario?
> >
> >         Thanks,
> >
> >         Carlos
> >
> >         2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >
> >         > Hi Carlos,
> >         >   Check this out:
> >         >
> >
> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
> >         >
> >         > Regards,
> >         >
> >         > Behcet
> >         >
> >         > ________________________________
> >         > From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >         > To: Jari Arkko <jari.arkko at piuha.net>
> >         > Cc: netext at mail.mobileip.jp
> >         > Sent: Tuesday, April 7, 2009 6:15:42 AM
> >         > Subject: Re: [Netext] next steps for netext
> >         >
> >         > Hi Jari, all,
> >         >
> >         > Regarding the NEMO topic, I don't know what Sri has in mind,
> >         but my
> >         > personal view on that is that it'd be nice to extend PMIPv6
> >         to support
> >         > mobile networks. What I mean here is that it'd be nice to
> >         enable MAGs
> >         > to also move (like MRs, but without even supporting
> >         RFC3963), so an MR
> >         > would be able to move between fixed and mobile MAGs without
> >         changing
> >         > its IP address (same support RFC5213 gives now). There are
> >         some
> >         > interesting scenarios that could benefit from this.
> >         >
> >         > What do others think? It is interesting to work on this?
> >         >
> >         > Thanks,
> >         >
> >         > Carlos
> >         >
> >         > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >         >> Sri,
> >         >>
> >         >> Thanks for your input. Inline:
> >         >>
> >         >>> I've a concern with the planned charter. The list is too
> >         random and
> >         >>> cherry picked and I dont believe proper input from all the
> >         folks went
> >         >>> into
> >         >>> this. There are many other items that are required for a
> >         reasonable
> >         >>> deployment of Proxy Mobile IPv6. Many items were proposed
> >         over the last 2
> >         >>> years, some of them that were left out in the base spec,
> >         some that we
> >         >>> realized as gaps when compared to other SDO protocols and
> >         some as
> >         >>> optimizations that we realized while implementing PMIP6,
> >         these items
> >         >>> should be in the initial scope.
> >         >>>
> >         >>> I understand the charter needs to be limited in scope, but
> >         just 3 or 4
> >         >>> random items, I'm not sure if this helps in short term
> >         PMIP6
> >         >>> requirements.
> >         >>> I've no issue with the currently listed items, but there
> >         are other items
> >         >>> that should get equal or higher priority.
> >         >>
> >         >> I have no problem with adding more. Even the charter says
> >         new things can
> >         >> be
> >         >> added.
> >         >>
> >         >> However, from a process perspective what I did was to take
> >         the proposal on
> >         >> the table, i.e., the full BOF scope and see what parts of
> >         that we already
> >         >> have an agreement on. I didn't include other things that
> >         were not
> >         >> discussed
> >         >> in the BOF. Maybe that would have been useful, but they
> >         were not on the
> >         >> table.
> >         >>
> >         >> We could add more items now, if there's general agreement
> >         that those
> >         >> things
> >         >> are useful. However, I do not want to declare an open
> >         season on doing
> >         >> everything. We pick a reasonable subset of all proposed
> >         work, based on
> >         >> priorities, community agreement that they are the right
> >         things to do,
> >         >> management reasons to ensure that we are not doing too
> >         much, etc.
> >         >>
> >         >>> For example, item #6, is absolutely required, from the
> >         perspective of
> >         >>> having a complete specification of 5213. There we allowed
> >         a mobile node
> >         >>> to
> >         >>> perform handoff betweek two interfaces. We defined all the
> >         hooks on the
> >         >>> network side, but we did not provide how a terminal vendor
> >         can support
> >         >>> that. A simple informational draft on how some one move
> >         prefixes between
> >         >>> interfaces will greatly help. Some guidance on how to
> >         create a virtual
> >         >>> interface and also some related notes for each platform
> >         (Linux, BSD,
> >         >>> Android ..etc). This should not fall in the controversial
> >         discussion
> >         >>> scope
> >         >>> of same address on two interfaces etc, thats a different
> >         problem, or
> >         >>> about
> >         >>> the issue of enhancing mobile node's capabilities. This is
> >         just
> >         >>> informational work, required to leverage what 5213 already
> >         supports.
> >         >>
> >         >> I suspect this is about the scoping of the handoff work.
> >         Lets try to
> >         >> figure
> >         >> out what makes sense (I personally believe the above item
> >         makes sense, for
> >         >> instance) and what doesn't.
> >         >>
> >         >> The fact that these parts were not in the charter was not a
> >         declaration
> >         >> that
> >         >> we're dismissing them. Its just that we didn't finish the
> >         discussion, but
> >         >> I
> >         >> still wanted to let the other things move forward.
> >         >>
> >         >>> Item #2, is required. The multimob BOF raised some issues,
> >         we need to
> >         >>> show how multicast services can be enabled in PMIP
> >         network. May be this
> >         >>> wont require extensions, a simple draft covering those
> >         aspects will help.
> >         >>
> >         >> As you may recall, in the Multimob BOF we did not have an
> >         agreement on
> >         >> what
> >         >> exactly is needed, if anything. My own conclusion is that
> >         we probably need
> >         >> at least an informational document that explains how to use
> >         RFC 5213 for
> >         >> multicast. I think we discussed the possibility of doing
> >         this as some kind
> >         >> of AD sponsored document or in one of the relevant WGs, as
> >         a joint work
> >         >> between PMIP and multicast experts.
> >         >>
> >         >> I'm on the fence about adding this work to the charter
> >         right now, mainly
> >         >> because the BOF back then was very inconclusive. I'd be
> >         happier if I saw
> >         >> an
> >         >> actual well written draft from say you and some of the
> >         multicast experts.
> >         >> There's no problem moving good documents forward, even if
> >         they are not in
> >         >> the charter of some WG. Then again, I wouldn't necessarily
> >         mind a
> >         >> maintenance like item for this in one of the WG charters
> >         either.
> >         >>
> >         >>> I think, the charter should be bit more relaxed and more
> >         extensive. As I
> >         >>> see it, atleast the folks are interested in doing the
> >         work. We should add
> >         >>> atleast 4 or 5 more items to this list.
> >         >>
> >         >> Generally speaking IETF WG charters give specific work
> >         items that the WG
> >         >> should work on. I had hoped that the charter text:
> >         >>
> >         >> "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."
> >         >>
> >         >> gives an indication that we intend to do more! I am also
> >         personally very
> >         >> happy to add more items to the group's charter. All in all,
> >         I do know that
> >         >> the current charter is a bit on the thin side -- mostly
> >         because the
> >         >> multihoming/interaccess issue is under discussion.
> >         >>
> >         >> There's also the question of general maintenance items.
> >         Some IETF WGs have
> >         >> a
> >         >> general work item to fix problems and issue updates to
> >         existing
> >         >> specifications. I think we need to do that for Proxy Mobile
> >         IPv6 as well.
> >         >> But we have not decided whether that item should go to
> >         NETLMM or NETEXT WG
> >         >> yet. Please rest assured that the work will be possible
> >         regardless of
> >         >> this.
> >         >>
> >         >>> 1. Dynamic LMA Assignment
> >         >>>
> >         >>> In blade architecture systems or in a load balancer
> >         configuration, the
> >         >>> PDNGW
> >         >>> should have the ability to dynamically assign a LMA on the
> >         fly, along the
> >         >>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment
> >         support
> >         >>> [RFC-4433].
> >         >>> Currently, GTP provides such semantics and this is a
> >         important
> >         >>> requirement
> >         >>> for deployment. Here the goal is to
> >         >>>
> >         >>> a.) Expose a single IP address to the SGW
> >         >>> b.) The exposed IP address should not be in path once the
> >         assignment is
> >         >>> done.
> >         >>>
> >         >>>
> >         >>>
> >         >>> [LMA1]---
> >         >>> | |
> >         >>> [LMA2]--[LMA]==========[MAG]
> >         >>> | |
> >         >>> [LMA3]---
> >         >>>
> >         >>>
> >         >>> Along the lines of:
> >         >>>
> >         >>>
> >         http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >         >>
> >         >> This is in the proposed NETEXT charter already.
> >         >>
> >         >>> 2. Multicast Support in Proxy Mobile IPv6
> >         >>>
> >         >>> We need an informational specification on how multicast
> >         support can be
> >         >>> enabled in Proxy Mobile IPv6 environment. Behcet has done
> >         extensive
> >         >>> analysis
> >         >>> on
> >         >>> this. This is required and critical for enabling any
> >         multicast services.
> >         >>> However,
> >         >>> Behcet may disagree with the scope of the work.
> >         >>
> >         >> See above.
> >         >>
> >         >>> 3. Bulk Registration Support
> >         >>>
> >         >>> This is a simple extension which helps in signaling
> >         optimization, along
> >         >>> the
> >         >>> lines of:
> >         >>>
> >         >>>
> >
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >         >>
> >         >> This is in the charter as well.
> >         >>
> >         >>> 4. Partial Failover Support
> >         >>>
> >         >>> We need a mechanism to notify the peer on revoke a partial
> >         set of
> >         >>> bindings.
> >         >>>
> >         >>>
> >         >>>
> >         >>>
> >
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> .
> >         >>> txt
> >         >>
> >         >> Hmm. Ok. This needs more discussion.
> >         >>
> >         >>> 5. Group Identifier Support for Proxy Mobile IPv6
> >         >>>
> >         >>> This provides a simple and a generic semantic for
> >         assigning a group
> >         >>> identifier
> >         >>> to a mobile node's binding. GTP has very similar
> >         semantics, Connexion Set
> >         >>> Id.
> >         >>> Both #3 and #4 can leverage this. Additionally, in load
> >         balancer systems
> >         >>> where
> >         >>> the load balancer is in path for all signaling messages,
> >         it can use this
> >         >>> as
> >         >>> a
> >         >>> tag for redirecting the message.
> >         >>>
> >         >>>
> >
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >         >>
> >         >> Since the bulk registration work is in the charter, can't
> >         you do the
> >         >> sensible design (whatever it is) under that? There is no
> >         requirement that
> >         >> one charter item equals one document.
> >         >>
> >         >>> 6. Virtual-Interface Support on IP host for supporting
> >         Inter-tech
> >         >>> handoffs:
> >         >>>
> >         >>>
> >         >>> RFC-5213 supports handoff between two interfaces. The
> >         ability to move
> >         >>> prefixes between interfaces. In other words address
> >         continuity is assured
> >         >>> with any IPv6 host on the planet and with absolutely no
> >         changes. This
> >         >>> meets
> >         >>> even Dave's comment, that "no changes to any IETF RFC's.".
> >         Now, what is
> >         >>> not assured is the aspect of session continuity. Which
> >         requires a virtual
> >         >>> interface implementation on the host, by binding the
> >         address/prefix to a
> >         >>> virtual interface and by not exposing the physical
> >         interface or by hiding
> >         >>> the handoff events from the layer-3 stack.
> >         >>>
> >         >>> In essence, we need an informational specification which
> >         provides some
> >         >>> general guidance to how to leverage the feature support
> >         provided in
> >         >>> RFC-5213,
> >         >>> along the lines of:
> >         >>>
> >         >>>
> >
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >         >>
> >         >> This is part of the discussion that we need to finish. But
> >         I plan to let
> >         >> the
> >         >> rest of the stuff move forward even before we have done
> >         that.
> >         >>
> >         >>
> >         >>> 7. Route Optimization for Proxy Mobile IPv6
> >         >>>
> >         >>> There were atleast 4 drafts in this area on Route
> >         Optimization. Marco
> >         >>> Liebsch
> >         >>> analyzed this exensively:
> >         >>>
> >         >>>
> >         >>>
> >         http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >         >>>
> >         >>>
> >         >>>
> >
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> .
> >         >>> txt
> >         >>
> >         >> This is in the charter.
> >         >>
> >         >>> 8. Prefix Management in Proxy Mobile IPv6 support
> >         >>>
> >         >>> Proxy Mobile IPv6 allows the assignment of multiple home
> >         network prefixes
> >         >>> to a given mobile node's interface. It might be useful to
> >         specify how the
> >         >>> LMA manages this aspects. It can potentially use DHCP PD,
> >         Local Pools or
> >         >>> AAA to manage this aspect. Behcet has one draft on this.
> >         >>
> >         >> I'm not personally sold on this particular work. But again,
> >         this could be
> >         >> something to consider.
> >         >>
> >         >>> 9. Partial Handoff Support
> >         >>>
> >         >>> We are missing some semantics in 5213 for moving a subset
> >         of the prefixes
> >         >>> between interfaces as part of the inter-tech handoff. This
> >         is about
> >         >>> defining
> >         >>> a new handoff value. This allows partial flow management,
> >         but moving the
> >         >>> flows associated to a prefix, as a whole group.
> >         >>>
> >         >>>
> >         >>>
> >
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >         >>
> >         >> A part of the topic we still need to discuss...
> >         >>
> >         >>> 10. CMIPv4/PMIP Interworking
> >         >>>
> >         >>> This is probably required to specify how an IPv4-only can
> >         move between
> >         >>> CMIP and PMIP environments.
> >         >>>
> >         >>>
> >         >>>
> >         >>>
> >
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >         >>> meghana-netlmm-pmipv6-mipv4-00.txt
> >         >>
> >         >> Client MIPv6 and Proxy MIPv6 interoperability is already in
> >         the NETLMM
> >         >> charter, but this work is presumably about interaction with
> >         MIPv4. Might
> >         >> be
> >         >> useful work, I wouldn't mind if this was done in NETEXT at
> >         some point. Is
> >         >> this crucial to be in the first revision of the WG's
> >         charter?
> >         >>
> >         >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile
> >         IPv6
> >         >>
> >         >> Can you expand on this?
> >         >>
> >         >> Jari
> >         >>
> >         >> _______________________________________________
> >         >> 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
> >         >
> >         >
> >
> >         _______________________________________________
> >         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/
> --
>   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
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>

-- 
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/20090416/097efffb/attachment-0001.html>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 16 Apr 2009 01:43:26 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <1239839006.4695.116.camel@localhost>

Hi Ryuji,

	Sorry for the delayed reply. Comments below.

El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
> Hello Carlos,
> 
> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
> 
> > Hi Behcet,
> >
> > I've quickly checked the document. I think it does address the same
> > problem I was referring to. This draft addresses the problem of
> > delegating a prefix to a router that attaches to a PMIPv6 domain, so
> > it can provide connectivity to nodes attached to it. I think this was
> > already discussed in a past meeting (a draft with the problem
> > statement) and I mentioned that IMHO this can basically be achieved by
> > just using plain NEMO support on the router. The only difference in
> > this draft is that it doesn't impose the router to be a NEMO RFC3963
> > MR, although still it needs to do some additional things that a normal
> > router (not mobile) doesn't. Anyway, I'm not against this type of
> > support if there are scenarios in which it's useful.
> 
> In the doc, we just specify how to get mobile network prefix from DHCP- 
> DR.
> DHCP-PD is that normal router does, right?

Yes, my point was more related with the benefits of doing this instead
of just using NEMO.

> 
> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> > bit beyond that, since what I want to enable is node to be able to
> > benefit from network based localised mobility support not only when
> > roaming between fixed points of attachment (this is what RFC5213 does
> > today) but also when roaming between fixed and mobile points of
> > attachment. What people do think about this scenario?
> 
> I don't know what is fixed and mobile points of attachment. You can  
> clarify these.
> 

I've sent another e-mail regarding this (hope there is more clear).
Summarising, what I call a fixed point of attachment is a MAG as it is
defined in RFC5213 that does not move. I call a mobile point of
attachment a MAG that would also be able to move (like an MR) within the
PMIPv6 domain.

Thanks,

Carlos

> ryuji
> 
> >
> >
> > Thanks,
> >
> > Carlos
> >
> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >> Hi Carlos,
> >>   Check this out:
> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo- 
> >> support-00
> >>
> >> Regards,
> >>
> >> Behcet
> >>
> >> ________________________________
> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >> To: Jari Arkko <jari.arkko at piuha.net>
> >> Cc: netext at mail.mobileip.jp
> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
> >> Subject: Re: [Netext] next steps for netext
> >>
> >> Hi Jari, all,
> >>
> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> >> personal view on that is that it'd be nice to extend PMIPv6 to  
> >> support
> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
> >> to also move (like MRs, but without even supporting RFC3963), so an  
> >> MR
> >> would be able to move between fixed and mobile MAGs without changing
> >> its IP address (same support RFC5213 gives now). There are some
> >> interesting scenarios that could benefit from this.
> >>
> >> What do others think? It is interesting to work on this?
> >>
> >> Thanks,
> >>
> >> Carlos
> >>
> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >>> Sri,
> >>>
> >>> Thanks for your input. Inline:
> >>>
> >>>> I've a concern with the planned charter. The list is too random and
> >>>> cherry picked and I dont believe proper input from all the folks  
> >>>> went
> >>>> into
> >>>> this. There are many other items that are required for a reasonable
> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over  
> >>>> the last 2
> >>>> years, some of them that were left out in the base spec, some  
> >>>> that we
> >>>> realized as gaps when compared to other SDO protocols and some as
> >>>> optimizations that we realized while implementing PMIP6, these  
> >>>> items
> >>>> should be in the initial scope.
> >>>>
> >>>> I understand the charter needs to be limited in scope, but just 3  
> >>>> or 4
> >>>> random items, I'm not sure if this helps in short term PMIP6
> >>>> requirements.
> >>>> I've no issue with the currently listed items, but there are  
> >>>> other items
> >>>> that should get equal or higher priority.
> >>>
> >>> I have no problem with adding more. Even the charter says new  
> >>> things can
> >>> be
> >>> added.
> >>>
> >>> However, from a process perspective what I did was to take the  
> >>> proposal on
> >>> the table, i.e., the full BOF scope and see what parts of that we  
> >>> already
> >>> have an agreement on. I didn't include other things that were not
> >>> discussed
> >>> in the BOF. Maybe that would have been useful, but they were not  
> >>> on the
> >>> table.
> >>>
> >>> We could add more items now, if there's general agreement that those
> >>> things
> >>> are useful. However, I do not want to declare an open season on  
> >>> doing
> >>> everything. We pick a reasonable subset of all proposed work,  
> >>> based on
> >>> priorities, community agreement that they are the right things to  
> >>> do,
> >>> management reasons to ensure that we are not doing too much, etc.
> >>>
> >>>> For example, item #6, is absolutely required, from the  
> >>>> perspective of
> >>>> having a complete specification of 5213. There we allowed a  
> >>>> mobile node
> >>>> to
> >>>> perform handoff betweek two interfaces. We defined all the hooks  
> >>>> on the
> >>>> network side, but we did not provide how a terminal vendor can  
> >>>> support
> >>>> that. A simple informational draft on how some one move prefixes  
> >>>> between
> >>>> interfaces will greatly help. Some guidance on how to create a  
> >>>> virtual
> >>>> interface and also some related notes for each platform (Linux,  
> >>>> BSD,
> >>>> Android ..etc). This should not fall in the controversial  
> >>>> discussion
> >>>> scope
> >>>> of same address on two interfaces etc, thats a different problem,  
> >>>> or
> >>>> about
> >>>> the issue of enhancing mobile node's capabilities. This is just
> >>>> informational work, required to leverage what 5213 already  
> >>>> supports.
> >>>
> >>> I suspect this is about the scoping of the handoff work. Lets try to
> >>> figure
> >>> out what makes sense (I personally believe the above item makes  
> >>> sense, for
> >>> instance) and what doesn't.
> >>>
> >>> The fact that these parts were not in the charter was not a  
> >>> declaration
> >>> that
> >>> we're dismissing them. Its just that we didn't finish the  
> >>> discussion, but
> >>> I
> >>> still wanted to let the other things move forward.
> >>>
> >>>> Item #2, is required. The multimob BOF raised some issues, we  
> >>>> need to
> >>>> show how multicast services can be enabled in PMIP network. May  
> >>>> be this
> >>>> wont require extensions, a simple draft covering those aspects  
> >>>> will help.
> >>>
> >>> As you may recall, in the Multimob BOF we did not have an  
> >>> agreement on
> >>> what
> >>> exactly is needed, if anything. My own conclusion is that we  
> >>> probably need
> >>> at least an informational document that explains how to use RFC  
> >>> 5213 for
> >>> multicast. I think we discussed the possibility of doing this as  
> >>> some kind
> >>> of AD sponsored document or in one of the relevant WGs, as a joint  
> >>> work
> >>> between PMIP and multicast experts.
> >>>
> >>> I'm on the fence about adding this work to the charter right now,  
> >>> mainly
> >>> because the BOF back then was very inconclusive. I'd be happier if  
> >>> I saw
> >>> an
> >>> actual well written draft from say you and some of the multicast  
> >>> experts.
> >>> There's no problem moving good documents forward, even if they are  
> >>> not in
> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
> >>> maintenance like item for this in one of the WG charters either.
> >>>
> >>>> I think, the charter should be bit more relaxed and more  
> >>>> extensive. As I
> >>>> see it, atleast the folks are interested in doing the work. We  
> >>>> should add
> >>>> atleast 4 or 5 more items to this list.
> >>>
> >>> Generally speaking IETF WG charters give specific work items that  
> >>> the WG
> >>> should work on. I had hoped that the charter text:
> >>>
> >>> "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."
> >>>
> >>> gives an indication that we intend to do more! I am also  
> >>> personally very
> >>> happy to add more items to the group's charter. All in all, I do  
> >>> know that
> >>> the current charter is a bit on the thin side -- mostly because the
> >>> multihoming/interaccess issue is under discussion.
> >>>
> >>> There's also the question of general maintenance items. Some IETF  
> >>> WGs have
> >>> a
> >>> general work item to fix problems and issue updates to existing
> >>> specifications. I think we need to do that for Proxy Mobile IPv6  
> >>> as well.
> >>> But we have not decided whether that item should go to NETLMM or  
> >>> NETEXT WG
> >>> yet. Please rest assured that the work will be possible regardless  
> >>> of
> >>> this.
> >>>
> >>>> 1. Dynamic LMA Assignment
> >>>>
> >>>> In blade architecture systems or in a load balancer  
> >>>> configuration, the
> >>>> PDNGW
> >>>> should have the ability to dynamically assign a LMA on the fly,  
> >>>> along the
> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >>>> [RFC-4433].
> >>>> Currently, GTP provides such semantics and this is a important
> >>>> requirement
> >>>> for deployment. Here the goal is to
> >>>>
> >>>> a.) Expose a single IP address to the SGW
> >>>> b.) The exposed IP address should not be in path once the  
> >>>> assignment is
> >>>> done.
> >>>>
> >>>>
> >>>>
> >>>> [LMA1]---
> >>>> | |
> >>>> [LMA2]--[LMA]==========[MAG]
> >>>> | |
> >>>> [LMA3]---
> >>>>
> >>>>
> >>>> Along the lines of:
> >>>>
> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >>>
> >>> This is in the proposed NETEXT charter already.
> >>>
> >>>> 2. Multicast Support in Proxy Mobile IPv6
> >>>>
> >>>> We need an informational specification on how multicast support  
> >>>> can be
> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >>>> analysis
> >>>> on
> >>>> this. This is required and critical for enabling any multicast  
> >>>> services.
> >>>> However,
> >>>> Behcet may disagree with the scope of the work.
> >>>
> >>> See above.
> >>>
> >>>> 3. Bulk Registration Support
> >>>>
> >>>> This is a simple extension which helps in signaling optimization,  
> >>>> along
> >>>> the
> >>>> lines of:
> >>>>
> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >>>
> >>> This is in the charter as well.
> >>>
> >>>> 4. Partial Failover Support
> >>>>
> >>>> We need a mechanism to notify the peer on revoke a partial set of
> >>>> bindings.
> >>>>
> >>>>
> >>>>
> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00 
> >>>> .
> >>>> txt
> >>>
> >>> Hmm. Ok. This needs more discussion.
> >>>
> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
> >>>>
> >>>> This provides a simple and a generic semantic for assigning a group
> >>>> identifier
> >>>> to a mobile node's binding. GTP has very similar semantics,  
> >>>> Connexion Set
> >>>> Id.
> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer  
> >>>> systems
> >>>> where
> >>>> the load balancer is in path for all signaling messages, it can  
> >>>> use this
> >>>> as
> >>>> a
> >>>> tag for redirecting the message.
> >>>>
> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >>>
> >>> Since the bulk registration work is in the charter, can't you do the
> >>> sensible design (whatever it is) under that? There is no  
> >>> requirement that
> >>> one charter item equals one document.
> >>>
> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >>>> handoffs:
> >>>>
> >>>>
> >>>> RFC-5213 supports handoff between two interfaces. The ability to  
> >>>> move
> >>>> prefixes between interfaces. In other words address continuity is  
> >>>> assured
> >>>> with any IPv6 host on the planet and with absolutely no changes.  
> >>>> This
> >>>> meets
> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,  
> >>>> what is
> >>>> not assured is the aspect of session continuity. Which requires a  
> >>>> virtual
> >>>> interface implementation on the host, by binding the address/ 
> >>>> prefix to a
> >>>> virtual interface and by not exposing the physical interface or  
> >>>> by hiding
> >>>> the handoff events from the layer-3 stack.
> >>>>
> >>>> In essence, we need an informational specification which provides  
> >>>> some
> >>>> general guidance to how to leverage the feature support provided in
> >>>> RFC-5213,
> >>>> along the lines of:
> >>>>
> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >>>
> >>> This is part of the discussion that we need to finish. But I plan  
> >>> to let
> >>> the
> >>> rest of the stuff move forward even before we have done that.
> >>>
> >>>
> >>>> 7. Route Optimization for Proxy Mobile IPv6
> >>>>
> >>>> There were atleast 4 drafts in this area on Route Optimization.  
> >>>> Marco
> >>>> Liebsch
> >>>> analyzed this exensively:
> >>>>
> >>>>
> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >>>>
> >>>>
> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00 
> >>>> .
> >>>> txt
> >>>
> >>> This is in the charter.
> >>>
> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
> >>>>
> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network  
> >>>> prefixes
> >>>> to a given mobile node's interface. It might be useful to specify  
> >>>> how the
> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local  
> >>>> Pools or
> >>>> AAA to manage this aspect. Behcet has one draft on this.
> >>>
> >>> I'm not personally sold on this particular work. But again, this  
> >>> could be
> >>> something to consider.
> >>>
> >>>> 9. Partial Handoff Support
> >>>>
> >>>> We are missing some semantics in 5213 for moving a subset of the  
> >>>> prefixes
> >>>> between interfaces as part of the inter-tech handoff. This is about
> >>>> defining
> >>>> a new handoff value. This allows partial flow management, but  
> >>>> moving the
> >>>> flows associated to a prefix, as a whole group.
> >>>>
> >>>>
> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >>>
> >>> A part of the topic we still need to discuss...
> >>>
> >>>> 10. CMIPv4/PMIP Interworking
> >>>>
> >>>> This is probably required to specify how an IPv4-only can move  
> >>>> between
> >>>> CMIP and PMIP environments.
> >>>>
> >>>>
> >>>>
> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
> >>>
> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the  
> >>> NETLMM
> >>> charter, but this work is presumably about interaction with MIPv4.  
> >>> Might
> >>> be
> >>> useful work, I wouldn't mind if this was done in NETEXT at some  
> >>> point. Is
> >>> this crucial to be in the first revision of the WG's charter?
> >>>
> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >>>
> >>> Can you expand on this?
> >>>
> >>> Jari
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >>
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
-- 
   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/20090416/0424cd94/attachment.bin>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 16 Apr 2009 01:43:19 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <1239838999.4695.115.camel@localhost>

Hi Ryuji,

	Sorry for the delayerd reply. Comments below...

El mi?, 08-04-2009 a las 18:01 -0400, Ryuji Wakikawa escribi?:
> Hello Carlos,
> 
> On 2009/04/07, at 7:15, Carlos Jes?s Bernardos Cano wrote:
> 
> > Hi Jari, all,
> >
> > Regarding the NEMO topic, I don't know what Sri has in mind, but my
> > personal view on that is that it'd be nice to extend PMIPv6 to support
> > mobile networks. What I mean here is that it'd be nice to enable MAGs
> > to also move (like MRs, but without even supporting RFC3963), so an MR
> > would be able to move between fixed and mobile MAGs without changing
> > its IP address (same support RFC5213 gives now). There are some
> > interesting scenarios that could benefit from this.
> 
> It sounds interesting, but what is the benefit of this?

First a correction, where I wrote above "so an MR would be able" it
should say "son an MN would be able". This is clearly misleading, sorry
for that.

Once I clariffied this, I clearly see a benefit in extending the PMIPv6
support so MAGs can also be mobile, while not breaking anything from the
point of view of an MN roaming between fixed ("classical") MAGs and
mobile MAGs.

> For supporting NEMO, which prefix will you assign to hosts under the  
> MR (MAG)?

I think that in order to support mobility between fixed and mobile MAGs,
the prefix assigned to hosts under the mobile MAG should be assigned by
the LMA. Otherwise there is no way of ensuring that the MN would
preserve its IPv6 address when moving from the mobile MAG to a fixed
one, right?

> The prefix is not assigned to MAG, but to a mobile host in RFC5213.
> 
> ryuji
> 
> 
> >
> >
> > What do others think? It is interesting to work on this?
> >
> > Thanks,
> >
> > Carlos
> >
> > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> Sri,
> >>
> >> Thanks for your input. Inline:
> >>
> >>> I've a concern with the planned charter. The list is too random and
> >>> cherry picked and I dont believe proper input from all the folks  
> >>> went into
> >>> this. There are many other items that are required for a reasonable
> >>> deployment of Proxy Mobile IPv6. Many items were proposed over the  
> >>> last 2
> >>> years, some of them that were left out in the base spec, some that  
> >>> we
> >>> realized as gaps when compared to other SDO protocols and some as
> >>> optimizations that we realized while implementing PMIP6, these items
> >>> should be in the initial scope.
> >>>
> >>> I understand the charter needs to be limited in scope, but just 3  
> >>> or 4
> >>> random items, I'm not sure if this helps in short term PMIP6  
> >>> requirements.
> >>> I've no issue with the currently listed items, but there are other  
> >>> items
> >>> that should get equal or higher priority.
> >>
> >> I have no problem with adding more. Even the charter says new  
> >> things can be
> >> added.
> >>
> >> However, from a process perspective what I did was to take the  
> >> proposal on
> >> the table, i.e., the full BOF scope and see what parts of that we  
> >> already
> >> have an agreement on. I didn't include other things that were not  
> >> discussed
> >> in the BOF. Maybe that would have been useful, but they were not on  
> >> the
> >> table.
> >>
> >> We could add more items now, if there's general agreement that  
> >> those things
> >> are useful. However, I do not want to declare an open season on doing
> >> everything. We pick a reasonable subset of all proposed work, based  
> >> on
> >> priorities, community agreement that they are the right things to do,
> >> management reasons to ensure that we are not doing too much, etc.
> >>
> >>> For example, item #6, is absolutely required, from the perspective  
> >>> of
> >>> having a complete specification of 5213. There we allowed a mobile  
> >>> node to
> >>> perform handoff betweek two interfaces. We defined all the hooks  
> >>> on the
> >>> network side, but we did not provide how a terminal vendor can  
> >>> support
> >>> that. A simple informational draft on how some one move prefixes  
> >>> between
> >>> interfaces will greatly help. Some guidance on how to create a  
> >>> virtual
> >>> interface and also some related notes for each platform (Linux, BSD,
> >>> Android ..etc). This should not fall in the controversial  
> >>> discussion scope
> >>> of same address on two interfaces etc, thats a different problem,  
> >>> or about
> >>> the issue of enhancing mobile node's capabilities. This is just
> >>> informational work, required to leverage what 5213 already supports.
> >>
> >> I suspect this is about the scoping of the handoff work. Lets try  
> >> to figure
> >> out what makes sense (I personally believe the above item makes  
> >> sense, for
> >> instance) and what doesn't.
> >>
> >> The fact that these parts were not in the charter was not a  
> >> declaration that
> >> we're dismissing them. Its just that we didn't finish the  
> >> discussion, but I
> >> still wanted to let the other things move forward.
> >>
> >>> Item #2, is required. The multimob BOF raised some issues, we need  
> >>> to
> >>> show how multicast services can be enabled in PMIP network. May be  
> >>> this
> >>> wont require extensions, a simple draft covering those aspects  
> >>> will help.
> >>
> >> As you may recall, in the Multimob BOF we did not have an agreement  
> >> on what
> >> exactly is needed, if anything. My own conclusion is that we  
> >> probably need
> >> at least an informational document that explains how to use RFC  
> >> 5213 for
> >> multicast. I think we discussed the possibility of doing this as  
> >> some kind
> >> of AD sponsored document or in one of the relevant WGs, as a joint  
> >> work
> >> between PMIP and multicast experts.
> >>
> >> I'm on the fence about adding this work to the charter right now,  
> >> mainly
> >> because the BOF back then was very inconclusive. I'd be happier if  
> >> I saw an
> >> actual well written draft from say you and some of the multicast  
> >> experts.
> >> There's no problem moving good documents forward, even if they are  
> >> not in
> >> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> maintenance like item for this in one of the WG charters either.
> >>
> >>> I think, the charter should be bit more relaxed and more  
> >>> extensive. As I
> >>> see it, atleast the folks are interested in doing the work. We  
> >>> should add
> >>> atleast 4 or 5 more items to this list.
> >>
> >> Generally speaking IETF WG charters give specific work items that  
> >> the WG
> >> should work on. I had hoped that the charter text:
> >>
> >> "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."
> >>
> >> gives an indication that we intend to do more! I am also personally  
> >> very
> >> happy to add more items to the group's charter. All in all, I do  
> >> know that
> >> the current charter is a bit on the thin side -- mostly because the
> >> multihoming/interaccess issue is under discussion.
> >>
> >> There's also the question of general maintenance items. Some IETF  
> >> WGs have a
> >> general work item to fix problems and issue updates to existing
> >> specifications. I think we need to do that for Proxy Mobile IPv6 as  
> >> well.
> >> But we have not decided whether that item should go to NETLMM or  
> >> NETEXT WG
> >> yet. Please rest assured that the work will be possible regardless  
> >> of this.
> >>
> >>> 1. Dynamic LMA Assignment
> >>>
> >>> In blade architecture systems or in a load balancer configuration,  
> >>> the
> >>> PDNGW
> >>> should have the ability to dynamically assign a LMA on the fly,  
> >>> along the
> >>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >>> [RFC-4433].
> >>> Currently, GTP provides such semantics and this is a important  
> >>> requirement
> >>> for deployment. Here the goal is to
> >>>
> >>> a.) Expose a single IP address to the SGW
> >>> b.) The exposed IP address should not be in path once the  
> >>> assignment is
> >>> done.
> >>>
> >>>
> >>>
> >>> [LMA1]---
> >>> | |
> >>> [LMA2]--[LMA]==========[MAG]
> >>> | |
> >>> [LMA3]---
> >>>
> >>>
> >>> Along the lines of:
> >>>
> >>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >>
> >> This is in the proposed NETEXT charter already.
> >>
> >>> 2. Multicast Support in Proxy Mobile IPv6
> >>>
> >>> We need an informational specification on how multicast support  
> >>> can be
> >>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >>> analysis
> >>> on
> >>> this. This is required and critical for enabling any multicast  
> >>> services.
> >>> However,
> >>> Behcet may disagree with the scope of the work.
> >>
> >> See above.
> >>
> >>> 3. Bulk Registration Support
> >>>
> >>> This is a simple extension which helps in signaling optimization,  
> >>> along
> >>> the
> >>> lines of:
> >>>
> >>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >>
> >> This is in the charter as well.
> >>
> >>> 4. Partial Failover Support
> >>>
> >>> We need a mechanism to notify the peer on revoke a partial set of
> >>> bindings.
> >>>
> >>>
> >>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00 
> >>> .
> >>> txt
> >>
> >> Hmm. Ok. This needs more discussion.
> >>
> >>> 5. Group Identifier Support for Proxy Mobile IPv6
> >>>
> >>> This provides a simple and a generic semantic for assigning a group
> >>> identifier
> >>> to a mobile node's binding. GTP has very similar semantics,  
> >>> Connexion Set
> >>> Id.
> >>> Both #3 and #4 can leverage this. Additionally, in load balancer  
> >>> systems
> >>> where
> >>> the load balancer is in path for all signaling messages, it can  
> >>> use this
> >>> as
> >>> a
> >>> tag for redirecting the message.
> >>>
> >>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >>
> >> Since the bulk registration work is in the charter, can't you do the
> >> sensible design (whatever it is) under that? There is no  
> >> requirement that
> >> one charter item equals one document.
> >>
> >>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >>> handoffs:
> >>>
> >>>
> >>> RFC-5213 supports handoff between two interfaces. The ability to  
> >>> move
> >>> prefixes between interfaces. In other words address continuity is  
> >>> assured
> >>> with any IPv6 host on the planet and with absolutely no changes.  
> >>> This
> >>> meets
> >>> even Dave's comment, that "no changes to any IETF RFC's.". Now,  
> >>> what is
> >>> not assured is the aspect of session continuity. Which requires a  
> >>> virtual
> >>> interface implementation on the host, by binding the address/ 
> >>> prefix to a
> >>> virtual interface and by not exposing the physical interface or by  
> >>> hiding
> >>> the handoff events from the layer-3 stack.
> >>>
> >>> In essence, we need an informational specification which provides  
> >>> some
> >>> general guidance to how to leverage the feature support provided in
> >>> RFC-5213,
> >>> along the lines of:
> >>>
> >>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >>
> >> This is part of the discussion that we need to finish. But I plan  
> >> to let the
> >> rest of the stuff move forward even before we have done that.
> >>
> >>
> >>> 7. Route Optimization for Proxy Mobile IPv6
> >>>
> >>> There were atleast 4 drafts in this area on Route Optimization.  
> >>> Marco
> >>> Liebsch
> >>> analyzed this exensively:
> >>>
> >>>
> >>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >>>
> >>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00 
> >>> .
> >>> txt
> >>
> >> This is in the charter.
> >>
> >>> 8. Prefix Management in Proxy Mobile IPv6 support
> >>>
> >>> Proxy Mobile IPv6 allows the assignment of multiple home network  
> >>> prefixes
> >>> to a given mobile node's interface. It might be useful to specify  
> >>> how the
> >>> LMA manages this aspects. It can potentially use DHCP PD, Local  
> >>> Pools or
> >>> AAA to manage this aspect. Behcet has one draft on this.
> >>
> >> I'm not personally sold on this particular work. But again, this  
> >> could be
> >> something to consider.
> >>
> >>> 9. Partial Handoff Support
> >>>
> >>> We are missing some semantics in 5213 for moving a subset of the  
> >>> prefixes
> >>> between interfaces as part of the inter-tech handoff. This is about
> >>> defining
> >>> a new handoff value. This allows partial flow management, but  
> >>> moving the
> >>> flows associated to a prefix, as a whole group.
> >>>
> >>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >>
> >> A part of the topic we still need to discuss...
> >>
> >>> 10. CMIPv4/PMIP Interworking
> >>>
> >>> This is probably required to specify how an IPv4-only can move  
> >>> between
> >>> CMIP and PMIP environments.
> >>>
> >>>
> >>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >>> meghana-netlmm-pmipv6-mipv4-00.txt
> >>
> >> Client MIPv6 and Proxy MIPv6 interoperability is already in the  
> >> NETLMM
> >> charter, but this work is presumably about interaction with MIPv4.  
> >> Might be
> >> useful work, I wouldn't mind if this was done in NETEXT at some  
> >> point. Is
> >> this crucial to be in the first revision of the WG's charter?
> >>
> >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >>
> >> Can you expand on this?
> >>
> >> Jari
> >>
> >> _______________________________________________
> >> 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
> 
-- 
   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/20090416/43fccfa4/attachment-0001.bin>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 16 Apr 2009 01:43:05 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <1239838985.4695.114.camel@localhost>

Hi Jong-Hyouk,

	Sorry for the delayed reply. I'll take a look at that draft and provide
comments. Please, let me ask a short question (before I've read the
draft): does the I-D look at any scenario involving an MN that changes
its point of attachment between an MR (attached to a PMIPv6 domain) and
a MAG?

	Thanks,

	Carlos

El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
> Hi, Carlos. 
>  
> Good to see your posts in this mailing. Anyway, the following document
> has been expired would provide some scenarios for NEMO within PMIPv6
> networks.
>  
> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01
>  
> Have a good day!
> 
> 
> 2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>         Hi Behcet,
>         
>         I've quickly checked the document. I think it does address the
>         same
>         problem I was referring to. This draft addresses the problem
>         of
>         delegating a prefix to a router that attaches to a PMIPv6
>         domain, so
>         it can provide connectivity to nodes attached to it. I think
>         this was
>         already discussed in a past meeting (a draft with the problem
>         statement) and I mentioned that IMHO this can basically be
>         achieved by
>         just using plain NEMO support on the router. The only
>         difference in
>         this draft is that it doesn't impose the router to be a NEMO
>         RFC3963
>         MR, although still it needs to do some additional things that
>         a normal
>         router (not mobile) doesn't. Anyway, I'm not against this type
>         of
>         support if there are scenarios in which it's useful.
>         
>         However, the kind of NEMO+PMIPv6 support I'm considering goes
>         a little
>         bit beyond that, since what I want to enable is node to be
>         able to
>         benefit from network based localised mobility support not only
>         when
>         roaming between fixed points of attachment (this is what
>         RFC5213 does
>         today) but also when roaming between fixed and mobile points
>         of
>         attachment. What people do think about this scenario?
>         
>         Thanks,
>         
>         Carlos
>         
>         2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>         
>         > Hi Carlos,
>         >   Check this out:
>         >
>         http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
>         >
>         > Regards,
>         >
>         > Behcet
>         >
>         > ________________________________
>         > From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>         > To: Jari Arkko <jari.arkko at piuha.net>
>         > Cc: netext at mail.mobileip.jp
>         > Sent: Tuesday, April 7, 2009 6:15:42 AM
>         > Subject: Re: [Netext] next steps for netext
>         >
>         > Hi Jari, all,
>         >
>         > Regarding the NEMO topic, I don't know what Sri has in mind,
>         but my
>         > personal view on that is that it'd be nice to extend PMIPv6
>         to support
>         > mobile networks. What I mean here is that it'd be nice to
>         enable MAGs
>         > to also move (like MRs, but without even supporting
>         RFC3963), so an MR
>         > would be able to move between fixed and mobile MAGs without
>         changing
>         > its IP address (same support RFC5213 gives now). There are
>         some
>         > interesting scenarios that could benefit from this.
>         >
>         > What do others think? It is interesting to work on this?
>         >
>         > Thanks,
>         >
>         > Carlos
>         >
>         > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>         >> Sri,
>         >>
>         >> Thanks for your input. Inline:
>         >>
>         >>> I've a concern with the planned charter. The list is too
>         random and
>         >>> cherry picked and I dont believe proper input from all the
>         folks went
>         >>> into
>         >>> this. There are many other items that are required for a
>         reasonable
>         >>> deployment of Proxy Mobile IPv6. Many items were proposed
>         over the last 2
>         >>> years, some of them that were left out in the base spec,
>         some that we
>         >>> realized as gaps when compared to other SDO protocols and
>         some as
>         >>> optimizations that we realized while implementing PMIP6,
>         these items
>         >>> should be in the initial scope.
>         >>>
>         >>> I understand the charter needs to be limited in scope, but
>         just 3 or 4
>         >>> random items, I'm not sure if this helps in short term
>         PMIP6
>         >>> requirements.
>         >>> I've no issue with the currently listed items, but there
>         are other items
>         >>> that should get equal or higher priority.
>         >>
>         >> I have no problem with adding more. Even the charter says
>         new things can
>         >> be
>         >> added.
>         >>
>         >> However, from a process perspective what I did was to take
>         the proposal on
>         >> the table, i.e., the full BOF scope and see what parts of
>         that we already
>         >> have an agreement on. I didn't include other things that
>         were not
>         >> discussed
>         >> in the BOF. Maybe that would have been useful, but they
>         were not on the
>         >> table.
>         >>
>         >> We could add more items now, if there's general agreement
>         that those
>         >> things
>         >> are useful. However, I do not want to declare an open
>         season on doing
>         >> everything. We pick a reasonable subset of all proposed
>         work, based on
>         >> priorities, community agreement that they are the right
>         things to do,
>         >> management reasons to ensure that we are not doing too
>         much, etc.
>         >>
>         >>> For example, item #6, is absolutely required, from the
>         perspective of
>         >>> having a complete specification of 5213. There we allowed
>         a mobile node
>         >>> to
>         >>> perform handoff betweek two interfaces. We defined all the
>         hooks on the
>         >>> network side, but we did not provide how a terminal vendor
>         can support
>         >>> that. A simple informational draft on how some one move
>         prefixes between
>         >>> interfaces will greatly help. Some guidance on how to
>         create a virtual
>         >>> interface and also some related notes for each platform
>         (Linux, BSD,
>         >>> Android ..etc). This should not fall in the controversial
>         discussion
>         >>> scope
>         >>> of same address on two interfaces etc, thats a different
>         problem, or
>         >>> about
>         >>> the issue of enhancing mobile node's capabilities. This is
>         just
>         >>> informational work, required to leverage what 5213 already
>         supports.
>         >>
>         >> I suspect this is about the scoping of the handoff work.
>         Lets try to
>         >> figure
>         >> out what makes sense (I personally believe the above item
>         makes sense, for
>         >> instance) and what doesn't.
>         >>
>         >> The fact that these parts were not in the charter was not a
>         declaration
>         >> that
>         >> we're dismissing them. Its just that we didn't finish the
>         discussion, but
>         >> I
>         >> still wanted to let the other things move forward.
>         >>
>         >>> Item #2, is required. The multimob BOF raised some issues,
>         we need to
>         >>> show how multicast services can be enabled in PMIP
>         network. May be this
>         >>> wont require extensions, a simple draft covering those
>         aspects will help.
>         >>
>         >> As you may recall, in the Multimob BOF we did not have an
>         agreement on
>         >> what
>         >> exactly is needed, if anything. My own conclusion is that
>         we probably need
>         >> at least an informational document that explains how to use
>         RFC 5213 for
>         >> multicast. I think we discussed the possibility of doing
>         this as some kind
>         >> of AD sponsored document or in one of the relevant WGs, as
>         a joint work
>         >> between PMIP and multicast experts.
>         >>
>         >> I'm on the fence about adding this work to the charter
>         right now, mainly
>         >> because the BOF back then was very inconclusive. I'd be
>         happier if I saw
>         >> an
>         >> actual well written draft from say you and some of the
>         multicast experts.
>         >> There's no problem moving good documents forward, even if
>         they are not in
>         >> the charter of some WG. Then again, I wouldn't necessarily
>         mind a
>         >> maintenance like item for this in one of the WG charters
>         either.
>         >>
>         >>> I think, the charter should be bit more relaxed and more
>         extensive. As I
>         >>> see it, atleast the folks are interested in doing the
>         work. We should add
>         >>> atleast 4 or 5 more items to this list.
>         >>
>         >> Generally speaking IETF WG charters give specific work
>         items that the WG
>         >> should work on. I had hoped that the charter text:
>         >>
>         >> "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."
>         >>
>         >> gives an indication that we intend to do more! I am also
>         personally very
>         >> happy to add more items to the group's charter. All in all,
>         I do know that
>         >> the current charter is a bit on the thin side -- mostly
>         because the
>         >> multihoming/interaccess issue is under discussion.
>         >>
>         >> There's also the question of general maintenance items.
>         Some IETF WGs have
>         >> a
>         >> general work item to fix problems and issue updates to
>         existing
>         >> specifications. I think we need to do that for Proxy Mobile
>         IPv6 as well.
>         >> But we have not decided whether that item should go to
>         NETLMM or NETEXT WG
>         >> yet. Please rest assured that the work will be possible
>         regardless of
>         >> this.
>         >>
>         >>> 1. Dynamic LMA Assignment
>         >>>
>         >>> In blade architecture systems or in a load balancer
>         configuration, the
>         >>> PDNGW
>         >>> should have the ability to dynamically assign a LMA on the
>         fly, along the
>         >>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment
>         support
>         >>> [RFC-4433].
>         >>> Currently, GTP provides such semantics and this is a
>         important
>         >>> requirement
>         >>> for deployment. Here the goal is to
>         >>>
>         >>> a.) Expose a single IP address to the SGW
>         >>> b.) The exposed IP address should not be in path once the
>         assignment is
>         >>> done.
>         >>>
>         >>>
>         >>>
>         >>> [LMA1]---
>         >>> | |
>         >>> [LMA2]--[LMA]==========[MAG]
>         >>> | |
>         >>> [LMA3]---
>         >>>
>         >>>
>         >>> Along the lines of:
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>         >>
>         >> This is in the proposed NETEXT charter already.
>         >>
>         >>> 2. Multicast Support in Proxy Mobile IPv6
>         >>>
>         >>> We need an informational specification on how multicast
>         support can be
>         >>> enabled in Proxy Mobile IPv6 environment. Behcet has done
>         extensive
>         >>> analysis
>         >>> on
>         >>> this. This is required and critical for enabling any
>         multicast services.
>         >>> However,
>         >>> Behcet may disagree with the scope of the work.
>         >>
>         >> See above.
>         >>
>         >>> 3. Bulk Registration Support
>         >>>
>         >>> This is a simple extension which helps in signaling
>         optimization, along
>         >>> the
>         >>> lines of:
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>         >>
>         >> This is in the charter as well.
>         >>
>         >>> 4. Partial Failover Support
>         >>>
>         >>> We need a mechanism to notify the peer on revoke a partial
>         set of
>         >>> bindings.
>         >>>
>         >>>
>         >>>
>         >>>
>         http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>         >>> txt
>         >>
>         >> Hmm. Ok. This needs more discussion.
>         >>
>         >>> 5. Group Identifier Support for Proxy Mobile IPv6
>         >>>
>         >>> This provides a simple and a generic semantic for
>         assigning a group
>         >>> identifier
>         >>> to a mobile node's binding. GTP has very similar
>         semantics, Connexion Set
>         >>> Id.
>         >>> Both #3 and #4 can leverage this. Additionally, in load
>         balancer systems
>         >>> where
>         >>> the load balancer is in path for all signaling messages,
>         it can use this
>         >>> as
>         >>> a
>         >>> tag for redirecting the message.
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>         >>
>         >> Since the bulk registration work is in the charter, can't
>         you do the
>         >> sensible design (whatever it is) under that? There is no
>         requirement that
>         >> one charter item equals one document.
>         >>
>         >>> 6. Virtual-Interface Support on IP host for supporting
>         Inter-tech
>         >>> handoffs:
>         >>>
>         >>>
>         >>> RFC-5213 supports handoff between two interfaces. The
>         ability to move
>         >>> prefixes between interfaces. In other words address
>         continuity is assured
>         >>> with any IPv6 host on the planet and with absolutely no
>         changes. This
>         >>> meets
>         >>> even Dave's comment, that "no changes to any IETF RFC's.".
>         Now, what is
>         >>> not assured is the aspect of session continuity. Which
>         requires a virtual
>         >>> interface implementation on the host, by binding the
>         address/prefix to a
>         >>> virtual interface and by not exposing the physical
>         interface or by hiding
>         >>> the handoff events from the layer-3 stack.
>         >>>
>         >>> In essence, we need an informational specification which
>         provides some
>         >>> general guidance to how to leverage the feature support
>         provided in
>         >>> RFC-5213,
>         >>> along the lines of:
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>         >>
>         >> This is part of the discussion that we need to finish. But
>         I plan to let
>         >> the
>         >> rest of the stuff move forward even before we have done
>         that.
>         >>
>         >>
>         >>> 7. Route Optimization for Proxy Mobile IPv6
>         >>>
>         >>> There were atleast 4 drafts in this area on Route
>         Optimization. Marco
>         >>> Liebsch
>         >>> analyzed this exensively:
>         >>>
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>         >>>
>         >>>
>         >>>
>         http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>         >>> txt
>         >>
>         >> This is in the charter.
>         >>
>         >>> 8. Prefix Management in Proxy Mobile IPv6 support
>         >>>
>         >>> Proxy Mobile IPv6 allows the assignment of multiple home
>         network prefixes
>         >>> to a given mobile node's interface. It might be useful to
>         specify how the
>         >>> LMA manages this aspects. It can potentially use DHCP PD,
>         Local Pools or
>         >>> AAA to manage this aspect. Behcet has one draft on this.
>         >>
>         >> I'm not personally sold on this particular work. But again,
>         this could be
>         >> something to consider.
>         >>
>         >>> 9. Partial Handoff Support
>         >>>
>         >>> We are missing some semantics in 5213 for moving a subset
>         of the prefixes
>         >>> between interfaces as part of the inter-tech handoff. This
>         is about
>         >>> defining
>         >>> a new handoff value. This allows partial flow management,
>         but moving the
>         >>> flows associated to a prefix, as a whole group.
>         >>>
>         >>>
>         >>>
>         http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>         >>
>         >> A part of the topic we still need to discuss...
>         >>
>         >>> 10. CMIPv4/PMIP Interworking
>         >>>
>         >>> This is probably required to specify how an IPv4-only can
>         move between
>         >>> CMIP and PMIP environments.
>         >>>
>         >>>
>         >>>
>         >>>
>         http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>         >>> meghana-netlmm-pmipv6-mipv4-00.txt
>         >>
>         >> Client MIPv6 and Proxy MIPv6 interoperability is already in
>         the NETLMM
>         >> charter, but this work is presumably about interaction with
>         MIPv4. Might
>         >> be
>         >> useful work, I wouldn't mind if this was done in NETEXT at
>         some point. Is
>         >> this crucial to be in the first revision of the WG's
>         charter?
>         >>
>         >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile
>         IPv6
>         >>
>         >> Can you expand on this?
>         >>
>         >> Jari
>         >>
>         >> _______________________________________________
>         >> 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
>         >
>         >
>         
>         _______________________________________________
>         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/
-- 
   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/20090416/e7f8bde6/attachment.bin>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 18:14:56 -0400
Subject: [Netext] LMA redirection (was RE: WG Review: Network-Based Mobility Extensions (netext))
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri, 

> Ok. How can we prove it either way. Lets hear from the
> WG, if how many other folks have concerns keeping it on
> standards track.
> 
> Either way, as I was told the planned charter evolved
> based on the BOF WG feedback.

There was less than 5 minutes for this presentation. I couldn't even go
to the mike and saying something. But I had already given feedback on
this to the authors, to the chairs and to you offline before and during
the IETF meeting. 

Before the BoF, there hasn't been any discussion on this on the mailing
list. 

I was actually surprised to see this on the charter.

> >> and we need a ratified well thought out
> >> solution and not with the purpose of gathering more practical
> >> data via experimental track.
> >
> > An experimental RFC does not mean it is intended for 
> testbeds and such.
> > It just means we are not sure if this is *the* solution.
> >
> 
> But, I'm sure we need this :), just as you are not sure.

FWIW, there a lot of vendors who already do this kind of load balancing
across blades in a chassis without modifying the protocol exchanges.
What more proof do you need?

Vijay

> 
> Lets hear from the WG ...
> 
> Thanks
> Sri
> 
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 15 Apr 2009 15:10:14 -0700 (PDT)
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

<taking IESG off, as the quality of the discussion is going down>

On Wed, 15 Apr 2009, Vijay Devarapalli wrote:

> Hi Sri,
>
>> This has to be on standards track, as I see it, most vendors
>> will implement it
>
> This is pure speculation.
>

Ok. How can we prove it either way. Lets hear from the
WG, if how many other folks have concerns keeping it on
standards track.

Either way, as I was told the planned charter evolved
based on the BOF WG feedback.

>> and we need a ratified well thought out
>> solution and not with the purpose of gathering more practical
>> data via experimental track.
>
> An experimental RFC does not mean it is intended for testbeds and such.
> It just means we are not sure if this is *the* solution.
>

But, I'm sure we need this :), just as you are not sure.

Lets hear from the WG ...

Thanks
Sri

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 15 Apr 2009 14:13:53 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Teemu,

Sorry for the delayed response. Please see inline.

>
> There are many OS'es, some of which are proprietary and/or used in embedded and/or strongly controlled devices - in such cases it may not be possible just to run a tool or just install application to do the trick even if the device is based on open OS (and especially not by the end users of those systems). These kinds of devices are pretty common in some environments where PMIP6 is planned to be used.. Support for PMIP6 based inter-access handovers would definitely be considered as a change that would need to be justified, implemented, and verified.
>

You make good points. I agree with you and Domagoj that to be able
to say we have a complete solution for inter-tech handoffs, there
has to be some support from the host. As you earlier put it, the
solution has to assume few things on the host, with respect
configuration or might require some special application support. But,
before we call it a "host change", lets make sure we certainly require
changes to 4861 or other IETF specs, as that appears to be the
definition of "host change", in the absence of a standard definition
of "standard host". We can always state our requirements on the host
for supporting  a given feature and move on.

A solution such as a using virtual interface, to most part, allows
the host to be able to perform handoffs, between interfaces. Should
not be an issue. However, we might still require the following, that
may qualify as a "host change", but depends on how the solution is
built.

- Handoff hint exchange between the network and the host. Notifying
   the purpose of a given attachment, handoff vs new attachment.

- For flow management, network and the host being in sync w.r.t to
   what flows are being moved around.

- Connection Manager, a common component which cant be avoided, CMIP
   or PMIP.

As you pointed out to your docs, broadly the above requirements
should be sufficient. May be MN-AR interface doc would have helped
here, but we killed it.

> From my perspective the L2 changes are not very feasible approach: 
> existing L$

Depends on how we build that interface layer. May be an application
interface, or some minimal extensions to ND options, need not be
L2 change.

Regards
Sri

> In the context of IETF - and wider - discussion, I have been concerned about the message I often hear: that PMIP6 would not require host changes for inter-access mobility. The problem is that some actually read that message literally.
>
> In http://tools.ietf.org/html/draft-premec-netlmm-intertech-handover-01 we describe at least some of the impacts (with also solution considerations & proposals):
> - multihoming & handoffs (when the address should be moved from one access to another, when to ask for different address for different access, when to have same address on multiple accesses simultanously and also have mechahisms for flow distribution)
> - overlapping IPv4 address spaces (how to know if 192.168.0.1 on two interfaces is logically the same or different address)
> - different MTUs
> - zero physical interface situation (i.e. the transition period when old access goes away and before the new access comes available)
>
> From my perspective the L2 changes are not very feasible approach: existing L2s would need to be changed (=very difficult to get done), and future L2 developers would also need to take care of this dependency. It is easier to handle mobility for IP at L3.
>
> Some people have been concerned on interoperability, but I don't think that is an issue: the hosts that would not implement suggested host changes (virtual interfaces, possibly required L3 signaling for advanced handoff scenarios) would work just as they do if they don't support client mobile IP either - they simply do not get seamless inter-technology handovers, but will need to manage with application level reconnection/multihoming techniques.
>
> Best regards,
>
> 	Teemu

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 17:12:12 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri, 

> This has to be on standards track, as I see it, most vendors
> will implement it 

This is pure speculation.

> and we need a ratified well thought out
> solution and not with the purpose of gathering more practical
> data via experimental track.

An experimental RFC does not mean it is intended for testbeds and such.
It just means we are not sure if this is *the* solution.

Vijay

> 
> Sri
> 
> 
> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> 
> > Sri,
> >
> > PMIPv6 is not special. You run into the scalability issue - 
> how to scale
> > gracefully by adding more blades into a chassis and 
> linearly increase
> > the number of subscribers you handle, for any service. It 
> could be Proxy
> > CSCF in IMS, security gateways for IPsec VPNs, media 
> gateways in IMS,
> > etc...
> >
> > So its not clear why you need a standards track document for PMIPv6
> > alone.
> >
> > Vijay
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: Wednesday, April 15, 2009 12:07 PM
> >> To: Vijay Devarapalli
> >> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
> >> Subject: RE: [Netext] WG Review: Network-Based Mobility
> >> Extensions (netext)
> >>
> >> Hello Vijay,
> >>
> >> In the absence of any protocol semantics, the primary LMA 
> will always
> >> be in path. So, vendor specific solutions cannot address 
> this issue.
> >>
> >> We need to provide semantics with the following goals in mind:
> >>
> >> - Expose a single address for the entire LMA infrastructure
> >> - Allow the primary LMA to dynamically assign the LMA for a
> >>    given session. We already have precedence for this in the
> >>    form of RFC-4433, Dynamic Home Agent Assignment.
> >> - Not require the primary LMA to be in path, once the assignment
> >>    is done
> >> - Not require multiple MIP signaling round trips after each
> >>    assignment.
> >>
> >> But, I agree to your one point, the solution has to be more
> >> generic and not to address a specific corner case.
> >>
> >> As I see it, the current proposal from Jouni is generic enough.
> >>
> >> Any case, we can discuss and not bother IESG with this.
> >>
> >> Thanks
> >> Sri
> >>
> >>
> >>
> >> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> >>
> >>> Hello Sri,
> >>>
> >>> The scalability problem as you mentioned below can be done in an
> >>> implementation specific manner. Many vendors already have 
> solutions
> >>> where scalability is handled in a multi-blade chassis architecture
> >>> transparently without modifying the Proxy BU/Proxy BAck
> >> signaling with
> >>> the MAG.
> >>>
> >>> We can't have solutions that address limitations in 
> scaling in some
> >>> vendor's platform architecture on the Standards Track in the IETF.
> >>>
> >>> Vijay
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Sri Gundavelli [mailto:sgundave at cisco.com]
> >>>> Sent: Wednesday, April 15, 2009 11:35 AM
> >>>> To: Vijay Devarapalli
> >>>> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
> >>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
> >>>> Extensions (netext)
> >>>>
> >>>> It has to be more generic. If the serving LMA's are configured on
> >>>> individual blades, in a blade architecture system, or if the
> >>>> blades are standalone systems, is upto the given deployment.
> >>>>
> >>>> As I see it, it requires each of the serving LMA to be
> >> reachable using
> >>>> an IP address, so for all practical purposes they are
> >>>> indivual nodes. If
> >>>> these nodes endup as blades, that is fine and the 
> solution is still
> >>>> generic enough.
> >>>>
> >>>> This should be on standards track, it addresses a
> >> practical deployment
> >>>> or scalability problem.
> >>>>
> >>>> Sri
> >>>>
> >>>>
> >>>> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I have a comment on one of the items proposed.
> >>>>>
> >>>>> IESG Secretary wrote:
> >>>>>
> >>>>>>  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, and is complementary to the initial LMA
> >>>> discovery work in the
> >>>>>>  NETLMM WG.
> >>>>>>
> >>>>>>  January 2009 Submit LMA Redirection to IESG for 
> publication as a
> >>>>>>  Proposed Standard RFC
> >>>>>
> >>>>> I would like to see this as an Experimental RFC.
> >>>>>
> >>>>> Based on the discussions I had with the authors on this
> >>>> draft, the main
> >>>>> motivation for this work seems to be the need for load
> >>>> balancing across
> >>>>> multiple application blades in a multi-blade chassis
> >>>> platform for the LMA.
> >>>>> Typically, when you have a multi-blade chassis, load
> >>>> balancing or the
> >>>>> distribution of sessions across blades, as I like to call
> >>>> it, is done
> >>>>> transparently. This is not visible to any external node.
> >>>> The whole chassis
> >>>>> appears as a one LMA to the external network. Folks are
> >>>> trying to use the
> >>>>> redirect mechanism, basically telling the MAG to go to
> >>>> another blade, during
> >>>>> session setup for load balancing. This introduces an
> >>>> additional round trip
> >>>>> for most sessions.
> >>>>>
> >>>>> I had some reservations on this work item from the beginning. We
> >>>>> unfortunately couldn't discuss this in the BoF as there was
> >>>> very little time
> >>>>> for this. But I do acknowledge that there is some interest
> >>>> in seeing this
> >>>>> extension standardized.
> >>>>>
> >>>>> Having this redirect mechanism on Standards Track is not
> >>>> something I am
> >>>>> comfortable with right now. Load balancing across multiple
> >>>> blades can be done
> >>>>> in an implementation specific manner.
> >>>>>
> >>>>> Vijay
> >>>>>
> >>>>> _______________________________________________
> >>>>> NetExt mailing list
> >>>>> NetExt at mail.mobileip.jp
> >>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 14:10:29 -0700
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni,

Experimental RFC does not mean it is intended for experiments in a lab. :)

FWIW, Standards Track means that the IETF thinks that this is the best 
possible solution for a particular problem. This is not true in this 
case, as many vendors already do LMA load balancing in an implementation 
specific manner transparently without modifying the protocol exchange 
with the MAG.

If it turns out that this LMA redirect mechanism does get implemented 
and used widely, we can revise the experimental RFC and get it published 
as a Standards Track document. We have done this for a number of a 
documents in the path.

More inline...

jouni wrote:
> Hi Vijay,
> 
> 
> On Apr 15, 2009, at 9:06 PM, Vijay Devarapalli wrote:
> 
>> Hello,
>>
>> I have a comment on one of the items proposed.
>>
>> IESG Secretary wrote:
>>
>>> 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, and is complementary to the initial LMA discovery work in the
>>> NETLMM WG.
>>> January 2009 Submit LMA Redirection to IESG for publication as a
>>> Proposed Standard RFC
>>
>> I would like to see this as an Experimental RFC.
>>
>> Based on the discussions I had with the authors on this draft, the 
>> main motivation for this work seems to be the need for load balancing 
>> across multiple application blades in a multi-blade chassis platform 
>> for the LMA. Typically, when you have a multi-blade chassis, load 
>> balancing or the distribution of sessions across blades, as I like to 
>> call it, is done transparently. This is not visible to any external 
>> node. The whole chassis appears as a one LMA to the external network. 
>> Folks are trying to use the redirect mechanism, basically telling the 
>> MAG to go to another blade, during session setup for load balancing. 
>> This introduces an additional round trip for most sessions.
> 
> Whether a LMA is a blade in a chassis or a separate box has no 
> difference what we are trying to achieve. It is true that you can do 
> load balancing "transparently" but in that case the traffic will always 
> go through the "visible LMA" that was initially exposed to MAGs.. and at 
> least I want to avoid that. 

This is not an issue for many deployments.

> Relocating LMA at the protocol level seems 
> the most solid way of doing it. 

Sorry, I don't agree with this.

Vijay

Also, there are no additional roundtrips
> during the mobility session setup at the protocol level. That is also 
> one of the goals we are trying to achieve.
> 
> Im my opinion LMA redirection needs to be standards track. It is not 
> targeted for any experimental testing but deployments where scalability 
> is a real concern.
> 
> Cheers,
>     Jouni
> 
> 
>>
>>
>> I had some reservations on this work item from the beginning. We 
>> unfortunately couldn't discuss this in the BoF as there was very 
>> little time for this. But I do acknowledge that there is some interest 
>> in seeing this extension standardized.
>>
>> Having this redirect mechanism on Standards Track is not something I 
>> am comfortable with right now. Load balancing across multiple blades 
>> can be done in an implementation specific manner.
>>
>> Vijay
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: jouni.nospam at gmail.com (jouni)
Date: Wed, 15 Apr 2009 22:38:28 +0300
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

On Apr 15, 2009, at 9:06 PM, Vijay Devarapalli wrote:

> Hello,
>
> I have a comment on one of the items proposed.
>
> IESG Secretary wrote:
>
>> 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, and is complementary to the initial LMA discovery work  
>> in the
>> NETLMM WG.
>> January 2009 Submit LMA Redirection to IESG for publication as a
>> Proposed Standard RFC
>
> I would like to see this as an Experimental RFC.
>
> Based on the discussions I had with the authors on this draft, the  
> main motivation for this work seems to be the need for load  
> balancing across multiple application blades in a multi-blade  
> chassis platform for the LMA. Typically, when you have a multi-blade  
> chassis, load balancing or the distribution of sessions across  
> blades, as I like to call it, is done transparently. This is not  
> visible to any external node. The whole chassis appears as a one LMA  
> to the external network. Folks are trying to use the redirect  
> mechanism, basically telling the MAG to go to another blade, during  
> session setup for load balancing. This introduces an additional  
> round trip for most sessions.

Whether a LMA is a blade in a chassis or a separate box has no  
difference what we are trying to achieve. It is true that you can do  
load balancing "transparently" but in that case the traffic will  
always go through the "visible LMA" that was initially exposed to  
MAGs.. and at least I want to avoid that. Relocating LMA at the  
protocol level seems the most solid way of doing it. Also, there are  
no additional roundtrips during the mobility session setup at the  
protocol level. That is also one of the goals we are trying to achieve.

Im my opinion LMA redirection needs to be standards track. It is not  
targeted for any experimental testing but deployments where  
scalability is a real concern.

Cheers,
	Jouni

>
>
> I had some reservations on this work item from the beginning. We  
> unfortunately couldn't discuss this in the BoF as there was very  
> little time for this. But I do acknowledge that there is some  
> interest in seeing this extension standardized.
>
> Having this redirect mechanism on Standards Track is not something I  
> am comfortable with right now. Load balancing across multiple blades  
> can be done in an implementation specific manner.
>
> Vijay
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 15 Apr 2009 12:33:10 -0700 (PDT)
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Vijay,

Sure, for increasing  the capacity a given deployment will
certainly add more blades or modules.  But, as I said in
one of the listed points, we dont want the signaling to
always go through the primary, that is a limitation. So,
we need to provide protocol semantics to achieve this.

We could have assumed HA Swithover semantic is not required,
as the vendor has redundancy support and the blade reboot is
not require to be exposed to MN, but we provided a semantic to
build a generic solution. Same thing !

This has to be on standards track, as I see it, most vendors
will implement it and we need a ratified well thought out
solution and not with the purpose of gathering more practical
data via experimental track.

Sri

On Wed, 15 Apr 2009, Vijay Devarapalli wrote:

> Sri,
>
> PMIPv6 is not special. You run into the scalability issue - how to scale
> gracefully by adding more blades into a chassis and linearly increase
> the number of subscribers you handle, for any service. It could be Proxy
> CSCF in IMS, security gateways for IPsec VPNs, media gateways in IMS,
> etc...
>
> So its not clear why you need a standards track document for PMIPv6
> alone.
>
> Vijay
>
>> -----Original Message-----
>> From: Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: Wednesday, April 15, 2009 12:07 PM
>> To: Vijay Devarapalli
>> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
>> Subject: RE: [Netext] WG Review: Network-Based Mobility
>> Extensions (netext)
>>
>> Hello Vijay,
>>
>> In the absence of any protocol semantics, the primary LMA will always
>> be in path. So, vendor specific solutions cannot address this issue.
>>
>> We need to provide semantics with the following goals in mind:
>>
>> - Expose a single address for the entire LMA infrastructure
>> - Allow the primary LMA to dynamically assign the LMA for a
>>    given session. We already have precedence for this in the
>>    form of RFC-4433, Dynamic Home Agent Assignment.
>> - Not require the primary LMA to be in path, once the assignment
>>    is done
>> - Not require multiple MIP signaling round trips after each
>>    assignment.
>>
>> But, I agree to your one point, the solution has to be more
>> generic and not to address a specific corner case.
>>
>> As I see it, the current proposal from Jouni is generic enough.
>>
>> Any case, we can discuss and not bother IESG with this.
>>
>> Thanks
>> Sri
>>
>>
>>
>> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
>>
>>> Hello Sri,
>>>
>>> The scalability problem as you mentioned below can be done in an
>>> implementation specific manner. Many vendors already have solutions
>>> where scalability is handled in a multi-blade chassis architecture
>>> transparently without modifying the Proxy BU/Proxy BAck
>> signaling with
>>> the MAG.
>>>
>>> We can't have solutions that address limitations in scaling in some
>>> vendor's platform architecture on the Standards Track in the IETF.
>>>
>>> Vijay
>>>
>>>
>>>> -----Original Message-----
>>>> From: Sri Gundavelli [mailto:sgundave at cisco.com]
>>>> Sent: Wednesday, April 15, 2009 11:35 AM
>>>> To: Vijay Devarapalli
>>>> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
>>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>>> Extensions (netext)
>>>>
>>>> It has to be more generic. If the serving LMA's are configured on
>>>> individual blades, in a blade architecture system, or if the
>>>> blades are standalone systems, is upto the given deployment.
>>>>
>>>> As I see it, it requires each of the serving LMA to be
>> reachable using
>>>> an IP address, so for all practical purposes they are
>>>> indivual nodes. If
>>>> these nodes endup as blades, that is fine and the solution is still
>>>> generic enough.
>>>>
>>>> This should be on standards track, it addresses a
>> practical deployment
>>>> or scalability problem.
>>>>
>>>> Sri
>>>>
>>>>
>>>> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have a comment on one of the items proposed.
>>>>>
>>>>> IESG Secretary wrote:
>>>>>
>>>>>>  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, and is complementary to the initial LMA
>>>> discovery work in the
>>>>>>  NETLMM WG.
>>>>>>
>>>>>>  January 2009 Submit LMA Redirection to IESG for publication as a
>>>>>>  Proposed Standard RFC
>>>>>
>>>>> I would like to see this as an Experimental RFC.
>>>>>
>>>>> Based on the discussions I had with the authors on this
>>>> draft, the main
>>>>> motivation for this work seems to be the need for load
>>>> balancing across
>>>>> multiple application blades in a multi-blade chassis
>>>> platform for the LMA.
>>>>> Typically, when you have a multi-blade chassis, load
>>>> balancing or the
>>>>> distribution of sessions across blades, as I like to call
>>>> it, is done
>>>>> transparently. This is not visible to any external node.
>>>> The whole chassis
>>>>> appears as a one LMA to the external network. Folks are
>>>> trying to use the
>>>>> redirect mechanism, basically telling the MAG to go to
>>>> another blade, during
>>>>> session setup for load balancing. This introduces an
>>>> additional round trip
>>>>> for most sessions.
>>>>>
>>>>> I had some reservations on this work item from the beginning. We
>>>>> unfortunately couldn't discuss this in the BoF as there was
>>>> very little time
>>>>> for this. But I do acknowledge that there is some interest
>>>> in seeing this
>>>>> extension standardized.
>>>>>
>>>>> Having this redirect mechanism on Standards Track is not
>>>> something I am
>>>>> comfortable with right now. Load balancing across multiple
>>>> blades can be done
>>>>> in an implementation specific manner.
>>>>>
>>>>> Vijay
>>>>>
>>>>> _______________________________________________
>>>>> NetExt mailing list
>>>>> NetExt at mail.mobileip.jp
>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>
>>>>>
>>>>
>>>
>>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 15:17:33 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

PMIPv6 is not special. You run into the scalability issue - how to scale
gracefully by adding more blades into a chassis and linearly increase
the number of subscribers you handle, for any service. It could be Proxy
CSCF in IMS, security gateways for IPsec VPNs, media gateways in IMS,
etc...

So its not clear why you need a standards track document for PMIPv6
alone.

Vijay

> -----Original Message-----
> From: Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: Wednesday, April 15, 2009 12:07 PM
> To: Vijay Devarapalli
> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
> Subject: RE: [Netext] WG Review: Network-Based Mobility 
> Extensions (netext)
> 
> Hello Vijay,
> 
> In the absence of any protocol semantics, the primary LMA will always
> be in path. So, vendor specific solutions cannot address this issue.
> 
> We need to provide semantics with the following goals in mind:
> 
> - Expose a single address for the entire LMA infrastructure
> - Allow the primary LMA to dynamically assign the LMA for a
>    given session. We already have precedence for this in the
>    form of RFC-4433, Dynamic Home Agent Assignment.
> - Not require the primary LMA to be in path, once the assignment
>    is done
> - Not require multiple MIP signaling round trips after each
>    assignment.
> 
> But, I agree to your one point, the solution has to be more
> generic and not to address a specific corner case.
> 
> As I see it, the current proposal from Jouni is generic enough.
> 
> Any case, we can discuss and not bother IESG with this.
> 
> Thanks
> Sri
> 
> 
> 
> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> 
> > Hello Sri,
> >
> > The scalability problem as you mentioned below can be done in an
> > implementation specific manner. Many vendors already have solutions
> > where scalability is handled in a multi-blade chassis architecture
> > transparently without modifying the Proxy BU/Proxy BAck 
> signaling with
> > the MAG.
> >
> > We can't have solutions that address limitations in scaling in some
> > vendor's platform architecture on the Standards Track in the IETF.
> >
> > Vijay
> >
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: Wednesday, April 15, 2009 11:35 AM
> >> To: Vijay Devarapalli
> >> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
> >> Subject: Re: [Netext] WG Review: Network-Based Mobility
> >> Extensions (netext)
> >>
> >> It has to be more generic. If the serving LMA's are configured on
> >> individual blades, in a blade architecture system, or if the
> >> blades are standalone systems, is upto the given deployment.
> >>
> >> As I see it, it requires each of the serving LMA to be 
> reachable using
> >> an IP address, so for all practical purposes they are
> >> indivual nodes. If
> >> these nodes endup as blades, that is fine and the solution is still
> >> generic enough.
> >>
> >> This should be on standards track, it addresses a 
> practical deployment
> >> or scalability problem.
> >>
> >> Sri
> >>
> >>
> >> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> >>
> >>> Hello,
> >>>
> >>> I have a comment on one of the items proposed.
> >>>
> >>> IESG Secretary wrote:
> >>>
> >>>>  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, and is complementary to the initial LMA
> >> discovery work in the
> >>>>  NETLMM WG.
> >>>>
> >>>>  January 2009 Submit LMA Redirection to IESG for publication as a
> >>>>  Proposed Standard RFC
> >>>
> >>> I would like to see this as an Experimental RFC.
> >>>
> >>> Based on the discussions I had with the authors on this
> >> draft, the main
> >>> motivation for this work seems to be the need for load
> >> balancing across
> >>> multiple application blades in a multi-blade chassis
> >> platform for the LMA.
> >>> Typically, when you have a multi-blade chassis, load
> >> balancing or the
> >>> distribution of sessions across blades, as I like to call
> >> it, is done
> >>> transparently. This is not visible to any external node.
> >> The whole chassis
> >>> appears as a one LMA to the external network. Folks are
> >> trying to use the
> >>> redirect mechanism, basically telling the MAG to go to
> >> another blade, during
> >>> session setup for load balancing. This introduces an
> >> additional round trip
> >>> for most sessions.
> >>>
> >>> I had some reservations on this work item from the beginning. We
> >>> unfortunately couldn't discuss this in the BoF as there was
> >> very little time
> >>> for this. But I do acknowledge that there is some interest
> >> in seeing this
> >>> extension standardized.
> >>>
> >>> Having this redirect mechanism on Standards Track is not
> >> something I am
> >>> comfortable with right now. Load balancing across multiple
> >> blades can be done
> >>> in an implementation specific manner.
> >>>
> >>> Vijay
> >>>
> >>> _______________________________________________
> >>> NetExt mailing list
> >>> NetExt at mail.mobileip.jp
> >>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>
> >>>
> >>
> >
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 15 Apr 2009 12:07:27 -0700 (PDT)
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Vijay,

In the absence of any protocol semantics, the primary LMA will always
be in path. So, vendor specific solutions cannot address this issue.

We need to provide semantics with the following goals in mind:

- Expose a single address for the entire LMA infrastructure
- Allow the primary LMA to dynamically assign the LMA for a
   given session. We already have precedence for this in the
   form of RFC-4433, Dynamic Home Agent Assignment.
- Not require the primary LMA to be in path, once the assignment
   is done
- Not require multiple MIP signaling round trips after each
   assignment.

But, I agree to your one point, the solution has to be more
generic and not to address a specific corner case.

As I see it, the current proposal from Jouni is generic enough.

Any case, we can discuss and not bother IESG with this.

Thanks
Sri

On Wed, 15 Apr 2009, Vijay Devarapalli wrote:

> Hello Sri,
>
> The scalability problem as you mentioned below can be done in an
> implementation specific manner. Many vendors already have solutions
> where scalability is handled in a multi-blade chassis architecture
> transparently without modifying the Proxy BU/Proxy BAck signaling with
> the MAG.
>
> We can't have solutions that address limitations in scaling in some
> vendor's platform architecture on the Standards Track in the IETF.
>
> Vijay
>
>
>> -----Original Message-----
>> From: Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: Wednesday, April 15, 2009 11:35 AM
>> To: Vijay Devarapalli
>> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>> Extensions (netext)
>>
>> It has to be more generic. If the serving LMA's are configured on
>> individual blades, in a blade architecture system, or if the
>> blades are standalone systems, is upto the given deployment.
>>
>> As I see it, it requires each of the serving LMA to be reachable using
>> an IP address, so for all practical purposes they are
>> indivual nodes. If
>> these nodes endup as blades, that is fine and the solution is still
>> generic enough.
>>
>> This should be on standards track, it addresses a practical deployment
>> or scalability problem.
>>
>> Sri
>>
>>
>> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
>>
>>> Hello,
>>>
>>> I have a comment on one of the items proposed.
>>>
>>> IESG Secretary wrote:
>>>
>>>>  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, and is complementary to the initial LMA
>> discovery work in the
>>>>  NETLMM WG.
>>>>
>>>>  January 2009 Submit LMA Redirection to IESG for publication as a
>>>>  Proposed Standard RFC
>>>
>>> I would like to see this as an Experimental RFC.
>>>
>>> Based on the discussions I had with the authors on this
>> draft, the main
>>> motivation for this work seems to be the need for load
>> balancing across
>>> multiple application blades in a multi-blade chassis
>> platform for the LMA.
>>> Typically, when you have a multi-blade chassis, load
>> balancing or the
>>> distribution of sessions across blades, as I like to call
>> it, is done
>>> transparently. This is not visible to any external node.
>> The whole chassis
>>> appears as a one LMA to the external network. Folks are
>> trying to use the
>>> redirect mechanism, basically telling the MAG to go to
>> another blade, during
>>> session setup for load balancing. This introduces an
>> additional round trip
>>> for most sessions.
>>>
>>> I had some reservations on this work item from the beginning. We
>>> unfortunately couldn't discuss this in the BoF as there was
>> very little time
>>> for this. But I do acknowledge that there is some interest
>> in seeing this
>>> extension standardized.
>>>
>>> Having this redirect mechanism on Standards Track is not
>> something I am
>>> comfortable with right now. Load balancing across multiple
>> blades can be done
>>> in an implementation specific manner.
>>>
>>> Vijay
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>
>>>
>>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 14:55:11 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Sri,

The scalability problem as you mentioned below can be done in an
implementation specific manner. Many vendors already have solutions
where scalability is handled in a multi-blade chassis architecture
transparently without modifying the Proxy BU/Proxy BAck signaling with
the MAG. 

We can't have solutions that address limitations in scaling in some
vendor's platform architecture on the Standards Track in the IETF.

Vijay

> -----Original Message-----
> From: Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: Wednesday, April 15, 2009 11:35 AM
> To: Vijay Devarapalli
> Cc: iesg at ietf.org; Jari Arkko; netext at mail.mobileip.jp
> Subject: Re: [Netext] WG Review: Network-Based Mobility 
> Extensions (netext)
> 
> It has to be more generic. If the serving LMA's are configured on
> individual blades, in a blade architecture system, or if the
> blades are standalone systems, is upto the given deployment.
> 
> As I see it, it requires each of the serving LMA to be reachable using
> an IP address, so for all practical purposes they are 
> indivual nodes. If
> these nodes endup as blades, that is fine and the solution is still
> generic enough.
> 
> This should be on standards track, it addresses a practical deployment
> or scalability problem.
> 
> Sri
> 
> 
> On Wed, 15 Apr 2009, Vijay Devarapalli wrote:
> 
> > Hello,
> >
> > I have a comment on one of the items proposed.
> >
> > IESG Secretary wrote:
> >
> >>  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, and is complementary to the initial LMA 
> discovery work in the
> >>  NETLMM WG.
> >>
> >>  January 2009 Submit LMA Redirection to IESG for publication as a
> >>  Proposed Standard RFC
> >
> > I would like to see this as an Experimental RFC.
> >
> > Based on the discussions I had with the authors on this 
> draft, the main 
> > motivation for this work seems to be the need for load 
> balancing across 
> > multiple application blades in a multi-blade chassis 
> platform for the LMA. 
> > Typically, when you have a multi-blade chassis, load 
> balancing or the 
> > distribution of sessions across blades, as I like to call 
> it, is done 
> > transparently. This is not visible to any external node. 
> The whole chassis 
> > appears as a one LMA to the external network. Folks are 
> trying to use the 
> > redirect mechanism, basically telling the MAG to go to 
> another blade, during 
> > session setup for load balancing. This introduces an 
> additional round trip 
> > for most sessions.
> >
> > I had some reservations on this work item from the beginning. We 
> > unfortunately couldn't discuss this in the BoF as there was 
> very little time 
> > for this. But I do acknowledge that there is some interest 
> in seeing this 
> > extension standardized.
> >
> > Having this redirect mechanism on Standards Track is not 
> something I am 
> > comfortable with right now. Load balancing across multiple 
> blades can be done 
> > in an implementation specific manner.
> >
> > Vijay
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Wed, 15 Apr 2009 14:51:45 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marcelo,
 
it is not so much whether MIP6 works or not; it is assumed to work. We can (re)state it again that potential users of these technologies should consider MIP6 as a solution first.  
 
We have been trying to see if there is interest in working on PMIP6 extensions for multiple i/f support and inter-tech handovers. Those extensions do not necessarily transform the protocol to MIP6, although one could make such an extrapolation. If there is interest in this, we need to determine a way forward while recognizing that MIP6 is one solution.  
 
Regards,
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of marcelo bagnulo braun
Sent: Wed 4/15/2009 3:30 AM
To: Qin Wu
Cc: iesg at ietf.org; netext at mail.mobileip.jp
Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions (netext)

Qin Wu escribi?:
> Hi, Maro ,George and all:
> I tend to agree with Marco's point.
> No MN involvement means MN does not involve in network layer/IP layer moblity management.However it does not restrict MN to involve in out of band signaling.
> On the other hand, no MN involvement does not mean no host change.  Host changes can be divided into changes in different levels,e.g., IP stack level change, application level change, etc. For some case without MN involvement, the host changes below or over the IP layer can be allowed. So I think we should be careful to interpret it if we include "no MN involvement" in the current charter.
>
>  

right
but once we accept that we can do changes in the MN (whcih was out of
the scope for netlmm), then we need to open the discssion for what
changes are better. On possible change is to include a MIP
implementation in the node and there seems to be evidence that that
approach works.

Regards, marcelo

> Regards!
> -Qin
> ----- Original Message -----
> From: "Marco Liebsch" <marco.liebsch at nw.neclab.eu>
> To: "George Tsirtsis" <tsirtsis at googlemail.com>
> Cc: <netext at mail.mobileip.jp>; <iesg at ietf.org>
> Sent: Wednesday, April 15, 2009 5:18 PM
> Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions (netext)
>
>
>  
>> George,
>>
>> George Tsirtsis schrieb:
>>    
>>> Vijay,
>>>
>>> The "no-MN-involvement" clause was central to the NETLMM BOF becoming
>>> a WG. This is the reason PMIPv6 exists i.e., to provide a mobility
>>> management mechanism that unlike MIPv6, does not require MN
>>> involvement.
>>>
>>> The recent controversy is about adding further support for
>>> inter-technology handoffs and for multihoming, which some of us argue
>>> will definitely require MN involvement and thus, PMIPv6 should stay
>>> away from such features.
>>>
>>> If the no-MN-involvement clause is not included in the charter, then I
>>> would argue that we need to define exactly what kind of MN-involvement
>>> is acceptable. This is important because some people in this group
>>> think that only MN software is needed (e.g., virtual interfaces) but
>>> no protocols, others think that it is OK for the IETF to rely on link
>>> layer software to do their job, and others want to do it at the
>>> network layer, making PMIPv6 to directly compete with MIPv6.
>>>  
>>>      
>> I don't think this makes PMIPv6 compete with MIPv6. Unfortunately this
>> is the way some of us want to understand it. There is sufficient benefit
>> in using
>> PMIPv6, even with some host changes. This includes no encapsulation on the
>> radio interface and use of a single IP address (prefix) beyond the scope
>> of a
>> single access router. I think we can agree that, according to the
>> original definition,
>> hosts are not involved in IP mobility management. I don't see the reason
>> why not
>> permitting host involvement in some local functions such as multiple
>> radio interface
>> setup and configuration of associated routes. Even signaling some
>> indications towards
>> the network infrastructure about the mobile node's interest in using
>> more than one interface
>> seems to be outside of what IP mobility management does. In particular,
>> I don't see this
>> competes with host mobility..
>>
>> I think the "no host involvement" argument does not hold, in particular
>> as it allows
>> to much degree of freedom in interpretation. I don't think any strict
>> 'no host modification'
>> argument can avoid some out of band signaling, which is used in the end
>> by the
>> infrastrucre to enforce a particular behvior in PMIPv6 operation. So, I
>> think we should
>> rather converge on what level of mobile node extensions are acceptable.
>>
>> marco
>>
>>    
>>> All of these are "controversial" and the subject of much recent discussion.
>>> So, it is the *omission* of the no-MN-Involvement clause that will
>>> cause confusion, and its controversial, not its inclusion. The
>>> no-MN-involvement clause has been there from the beginning and it
>>> should only be removed conciously and for good reasons.
>>>
>>> Regards
>>> George
>>>
>>>
>>>
>>>
>>> On Wed, Apr 15, 2009 at 12:13 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
>>>  
>>>      
>>>> George,
>>>>
>>>> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>>>>
>>>> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>>>>
>>>> Vijay
>>>>
>>>>    
>>>>        
>>>>> -----Original Message-----
>>>>> From: netext-bounces at mail.mobileip.jp
>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>>>>> Sent: Tuesday, April 14, 2009 1:59 PM
>>>>> To: Jari Arkko
>>>>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>>>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>>>> Extensions (netext)
>>>>>
>>>>> Hi Jari et.al.,
>>>>>
>>>>> I think the work items listed reflect the current level of agreement
>>>>> on this work, but I would like to see the following limitation in the
>>>>> charter.
>>>>>
>>>>> I would suggest that a statement reaffirming the "no MN involvement"
>>>>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>>>>> Charter, and which is still the basis for the existence of PMIPv6, is
>>>>> still valid in this new WG, tasked with extending it.
>>>>>
>>>>> Just for people who do not remember, the NETLMM charter states (in
>>>>> multiple places) that:
>>>>> "  ...all features defined must work with unmodified IP nodes.
>>>>> Specifying any changes to mobile nodes is out of scope of the current
>>>>> charter".
>>>>>
>>>>> I suggest that the same clause is added in the NETEXT charter, at
>>>>> least in this version of the charter, and at least until the
>>>>> discussion about the more controversial work items (inter-technology
>>>>> handoffs and multihoming) concludes.
>>>>>
>>>>> Regards
>>>>> George
>>>>>
>>>>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>>>>> <iesg-secretary at ietf.org> wrote:
>>>>>      
>>>>>          
>>>>>> A new IETF working group has been proposed in the Internet
>>>>>>        
>>>>>>            
>>>>> Area.  The IESG
>>>>>      
>>>>>          
>>>>>> has not made any determination as yet.  The following draft
>>>>>>        
>>>>>>            
>>>>> charter was
>>>>>      
>>>>>          
>>>>>> submitted, and is provided for informational purposes only.
>>>>>>        
>>>>>>            
>>>>>  Please send
>>>>>      
>>>>>          
>>>>>> your comments to the IESG mailing list (iesg at ietf.org) by
>>>>>>        
>>>>>>            
>>>>> Tuesday, April
>>>>>      
>>>>>          
>>>>>> 21, 2009.
>>>>>>
>>>>>> Network-Based Mobility Extensions (netext)
>>>>>> -------------------------------------------------------------
>>>>>>
>>>>>> Last Modified: 2009-04-03
>>>>>>
>>>>>> 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. Hosts
>>>>>      
>>>>>          
>>>>>> are not affected, as they still send and receive their
>>>>>>        
>>>>>>            
>>>>> packets via the
>>>>>      
>>>>>          
>>>>>> MAG.
>>>>>>
>>>>>> 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, and is complementary to the initial LMA
>>>>>>        
>>>>>>            
>>>>> discovery work in the
>>>>>      
>>>>>          
>>>>>> NETLMM WG.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Milestones
>>>>>>
>>>>>> May 2009 WG chartered
>>>>>> July 2009 Initial WG draft on Bulk Refresh
>>>>>> 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 2009 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
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>      
>>>>>          
>>> _______________________________________________
>>> 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
>>
>>    
> _______________________________________________
> 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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 15 Apr 2009 11:35:29 -0700 (PDT)
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

It has to be more generic. If the serving LMA's are configured on
individual blades, in a blade architecture system, or if the
blades are standalone systems, is upto the given deployment.

As I see it, it requires each of the serving LMA to be reachable using
an IP address, so for all practical purposes they are indivual nodes. If
these nodes endup as blades, that is fine and the solution is still
generic enough.

This should be on standards track, it addresses a practical deployment
or scalability problem.

Sri

On Wed, 15 Apr 2009, Vijay Devarapalli wrote:

> Hello,
>
> I have a comment on one of the items proposed.
>
> IESG Secretary wrote:
>
>>  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, and is complementary to the initial LMA discovery work in the
>>  NETLMM WG.
>>
>>  January 2009 Submit LMA Redirection to IESG for publication as a
>>  Proposed Standard RFC
>
> I would like to see this as an Experimental RFC.
>
> Based on the discussions I had with the authors on this draft, the main 
> motivation for this work seems to be the need for load balancing across 
> multiple application blades in a multi-blade chassis platform for the LMA. 
> Typically, when you have a multi-blade chassis, load balancing or the 
> distribution of sessions across blades, as I like to call it, is done 
> transparently. This is not visible to any external node. The whole chassis 
> appears as a one LMA to the external network. Folks are trying to use the 
> redirect mechanism, basically telling the MAG to go to another blade, during 
> session setup for load balancing. This introduces an additional round trip 
> for most sessions.
>
> I had some reservations on this work item from the beginning. We 
> unfortunately couldn't discuss this in the BoF as there was very little time 
> for this. But I do acknowledge that there is some interest in seeing this 
> extension standardized.
>
> Having this redirect mechanism on Standards Track is not something I am 
> comfortable with right now. Load balancing across multiple blades can be done 
> in an implementation specific manner.
>
> Vijay
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 11:06:28 -0700
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I have a comment on one of the items proposed.

IESG Secretary wrote:

> 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, and is complementary to the initial LMA discovery work in the
> NETLMM WG.
> 
> January 2009 Submit LMA Redirection to IESG for publication as a
> Proposed Standard RFC

I would like to see this as an Experimental RFC.

Based on the discussions I had with the authors on this draft, the main 
motivation for this work seems to be the need for load balancing across 
multiple application blades in a multi-blade chassis platform for the 
LMA. Typically, when you have a multi-blade chassis, load balancing or 
the distribution of sessions across blades, as I like to call it, is 
done transparently. This is not visible to any external node. The whole 
chassis appears as a one LMA to the external network. Folks are trying 
to use the redirect mechanism, basically telling the MAG to go to 
another blade, during session setup for load balancing. This introduces 
an additional round trip for most sessions.

I had some reservations on this work item from the beginning. We 
unfortunately couldn't discuss this in the BoF as there was very little 
time for this. But I do acknowledge that there is some interest in 
seeing this extension standardized.

Having this redirect mechanism on Standards Track is not something I am 
comfortable with right now. Load balancing across multiple blades can be 
done in an implementation specific manner.

Vijay

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 15 Apr 2009 13:57:35 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Jari and the IESG,

I would like to add one more item to the charter. 

We spent quite a bit of effort looking into the various scenarios for
multiple interface support with PMIPv6. We have been working on two
problem statement drafts related to these scenarios. I think NetExt
should continue working on the problem statement drafts. They should
clearly describe what the issues are when PMIPv6 is used for mobility
management in these scenarios. Since these are problem statement drafts,
they won't be talking about solutions. The actual solutions, if we
decide to work on any, can only be done by re-chartering.

So I propose the following additions to the charter.

Multiple Interface Support: The working group will work on problem
statements that analyze the scenarios associated with a host attaching
to the PMIPv6 domain with multiple interfaces. These problem statements
will capture what the issues are with the use of PMIPv6 for mobility
management in these scenarios. The working group shall not work on
solutions in this space.

October 2009 Submit problem statement on using PMIPv6 for handovers
across interfaces to the IESG for publication as an Informational RFC
October 2009 Submit problem statement on using PMIPv6 for multiple
interface support to the IESG for publication as an Informational RFC

Does this sound good?

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of IESG Secretary
> Sent: Tuesday, April 14, 2009 1:00 PM
> To: ietf-announce at ietf.org
> Cc: netext at mail.mobileip.jp
> Subject: [Netext] WG Review: Network-Based Mobility 
> Extensions (netext)
> 
> A new IETF working group has been proposed in the Internet 
> Area.  The IESG
> has not made any determination as yet.  The following draft 
> charter was
> submitted, and is provided for informational purposes only.  
> Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 
> Tuesday, April
> 21, 2009.
> 
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts
> are not affected, as they still send and receive their packets via the
> MAG.
> 
> 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, and is complementary to the initial LMA discovery 
> work in the
> NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> 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 2009 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
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Wed, 15 Apr 2009 10:13:47 -0700
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

The way I understand the motivations to create netext WG is to extend PMIPv6 with some new functionality required by deployments within the scope of what IETF agreed NETLMM can be used. NETLMM WG was chartered and created with a very specific assumption which is stated below (from the charter):

" Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter."

This was the key point of NETLMM and it was the main reason why IETF started the work, i.e. to support unmodified hosts. Based on this assumption, PMIPv6 was chosen as the NETLMM protocol. If netext is going to work on PMIPv6 extensions, IMO it needs to work within the scope PMIPv6 was defined, i.e. work with unmodified IP nodes. 

As you mentioned, the current work items do not affect hosts and this is why they are not controversial, i.e. because they are in line with the scope NETLMM was created. Therefore it makes sense to state explicitly in the charter that we are still maintaining the assumptions based on which PMIPv6 was specified in RFC 5213. This is a key principle which should be in the charter as it reflects what was agreed when NETLMM WG was created (and this agreement never changed as far as I know).

If the IETF community will decide that it makes sense to have host changes for PMIPv6 extensions, we will remove this principle from the charter. However there is not agreement on this yet and this is why we should keep the principle clearly stated in the charter. 

Thanks
Gerardo 

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Jari Arkko
> Sent: Wednesday, April 15, 2009 1:47 AM
> To: George Tsirtsis
> Cc: netext at mail.mobileip.jp; iesg at ietf.org
> Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions (netext)
> 
> George, Vijay,
> 
> The three current work items do not affect hosts in any way. The one
> work item where we felt that it was necessary to clarify this already
> has a statement to this effect.
> 
> So I'm not sure we need more statements for the part of the work that is
> in this charter. If the WG were to do something that is affecting hosts,
> they would already be doing something outside their charter.
> 
> However, we obviously need to figure out what to do with the other work
> items not yet in the charter. A critical part of figuring that out is a
> statement that specifies what to do or not do with the hosts.
> 
> Jari
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Wed, 15 Apr 2009 12:30:59 +0200
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Qin Wu escribi?:
> Hi, Maro ,George and all: 
> I tend to agree with Marco's point.
> No MN involvement means MN does not involve in network layer/IP layer moblity management.However it does not restrict MN to involve in out of band signaling. 
> On the other hand, no MN involvement does not mean no host change.  Host changes can be divided into changes in different levels,e.g., IP stack level change, application level change, etc. For some case without MN involvement, the host changes below or over the IP layer can be allowed. So I think we should be careful to interpret it if we include "no MN involvement" in the current charter.
>
>   

right
but once we accept that we can do changes in the MN (whcih was out of 
the scope for netlmm), then we need to open the discssion for what 
changes are better. On possible change is to include a MIP 
implementation in the node and there seems to be evidence that that 
approach works.

Regards, marcelo

> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Marco Liebsch" <marco.liebsch at nw.neclab.eu>
> To: "George Tsirtsis" <tsirtsis at googlemail.com>
> Cc: <netext at mail.mobileip.jp>; <iesg at ietf.org>
> Sent: Wednesday, April 15, 2009 5:18 PM
> Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions (netext)
>
>
>   
>> George,
>>
>> George Tsirtsis schrieb:
>>     
>>> Vijay,
>>>
>>> The "no-MN-involvement" clause was central to the NETLMM BOF becoming
>>> a WG. This is the reason PMIPv6 exists i.e., to provide a mobility
>>> management mechanism that unlike MIPv6, does not require MN
>>> involvement.
>>>
>>> The recent controversy is about adding further support for
>>> inter-technology handoffs and for multihoming, which some of us argue
>>> will definitely require MN involvement and thus, PMIPv6 should stay
>>> away from such features.
>>>
>>> If the no-MN-involvement clause is not included in the charter, then I
>>> would argue that we need to define exactly what kind of MN-involvement
>>> is acceptable. This is important because some people in this group
>>> think that only MN software is needed (e.g., virtual interfaces) but
>>> no protocols, others think that it is OK for the IETF to rely on link
>>> layer software to do their job, and others want to do it at the
>>> network layer, making PMIPv6 to directly compete with MIPv6.
>>>   
>>>       
>> I don't think this makes PMIPv6 compete with MIPv6. Unfortunately this
>> is the way some of us want to understand it. There is sufficient benefit 
>> in using
>> PMIPv6, even with some host changes. This includes no encapsulation on the
>> radio interface and use of a single IP address (prefix) beyond the scope 
>> of a
>> single access router. I think we can agree that, according to the 
>> original definition,
>> hosts are not involved in IP mobility management. I don't see the reason 
>> why not
>> permitting host involvement in some local functions such as multiple 
>> radio interface
>> setup and configuration of associated routes. Even signaling some 
>> indications towards
>> the network infrastructure about the mobile node's interest in using 
>> more than one interface
>> seems to be outside of what IP mobility management does. In particular, 
>> I don't see this
>> competes with host mobility..
>>
>> I think the "no host involvement" argument does not hold, in particular 
>> as it allows
>> to much degree of freedom in interpretation. I don't think any strict 
>> 'no host modification'
>> argument can avoid some out of band signaling, which is used in the end 
>> by the
>> infrastrucre to enforce a particular behvior in PMIPv6 operation. So, I 
>> think we should
>> rather converge on what level of mobile node extensions are acceptable.
>>
>> marco
>>
>>     
>>> All of these are "controversial" and the subject of much recent discussion.
>>> So, it is the *omission* of the no-MN-Involvement clause that will
>>> cause confusion, and its controversial, not its inclusion. The
>>> no-MN-involvement clause has been there from the beginning and it
>>> should only be removed conciously and for good reasons.
>>>
>>> Regards
>>> George
>>>
>>>
>>>
>>>
>>> On Wed, Apr 15, 2009 at 12:13 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
>>>   
>>>       
>>>> George,
>>>>
>>>> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>>>>
>>>> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>>>>
>>>> Vijay
>>>>
>>>>     
>>>>         
>>>>> -----Original Message-----
>>>>> From: netext-bounces at mail.mobileip.jp
>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>>>>> Sent: Tuesday, April 14, 2009 1:59 PM
>>>>> To: Jari Arkko
>>>>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>>>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>>>> Extensions (netext)
>>>>>
>>>>> Hi Jari et.al.,
>>>>>
>>>>> I think the work items listed reflect the current level of agreement
>>>>> on this work, but I would like to see the following limitation in the
>>>>> charter.
>>>>>
>>>>> I would suggest that a statement reaffirming the "no MN involvement"
>>>>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>>>>> Charter, and which is still the basis for the existence of PMIPv6, is
>>>>> still valid in this new WG, tasked with extending it.
>>>>>
>>>>> Just for people who do not remember, the NETLMM charter states (in
>>>>> multiple places) that:
>>>>> "  ...all features defined must work with unmodified IP nodes.
>>>>> Specifying any changes to mobile nodes is out of scope of the current
>>>>> charter".
>>>>>
>>>>> I suggest that the same clause is added in the NETEXT charter, at
>>>>> least in this version of the charter, and at least until the
>>>>> discussion about the more controversial work items (inter-technology
>>>>> handoffs and multihoming) concludes.
>>>>>
>>>>> Regards
>>>>> George
>>>>>
>>>>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>>>>> <iesg-secretary at ietf.org> wrote:
>>>>>       
>>>>>           
>>>>>> A new IETF working group has been proposed in the Internet
>>>>>>         
>>>>>>             
>>>>> Area.  The IESG
>>>>>       
>>>>>           
>>>>>> has not made any determination as yet.  The following draft
>>>>>>         
>>>>>>             
>>>>> charter was
>>>>>       
>>>>>           
>>>>>> submitted, and is provided for informational purposes only.
>>>>>>         
>>>>>>             
>>>>>  Please send
>>>>>       
>>>>>           
>>>>>> your comments to the IESG mailing list (iesg at ietf.org) by
>>>>>>         
>>>>>>             
>>>>> Tuesday, April
>>>>>       
>>>>>           
>>>>>> 21, 2009.
>>>>>>
>>>>>> Network-Based Mobility Extensions (netext)
>>>>>> -------------------------------------------------------------
>>>>>>
>>>>>> Last Modified: 2009-04-03
>>>>>>
>>>>>> 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. Hosts
>>>>>       
>>>>>           
>>>>>> are not affected, as they still send and receive their
>>>>>>         
>>>>>>             
>>>>> packets via the
>>>>>       
>>>>>           
>>>>>> MAG.
>>>>>>
>>>>>> 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, and is complementary to the initial LMA
>>>>>>         
>>>>>>             
>>>>> discovery work in the
>>>>>       
>>>>>           
>>>>>> NETLMM WG.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Milestones
>>>>>>
>>>>>> May 2009 WG chartered
>>>>>> July 2009 Initial WG draft on Bulk Refresh
>>>>>> 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 2009 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
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>       
>>>>>           
>>> _______________________________________________
>>> 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
>>
>>     
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>   

From: sunseawq at huawei.com (Qin Wu)
Date: Wed, 15 Apr 2009 17:55:05 +0800
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Maro ,George and all: 
I tend to agree with Marco's point.
No MN involvement means MN does not involve in network layer/IP layer moblity management.However it does not restrict MN to involve in out of band signaling. 
On the other hand, no MN involvement does not mean no host change.  Host changes can be divided into changes in different levels,e.g., IP stack level change, application level change, etc. For some case without MN involvement, the host changes below or over the IP layer can be allowed. So I think we should be careful to interpret it if we include "no MN involvement" in the current charter.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <marco.liebsch at nw.neclab.eu>
To: "George Tsirtsis" <tsirtsis at googlemail.com>
Cc: <netext at mail.mobileip.jp>; <iesg at ietf.org>
Sent: Wednesday, April 15, 2009 5:18 PM
Subject: Re: [Netext] WG Review: Network-Based Mobility Extensions (netext)

> George,
> 
> George Tsirtsis schrieb:
>> Vijay,
>>
>> The "no-MN-involvement" clause was central to the NETLMM BOF becoming
>> a WG. This is the reason PMIPv6 exists i.e., to provide a mobility
>> management mechanism that unlike MIPv6, does not require MN
>> involvement.
>>
>> The recent controversy is about adding further support for
>> inter-technology handoffs and for multihoming, which some of us argue
>> will definitely require MN involvement and thus, PMIPv6 should stay
>> away from such features.
>>
>> If the no-MN-involvement clause is not included in the charter, then I
>> would argue that we need to define exactly what kind of MN-involvement
>> is acceptable. This is important because some people in this group
>> think that only MN software is needed (e.g., virtual interfaces) but
>> no protocols, others think that it is OK for the IETF to rely on link
>> layer software to do their job, and others want to do it at the
>> network layer, making PMIPv6 to directly compete with MIPv6.
>>   
> I don't think this makes PMIPv6 compete with MIPv6. Unfortunately this
> is the way some of us want to understand it. There is sufficient benefit 
> in using
> PMIPv6, even with some host changes. This includes no encapsulation on the
> radio interface and use of a single IP address (prefix) beyond the scope 
> of a
> single access router. I think we can agree that, according to the 
> original definition,
> hosts are not involved in IP mobility management. I don't see the reason 
> why not
> permitting host involvement in some local functions such as multiple 
> radio interface
> setup and configuration of associated routes. Even signaling some 
> indications towards
> the network infrastructure about the mobile node's interest in using 
> more than one interface
> seems to be outside of what IP mobility management does. In particular, 
> I don't see this
> competes with host mobility..
> 
> I think the "no host involvement" argument does not hold, in particular 
> as it allows
> to much degree of freedom in interpretation. I don't think any strict 
> 'no host modification'
> argument can avoid some out of band signaling, which is used in the end 
> by the
> infrastrucre to enforce a particular behvior in PMIPv6 operation. So, I 
> think we should
> rather converge on what level of mobile node extensions are acceptable.
> 
> marco
> 
>> All of these are "controversial" and the subject of much recent discussion.
>> So, it is the *omission* of the no-MN-Involvement clause that will
>> cause confusion, and its controversial, not its inclusion. The
>> no-MN-involvement clause has been there from the beginning and it
>> should only be removed conciously and for good reasons.
>>
>> Regards
>> George
>>
>>
>>
>>
>> On Wed, Apr 15, 2009 at 12:13 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
>>   
>>> George,
>>>
>>> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>>>
>>> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>>>
>>> Vijay
>>>
>>>     
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp
>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>>>> Sent: Tuesday, April 14, 2009 1:59 PM
>>>> To: Jari Arkko
>>>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>>> Extensions (netext)
>>>>
>>>> Hi Jari et.al.,
>>>>
>>>> I think the work items listed reflect the current level of agreement
>>>> on this work, but I would like to see the following limitation in the
>>>> charter.
>>>>
>>>> I would suggest that a statement reaffirming the "no MN involvement"
>>>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>>>> Charter, and which is still the basis for the existence of PMIPv6, is
>>>> still valid in this new WG, tasked with extending it.
>>>>
>>>> Just for people who do not remember, the NETLMM charter states (in
>>>> multiple places) that:
>>>> "  ...all features defined must work with unmodified IP nodes.
>>>> Specifying any changes to mobile nodes is out of scope of the current
>>>> charter".
>>>>
>>>> I suggest that the same clause is added in the NETEXT charter, at
>>>> least in this version of the charter, and at least until the
>>>> discussion about the more controversial work items (inter-technology
>>>> handoffs and multihoming) concludes.
>>>>
>>>> Regards
>>>> George
>>>>
>>>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>>>> <iesg-secretary at ietf.org> wrote:
>>>>       
>>>>> A new IETF working group has been proposed in the Internet
>>>>>         
>>>> Area.  The IESG
>>>>       
>>>>> has not made any determination as yet.  The following draft
>>>>>         
>>>> charter was
>>>>       
>>>>> submitted, and is provided for informational purposes only.
>>>>>         
>>>>  Please send
>>>>       
>>>>> your comments to the IESG mailing list (iesg at ietf.org) by
>>>>>         
>>>> Tuesday, April
>>>>       
>>>>> 21, 2009.
>>>>>
>>>>> Network-Based Mobility Extensions (netext)
>>>>> -------------------------------------------------------------
>>>>>
>>>>> Last Modified: 2009-04-03
>>>>>
>>>>> 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. Hosts
>>>>       
>>>>> are not affected, as they still send and receive their
>>>>>         
>>>> packets via the
>>>>       
>>>>> MAG.
>>>>>
>>>>> 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, and is complementary to the initial LMA
>>>>>         
>>>> discovery work in the
>>>>       
>>>>> NETLMM WG.
>>>>>
>>>>> 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.
>>>>>
>>>>> Milestones
>>>>>
>>>>> May 2009 WG chartered
>>>>> July 2009 Initial WG draft on Bulk Refresh
>>>>> 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 2009 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
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>       
>>
>> _______________________________________________
>> 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
>

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 15 Apr 2009 11:18:18 +0200
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

George,

George Tsirtsis schrieb:
> Vijay,
>
> The "no-MN-involvement" clause was central to the NETLMM BOF becoming
> a WG. This is the reason PMIPv6 exists i.e., to provide a mobility
> management mechanism that unlike MIPv6, does not require MN
> involvement.
>
> The recent controversy is about adding further support for
> inter-technology handoffs and for multihoming, which some of us argue
> will definitely require MN involvement and thus, PMIPv6 should stay
> away from such features.
>
> If the no-MN-involvement clause is not included in the charter, then I
> would argue that we need to define exactly what kind of MN-involvement
> is acceptable. This is important because some people in this group
> think that only MN software is needed (e.g., virtual interfaces) but
> no protocols, others think that it is OK for the IETF to rely on link
> layer software to do their job, and others want to do it at the
> network layer, making PMIPv6 to directly compete with MIPv6.
>   
I don't think this makes PMIPv6 compete with MIPv6. Unfortunately this
is the way some of us want to understand it. There is sufficient benefit 
in using
PMIPv6, even with some host changes. This includes no encapsulation on the
radio interface and use of a single IP address (prefix) beyond the scope 
of a
single access router. I think we can agree that, according to the 
original definition,
hosts are not involved in IP mobility management. I don't see the reason 
why not
permitting host involvement in some local functions such as multiple 
radio interface
setup and configuration of associated routes. Even signaling some 
indications towards
the network infrastructure about the mobile node's interest in using 
more than one interface
seems to be outside of what IP mobility management does. In particular, 
I don't see this
competes with host mobility..

I think the "no host involvement" argument does not hold, in particular 
as it allows
to much degree of freedom in interpretation. I don't think any strict 
'no host modification'
argument can avoid some out of band signaling, which is used in the end 
by the
infrastrucre to enforce a particular behvior in PMIPv6 operation. So, I 
think we should
rather converge on what level of mobile node extensions are acceptable.

marco

> All of these are "controversial" and the subject of much recent discussion.
> So, it is the *omission* of the no-MN-Involvement clause that will
> cause confusion, and its controversial, not its inclusion. The
> no-MN-involvement clause has been there from the beginning and it
> should only be removed conciously and for good reasons.
>
> Regards
> George
>
>
>
>
> On Wed, Apr 15, 2009 at 12:13 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
>   
>> George,
>>
>> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>>
>> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>>
>> Vijay
>>
>>     
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>>> Sent: Tuesday, April 14, 2009 1:59 PM
>>> To: Jari Arkko
>>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>> Extensions (netext)
>>>
>>> Hi Jari et.al.,
>>>
>>> I think the work items listed reflect the current level of agreement
>>> on this work, but I would like to see the following limitation in the
>>> charter.
>>>
>>> I would suggest that a statement reaffirming the "no MN involvement"
>>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>>> Charter, and which is still the basis for the existence of PMIPv6, is
>>> still valid in this new WG, tasked with extending it.
>>>
>>> Just for people who do not remember, the NETLMM charter states (in
>>> multiple places) that:
>>> "  ...all features defined must work with unmodified IP nodes.
>>> Specifying any changes to mobile nodes is out of scope of the current
>>> charter".
>>>
>>> I suggest that the same clause is added in the NETEXT charter, at
>>> least in this version of the charter, and at least until the
>>> discussion about the more controversial work items (inter-technology
>>> handoffs and multihoming) concludes.
>>>
>>> Regards
>>> George
>>>
>>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>>> <iesg-secretary at ietf.org> wrote:
>>>       
>>>> A new IETF working group has been proposed in the Internet
>>>>         
>>> Area.  The IESG
>>>       
>>>> has not made any determination as yet.  The following draft
>>>>         
>>> charter was
>>>       
>>>> submitted, and is provided for informational purposes only.
>>>>         
>>>  Please send
>>>       
>>>> your comments to the IESG mailing list (iesg at ietf.org) by
>>>>         
>>> Tuesday, April
>>>       
>>>> 21, 2009.
>>>>
>>>> Network-Based Mobility Extensions (netext)
>>>> -------------------------------------------------------------
>>>>
>>>> Last Modified: 2009-04-03
>>>>
>>>> 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. Hosts
>>>       
>>>> are not affected, as they still send and receive their
>>>>         
>>> packets via the
>>>       
>>>> MAG.
>>>>
>>>> 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, and is complementary to the initial LMA
>>>>         
>>> discovery work in the
>>>       
>>>> NETLMM WG.
>>>>
>>>> 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.
>>>>
>>>> Milestones
>>>>
>>>> May 2009 WG chartered
>>>> July 2009 Initial WG draft on Bulk Refresh
>>>> 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 2009 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
>>>> _______________________________________________
>>>> 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
>>>
>>>       
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: jari.arkko at piuha.net (Jari Arkko)
Date: Wed, 15 Apr 2009 11:46:38 +0300
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

George, Vijay,

The three current work items do not affect hosts in any way. The one 
work item where we felt that it was necessary to clarify this already 
has a statement to this effect.

So I'm not sure we need more statements for the part of the work that is 
in this charter. If the WG were to do something that is affecting hosts, 
they would already be doing something outside their charter.

However, we obviously need to figure out what to do with the other work 
items not yet in the charter. A critical part of figuring that out is a 
statement that specifies what to do or not do with the hosts.

Jari

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Wed, 15 Apr 2009 09:32:48 +0100
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Vijay,

The "no-MN-involvement" clause was central to the NETLMM BOF becoming
a WG. This is the reason PMIPv6 exists i.e., to provide a mobility
management mechanism that unlike MIPv6, does not require MN
involvement.

The recent controversy is about adding further support for
inter-technology handoffs and for multihoming, which some of us argue
will definitely require MN involvement and thus, PMIPv6 should stay
away from such features.

If the no-MN-involvement clause is not included in the charter, then I
would argue that we need to define exactly what kind of MN-involvement
is acceptable. This is important because some people in this group
think that only MN software is needed (e.g., virtual interfaces) but
no protocols, others think that it is OK for the IETF to rely on link
layer software to do their job, and others want to do it at the
network layer, making PMIPv6 to directly compete with MIPv6.

All of these are "controversial" and the subject of much recent discussion.
So, it is the *omission* of the no-MN-Involvement clause that will
cause confusion, and its controversial, not its inclusion. The
no-MN-involvement clause has been there from the beginning and it
should only be removed conciously and for good reasons.

Regards
George

On Wed, Apr 15, 2009 at 12:13 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
> George,
>
> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>
> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>
> Vijay
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>> Sent: Tuesday, April 14, 2009 1:59 PM
>> To: Jari Arkko
>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>> Extensions (netext)
>>
>> Hi Jari et.al.,
>>
>> I think the work items listed reflect the current level of agreement
>> on this work, but I would like to see the following limitation in the
>> charter.
>>
>> I would suggest that a statement reaffirming the "no MN involvement"
>> clause, ?which features in 3 out of the 5 paragraphs of the NETLMM WG
>> Charter, and which is still the basis for the existence of PMIPv6, is
>> still valid in this new WG, tasked with extending it.
>>
>> Just for people who do not remember, the NETLMM charter states (in
>> multiple places) that:
>> " ?...all features defined must work with unmodified IP nodes.
>> Specifying any changes to mobile nodes is out of scope of the current
>> charter".
>>
>> I suggest that the same clause is added in the NETEXT charter, at
>> least in this version of the charter, and at least until the
>> discussion about the more controversial work items (inter-technology
>> handoffs and multihoming) concludes.
>>
>> Regards
>> George
>>
>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>> <iesg-secretary at ietf.org> wrote:
>> > A new IETF working group has been proposed in the Internet
>> Area. ?The IESG
>> > has not made any determination as yet. ?The following draft
>> charter was
>> > submitted, and is provided for informational purposes only.
>> ?Please send
>> > your comments to the IESG mailing list (iesg at ietf.org) by
>> Tuesday, April
>> > 21, 2009.
>> >
>> > Network-Based Mobility Extensions (netext)
>> > -------------------------------------------------------------
>> >
>> > Last Modified: 2009-04-03
>> >
>> > 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. Hosts
>> > are not affected, as they still send and receive their
>> packets via the
>> > MAG.
>> >
>> > 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, and is complementary to the initial LMA
>> discovery work in the
>> > NETLMM WG.
>> >
>> > 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.
>> >
>> > Milestones
>> >
>> > May 2009 WG chartered
>> > July 2009 Initial WG draft on Bulk Refresh
>> > 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 2009 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
>> > _______________________________________________
>> > 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
>>
>

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Wed, 15 Apr 2009 10:25:47 +0200
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

Vijay Devarapalli escribi?:
> George,
>
> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
>
> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
>
>   
I am not sure i understand your point
The items currently included in the charter do not require any kind of 
mobile node changes (by any definition you want to use of mobile node 
changes), is that correct?

If Netext decides to work on other items that do require modifications 
to the mobile nodes (in any definition) a recharter is needed. So, when 
this recharter is performed, you can change change the scope of the 
charter, in particular, you can remove the limitiations of no node changes.

I mean, as today, i understand the consensus is that the WG can be 
created with the scope of working in the items that imply no node changes.
I don't see any kind of consensus in the creation of a WG with a scope 
that can change MN.

So, i think George proposal does reflect the consensus so far.

Regards, marcelo

> Vijay
>
>   
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp 
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>> Sent: Tuesday, April 14, 2009 1:59 PM
>> To: Jari Arkko
>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>> Subject: Re: [Netext] WG Review: Network-Based Mobility 
>> Extensions (netext)
>>
>> Hi Jari et.al.,
>>
>> I think the work items listed reflect the current level of agreement
>> on this work, but I would like to see the following limitation in the
>> charter.
>>
>> I would suggest that a statement reaffirming the "no MN involvement"
>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>> Charter, and which is still the basis for the existence of PMIPv6, is
>> still valid in this new WG, tasked with extending it.
>>
>> Just for people who do not remember, the NETLMM charter states (in
>> multiple places) that:
>> "  ...all features defined must work with unmodified IP nodes.
>> Specifying any changes to mobile nodes is out of scope of the current
>> charter".
>>
>> I suggest that the same clause is added in the NETEXT charter, at
>> least in this version of the charter, and at least until the
>> discussion about the more controversial work items (inter-technology
>> handoffs and multihoming) concludes.
>>
>> Regards
>> George
>>
>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary 
>> <iesg-secretary at ietf.org> wrote:
>>     
>>> A new IETF working group has been proposed in the Internet 
>>>       
>> Area.  The IESG
>>     
>>> has not made any determination as yet.  The following draft 
>>>       
>> charter was
>>     
>>> submitted, and is provided for informational purposes only. 
>>>       
>>  Please send
>>     
>>> your comments to the IESG mailing list (iesg at ietf.org) by 
>>>       
>> Tuesday, April
>>     
>>> 21, 2009.
>>>
>>> Network-Based Mobility Extensions (netext)
>>> -------------------------------------------------------------
>>>
>>> Last Modified: 2009-04-03
>>>
>>> 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. Hosts
>>     
>>> are not affected, as they still send and receive their 
>>>       
>> packets via the
>>     
>>> MAG.
>>>
>>> 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, and is complementary to the initial LMA 
>>>       
>> discovery work in the
>>     
>>> NETLMM WG.
>>>
>>> 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.
>>>
>>> Milestones
>>>
>>> May 2009 WG chartered
>>> July 2009 Initial WG draft on Bulk Refresh
>>> 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 2009 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
>>> _______________________________________________
>>> 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
>>
>>     
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>   

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Wed, 15 Apr 2009 18:53:48 +1100
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Hi Vijay,
> 
> Vijay Devarapalli escribi?:
>> George,
>> 
>> The main issue I have noticed in the NetExt chartering discussion is on what
>> exactly is meant by "no MN involvement". Many folks see this as the mobile
>> node not being involved in mobility management. This has been most
>> controversial topic on the mailing list due to which some of the work items
>> for which there is maximum support are not being added to the charter right
>> now.
>> 
>> So how does it make sense to encode this in the charter right now? Lets
>> conclude on those discussions and figure out what to do on the multiple
>> interface support and handovers across interface with Proxy Mobile IPv6 and
>> then add the result to the charter.
>> 
>>   
> I am not sure i understand your point
> The items currently included in the charter do not require any kind of
> mobile node changes (by any definition you want to use of mobile node
> changes), is that correct?
> 
> If Netext decides to work on other items that do require modifications
> to the mobile nodes (in any definition) a recharter is needed. So, when
> this recharter is performed, you can change change the scope of the
> charter, in particular, you can remove the limitiations of no node changes.
> 
> I mean, as today, i understand the consensus is that the WG can be
> created with the scope of working in the items that imply no node changes.
> I don't see any kind of consensus in the creation of a WG with a scope
> that can change MN.
> 
> So, i think George proposal does reflect the consensus so far.

=> That's exactly right. That's why I also agree with George's request for
the additional text.

Hesham

> 
> Regards, marcelo
> 
> 
>> Vijay
>> 
>>   
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>>> Sent: Tuesday, April 14, 2009 1:59 PM
>>> To: Jari Arkko
>>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>>> Subject: Re: [Netext] WG Review: Network-Based Mobility
>>> Extensions (netext)
>>> 
>>> Hi Jari et.al.,
>>> 
>>> I think the work items listed reflect the current level of agreement
>>> on this work, but I would like to see the following limitation in the
>>> charter.
>>> 
>>> I would suggest that a statement reaffirming the "no MN involvement"
>>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>>> Charter, and which is still the basis for the existence of PMIPv6, is
>>> still valid in this new WG, tasked with extending it.
>>> 
>>> Just for people who do not remember, the NETLMM charter states (in
>>> multiple places) that:
>>> "  ...all features defined must work with unmodified IP nodes.
>>> Specifying any changes to mobile nodes is out of scope of the current
>>> charter".
>>> 
>>> I suggest that the same clause is added in the NETEXT charter, at
>>> least in this version of the charter, and at least until the
>>> discussion about the more controversial work items (inter-technology
>>> handoffs and multihoming) concludes.
>>> 
>>> Regards
>>> George
>>> 
>>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary
>>> <iesg-secretary at ietf.org> wrote:
>>>     
>>>> A new IETF working group has been proposed in the Internet
>>>>       
>>> Area.  The IESG
>>>     
>>>> has not made any determination as yet.  The following draft
>>>>       
>>> charter was
>>>     
>>>> submitted, and is provided for informational purposes only.
>>>>       
>>>  Please send
>>>     
>>>> your comments to the IESG mailing list (iesg at ietf.org) by
>>>>       
>>> Tuesday, April
>>>     
>>>> 21, 2009.
>>>> 
>>>> Network-Based Mobility Extensions (netext)
>>>> -------------------------------------------------------------
>>>> 
>>>> Last Modified: 2009-04-03
>>>> 
>>>> 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. Hosts
>>>     
>>>> are not affected, as they still send and receive their
>>>>       
>>> packets via the
>>>     
>>>> MAG.
>>>> 
>>>> 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, and is complementary to the initial LMA
>>>>       
>>> discovery work in the
>>>     
>>>> NETLMM WG.
>>>> 
>>>> 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.
>>>> 
>>>> Milestones
>>>> 
>>>> May 2009 WG chartered
>>>> July 2009 Initial WG draft on Bulk Refresh
>>>> 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 2009 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
>>>> _______________________________________________
>>>> 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
>>> 
>>>     
>> 
>> _______________________________________________
>> 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

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Wed, 15 Apr 2009 11:57:39 +0900
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi George, Vijay and all,

I tend to agree with Vijay's comment. I think the current charter was
created carefully enough for the majority of the people to agree upon.
Terminologies such as "no host involvement" or "unmodified IP node" have
not reached a good level of consensus yet even for their definitions, so
it would be too early to put them in the charter. PMIPv6 has been
adopted by multiple SDOs and I don't want to see that each SDO creates
its own way to support inter-technology handover and multihoming. I want
to see a common way that can be accepted by those SDOs and I want to see
that IETF is the central place to create necessary extensions and
guidelines. (do I sound too much ambitious?)

I believe the listed work items are less controversial and the milestone
can be achieved without a big problem. I would rather suggest that if
NETEXT is accepted as a WG, the prospective chair(s) should also spare
time to discuss other work items before it becomes too late...

Regards,
-- 
Hidetoshi

> George,
> 
> The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.
> 
> So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.
> 
> Vijay
> 
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp 
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
>> Sent: Tuesday, April 14, 2009 1:59 PM
>> To: Jari Arkko
>> Cc: netext at mail.mobileip.jp; iesg at ietf.org
>> Subject: Re: [Netext] WG Review: Network-Based Mobility 
>> Extensions (netext)
>>
>> Hi Jari et.al.,
>>
>> I think the work items listed reflect the current level of agreement
>> on this work, but I would like to see the following limitation in the
>> charter.
>>
>> I would suggest that a statement reaffirming the "no MN involvement"
>> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
>> Charter, and which is still the basis for the existence of PMIPv6, is
>> still valid in this new WG, tasked with extending it.
>>
>> Just for people who do not remember, the NETLMM charter states (in
>> multiple places) that:
>> "  ...all features defined must work with unmodified IP nodes.
>> Specifying any changes to mobile nodes is out of scope of the current
>> charter".
>>
>> I suggest that the same clause is added in the NETEXT charter, at
>> least in this version of the charter, and at least until the
>> discussion about the more controversial work items (inter-technology
>> handoffs and multihoming) concludes.
>>
>> Regards
>> George
>>
>> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary 
>> <iesg-secretary at ietf.org> wrote:
>>> A new IETF working group has been proposed in the Internet 
>> Area.  The IESG
>>> has not made any determination as yet.  The following draft 
>> charter was
>>> submitted, and is provided for informational purposes only. 
>>  Please send
>>> your comments to the IESG mailing list (iesg at ietf.org) by 
>> Tuesday, April
>>> 21, 2009.
>>>
>>> Network-Based Mobility Extensions (netext)
>>> -------------------------------------------------------------
>>>
>>> Last Modified: 2009-04-03
>>>
>>> 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. Hosts
>>> are not affected, as they still send and receive their 
>> packets via the
>>> MAG.
>>>
>>> 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, and is complementary to the initial LMA 
>> discovery work in the
>>> NETLMM WG.
>>>
>>> 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.
>>>
>>> Milestones
>>>
>>> May 2009 WG chartered
>>> July 2009 Initial WG draft on Bulk Refresh
>>> 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 2009 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
>>> _______________________________________________
>>> 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
>>
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 14 Apr 2009 19:13:04 -0400
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

George,

The main issue I have noticed in the NetExt chartering discussion is on what exactly is meant by "no MN involvement". Many folks see this as the mobile node not being involved in mobility management. This has been most controversial topic on the mailing list due to which some of the work items for which there is maximum support are not being added to the charter right now.

So how does it make sense to encode this in the charter right now? Lets conclude on those discussions and figure out what to do on the multiple interface support and handovers across interface with Proxy Mobile IPv6 and then add the result to the charter.

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis
> Sent: Tuesday, April 14, 2009 1:59 PM
> To: Jari Arkko
> Cc: netext at mail.mobileip.jp; iesg at ietf.org
> Subject: Re: [Netext] WG Review: Network-Based Mobility 
> Extensions (netext)
> 
> Hi Jari et.al.,
> 
> I think the work items listed reflect the current level of agreement
> on this work, but I would like to see the following limitation in the
> charter.
> 
> I would suggest that a statement reaffirming the "no MN involvement"
> clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
> Charter, and which is still the basis for the existence of PMIPv6, is
> still valid in this new WG, tasked with extending it.
> 
> Just for people who do not remember, the NETLMM charter states (in
> multiple places) that:
> "  ...all features defined must work with unmodified IP nodes.
> Specifying any changes to mobile nodes is out of scope of the current
> charter".
> 
> I suggest that the same clause is added in the NETEXT charter, at
> least in this version of the charter, and at least until the
> discussion about the more controversial work items (inter-technology
> handoffs and multihoming) concludes.
> 
> Regards
> George
> 
> On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary 
> <iesg-secretary at ietf.org> wrote:
> > A new IETF working group has been proposed in the Internet 
> Area. ?The IESG
> > has not made any determination as yet. ?The following draft 
> charter was
> > submitted, and is provided for informational purposes only. 
> ?Please send
> > your comments to the IESG mailing list (iesg at ietf.org) by 
> Tuesday, April
> > 21, 2009.
> >
> > Network-Based Mobility Extensions (netext)
> > -------------------------------------------------------------
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts
> > are not affected, as they still send and receive their 
> packets via the
> > MAG.
> >
> > 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, and is complementary to the initial LMA 
> discovery work in the
> > NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009 WG chartered
> > July 2009 Initial WG draft on Bulk Refresh
> > 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 2009 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
> > _______________________________________________
> > 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
> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Tue, 14 Apr 2009 21:59:21 +0100
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari et.al.,

I think the work items listed reflect the current level of agreement
on this work, but I would like to see the following limitation in the
charter.

I would suggest that a statement reaffirming the "no MN involvement"
clause,  which features in 3 out of the 5 paragraphs of the NETLMM WG
Charter, and which is still the basis for the existence of PMIPv6, is
still valid in this new WG, tasked with extending it.

Just for people who do not remember, the NETLMM charter states (in
multiple places) that:
"  ...all features defined must work with unmodified IP nodes.
Specifying any changes to mobile nodes is out of scope of the current
charter".

I suggest that the same clause is added in the NETEXT charter, at
least in this version of the charter, and at least until the
discussion about the more controversial work items (inter-technology
handoffs and multihoming) concludes.

Regards
George

On Tue, Apr 14, 2009 at 9:00 PM, IESG Secretary <iesg-secretary at ietf.org> wrote:
> A new IETF working group has been proposed in the Internet Area. ?The IESG
> has not made any determination as yet. ?The following draft charter was
> submitted, and is provided for informational purposes only. ?Please send
> your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, April
> 21, 2009.
>
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
>
> Last Modified: 2009-04-03
>
> 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. Hosts
> are not affected, as they still send and receive their packets via the
> MAG.
>
> 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, and is complementary to the initial LMA discovery work in the
> NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> 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 2009 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
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: iesg-secretary at ietf.org (IESG Secretary)
Date: Tue, 14 Apr 2009 13:00:02 -0700 (PDT)
Subject: [Netext] WG Review: Network-Based Mobility Extensions (netext)
Message-ID: <[email-masked]>

A new IETF working group has been proposed in the Internet Area.  The IESG
has not made any determination as yet.  The following draft charter was
submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, April
21, 2009.

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

Last Modified: 2009-04-03

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. Hosts
are not affected, as they still send and receive their packets via the
MAG.

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, and is complementary to the initial LMA discovery work in the
NETLMM WG.

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.

Milestones

May 2009 WG chartered
July 2009 Initial WG draft on Bulk Refresh
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 2009 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: teemu.savolainen at nokia.com (teemu.savolainen at nokia.com)
Date: Tue, 14 Apr 2009 18:18:48 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri, all,

>-----Original Message-----
>From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
>Sent: 10 April, 2009 07:27
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>
>I agree with your description, it places certain "assumptions" 
>on the host. In most OS's, it might be about running a tool to 
>enable a specific configuration, in some cases there might be 
>a new application required. I did not want this to imply "host 
>change", that is most cases implies change to certain IETF 
>specifications or protocols, atleast in the context of IETF discussion.

There are many OS'es, some of which are proprietary and/or used in embedded and/or strongly controlled devices - in such cases it may not be possible just to run a tool or just install application to do the trick even if the device is based on open OS (and especially not by the end users of those systems). These kinds of devices are pretty common in some environments where PMIP6 is planned to be used.. Support for PMIP6 based inter-access handovers would definitely be considered as a change that would need to be justified, implemented, and verified.

In the context of IETF - and wider - discussion, I have been concerned about the message I often hear: that PMIP6 would not require host changes for inter-access mobility. The problem is that some actually read that message literally.

In http://tools.ietf.org/html/draft-premec-netlmm-intertech-handover-01 we describe at least some of the impacts (with also solution considerations & proposals):
- multihoming & handoffs (when the address should be moved from one access to another, when to ask for different address for different access, when to have same address on multiple accesses simultanously and also have mechahisms for flow distribution)
- overlapping IPv4 address spaces (how to know if 192.168.0.1 on two interfaces is logically the same or different address)
- different MTUs
- zero physical interface situation (i.e. the transition period when old access goes away and before the new access comes available)

>From my perspective the L2 changes are not very feasible approach: existing L2s would need to be changed (=very difficult to get done), and future L2 developers would also need to take care of this dependency. It is easier to handle mobility for IP at L3. 

Some people have been concerned on interoperability, but I don't think that is an issue: the hosts that would not implement suggested host changes (virtual interfaces, possibly required L3 signaling for advanced handoff scenarios) would work just as they do if they don't support client mobile IP either - they simply do not get seamless inter-technology handovers, but will need to manage with application level reconnection/multihoming techniques.

Best regards,

	Teemu

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 13 Apr 2009 12:22:40 +0300
Subject: [Netext] charter in public review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

FYI. The IESG has approved the charter for public review, and the mail 
about that should come out any moment now. This is the small charter, 
i.e., with the non-controversial topics from the BOF. My rationale for 
getting this moving forward was to ensure that we get work stated as 
soon as there's an agreement for a particular part.

The discussion on the rest obviously needs to continue; if and when the 
small charter gets approved, the discussion on the rest can happen in 
parallel, and a recharter for wider scope is possible at any time. For 
instance, in this case I will not ask you to complete the current 
charter before taking on other things.

Jari

From: sunseawq at huawei.com (Qin Wu)
Date: Mon, 13 Apr 2009 15:43:56 +0800
Subject: [Netext] next steps for netext
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Hesham and Marco:
Please see the comments inline!
-Qin
>  Not the problem of
>> existing solutions for localized mobility, as RFC4830 does. I don't
>> think NetExt
>> aims at turning PMIPv6 into a host-based mobility protocol again.
> 
> => I don't know what the goal is based on the BoF discussion and this
> discussion on the list. The reason I don't know that is that no one is
> saying:
> Here is the state of the art (including BOTH MIP and PMIP) and here is why
> they don't work, therefore we need to do something new.
> That's what a PS should say. What's being said here is "PMIP doesn't support
> advanced cases therefore we need something new", which is completely bogus
> because PMIP was not designed to support those cases because we already have
> something else for supporting those cases. Hence my reference to 4830...
> 
> I'm going to retire from the discussion till someone makes the argument
> above. Because I feel that if there is no such argument then the discussion
> is not a good use of time.
[Qin]=>
The scope and requirement of localized routing is very clear to me in the new charter. The motivation is to enrich the basic proxy mobile
IPv6 service with some additional feature and enable wide deployment and scalability.
The state of the art should refer to the section 6.10.3 of "local routing" in the RFC5213. Actually the concept of local routing has already be widely utilized in the
real practice, e.g., in the 3G cell network. Of cource this concept also works for the proxy mobile IPv6. That is what RFC5213 specifies in the section 6.10.3. However it has its limitation on the scenario, it restricts to be used in the intra-MAG mobility scenario. To enlarge the scalabilty of local routing(e.g., inter-MAG mobility or intra-LMA mobility, inter-LMA mobility), the PS document is developed to tackle this issues.

On the other hand, leaving the local routing issue aside, there are quite a lot of works on routing optimization in the netlmm working group. However they have the same difficulty, i.e., not applicable for inter-domain mobility. That's why local routing should fous on intra-domain mobility. So local routing can be viewed as  optimized pmip6-based approaches for the intra-domain moblity. The existing works includes:
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00. 
> http://tools.ietf.org/html/draft-qin-netlmm-pmipro-00
As regarding the last draft, we have updated it into new draft and posted to the IETF repository. The URL for this internet draft is:
http://tools.ietf.org/html/draft-wu-netext-local-ro-00
With this existing works, it can better the PS document for local routing and has a clear understanding what the PS document want to solve.
>
>> 
>> 
>>> Hesham
>>> 
>>> 
>>> and obviously also according to RFC4831. We should
>>>   
>>>> distinguish modification for mobility management, which is not what we
>>>> want to do,
>>>> and enabling local functions, such as the use of multiple interfaces,
>>>> where you have
>>>> to add routes, configure interfaces etc. to enable the use case.
>>>> 
>>>> marco
>>>>  
>>>> 
>>>> Hesham Soliman schrieb:
>>>>     
>>>>>   
>>>>>       
>>>>>>> => I think you're distinguishing between modified and unmodified based on
>>>>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>>>>> for
>>>>>>> those that did not attend the BoF, our conclusions were that you will
>>>>>>> either
>>>>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling
>>>>>>> on
>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>>> My opinion, and at least half the room's was that this is not a good way
>>>>>>> to
>>>>>>>       
>>>>>>>           
>>>>>> We can discuss what implies host changes and why this is such a big deal
>>>>>> anyway. But I don't think that half the room was in agreement as such. At
>>>>>> least from the count of hands raised for the question about whether we
>>>>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>>>>> favor). 
>>>>>>     
>>>>>>         
>>>>> => I think the question changed a few times :) The final question (which
>>>>> was
>>>>> specific to whether people wanted to work with this or not) showed a split
>>>>> room. 
>>>>> The host changes are not a big deal but they are mentioned here because
>>>>> they
>>>>> were one of the very few reasons for using NETLMM in the first place: Host
>>>>> changes (adding new SW to the host) and signalling from the MN. You can see
>>>>> them in section 4 of RFC 4830.
>>>>> 
>>>>>   
>>>>>       
>>>>>>> go and that it's better to stick with MIP instead of relying on a
>>>>>>> solution
>>>>>>> that will:
>>>>>>> - work on some L2s and not others,
>>>>>>>       
>>>>>>>           
>>>>>> We have no ability to specify changes to L2 anyway. However if some L2s do
>>>>>> have such capability, why would we not specify how multihoming would work
>>>>>> in
>>>>>> such scenarios.
>>>>>>     
>>>>>>         
>>>>> => Because we already have a solution that works in all L2s, doesn't
>>>>> require
>>>>> L2 changes that we don't control and doesn't cause confusing host config
>>>>> solutions. 
>>>>> 
>>>>>   
>>>>>       
>>>>>>> - Require additional SW and config on the host which is not done anywhere
>>>>>>> today, and
>>>>>>>       
>>>>>>>           
>>>>>> Why is there as much of a concern about additional SW or config? After all
>>>>>> everything (or most of it anyway) that we do in the IETF requires
>>>>>> configurations, protocol changes, changes to SW etc. There is nothing
>>>>>> unique
>>>>>> about this. 
>>>>>>     
>>>>>>         
>>>>> => Sure, but see above and see RFC 4830. These were the reasons for using
>>>>> PMIP in the first place. We can't have it both ways, or can we? :)
>>>>> 
>>>>>   
>>>>>       
>>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>>       
>>>>>>>           
>>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>>> (informatively)
>>>>>> what L2 capabilities would enable these features if that is the conclusion
>>>>>> that we arrive at.
>>>>>>     
>>>>>>         
>>>>> => We can, but I don't know why we should do that when a solution already
>>>>> exists. Especially when the alternative is inferior in terms of its
>>>>> applicability.
>>>>> 
>>>>> Hesham
>>>>> 
>>>>>   
>>>>>       
>>>>>> -Raj
>>>>>> 
>>>>>>     
>>>>>>         
>>>>>>> This is why I think we should stick with the charter that Jari sent.
>>>>>>> 
>>>>>>> 
>>>>>>> Hesham
>>>>>>> 
>>>>>>>       
>>>>>>>           
>>>>>>>> I share the same view with respect to all your other comments. We need
>>>>>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>>>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>>>>>> handoff cases supported today in 5213.
>>>>>>>> 
>>>>>>>> Sri
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>   
>>>>>       
>>>>     
>>> 
>>> 
>>>   
>> 
>> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: sunseawq at huawei.com (Qin Wu)
Date: Mon, 13 Apr 2009 15:09:27 +0800
Subject: [Netext] charter comments
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Jari, Koodli and all:
Please see the comments in line.

-Qin
>> >  Deployment Considerations:
>> >
>> >    o Localized Routing: a specification for constraining routing to
>> >    the MAG(s) without involving the LMA within a single PMIPv6
>> >    domain (PS)
>> >   
>> 
>> Again, there is limited functionality in RFC 5213, within a 
>> single MAG.
> 
> There is no protocol specification on how to do this. It defines a flag,
> which if set, can have localized routing.

[Qin]: The basic idea is local routing. Actually local routing has been widely used in the switches in practice. These concept also works for basic
proxy mobile IPv6. Although it is limited to be utilized in one MAG, it is definited to optimize the path between the MN and CN who attaches to the same MAG and does not need to tunnel the data traffic to the LMA and back again.
>> 
>> State the intended optimization model in more detail. Packets 
>> can flow directly between the MAGs, guided by some policy 
>> that enables this functionality on a per host/per flow basis?
>> 
> 
> In the PS document. Perhaps we will reference the PS docs against the
> items.

[Qin] Since there is some existing work in RFC5213, I support we should take section 6.10.3 of RFC5213 "Local routing"as a reference.
In this sense, the PS document should be based on RFC5213 and overcome the limitation of "local routing" described in RFC5213 and enhance broad use of
local routing.

>> >    o Bulk Refresh: specification of improving the signaling load for
>> >    binding lifetime refresh (PS)
>> >
>> >  Deficiencies:
>> >
>> >    o MN involvement: documentation of scenarios where MN involvement
>> >    may be seen as beneficial (Informational)
>> >   
>> 
>> How is this related to the other work items?
> 
> We probably don't want to take this up now to focus on the other topics.
> 
>> 
>> > The BoF proposes to discuss the above items and gauge interest in 
>> > forming a working Group. There is already work in progress 
>> addressing 
>> > the identified problems, which is expected to be the starting point 
>> > for the deliverables.
>> >
>> > The proposed activity will be complementary to the existing IETF 
>> > Working Groups, notably the NETLMM and MEXT WGs.
>> >
>> > Approximate Timeline for Deliverables:
>> > -------------------------------------
>> >
>> > March 2009  WG approved by IESG
>> >   
>> April by the earliest, March is over when IETF-74 is over...
>> 
>> > 2Q09         Problem statements for multihoming, 
>> localized routing
>> >        and inter-access HO agreed upon in the WG
>> > 2H09           Submit Inter-access Tech Handover, Localized Routing
>> >                and Multihoming I-Ds to IESG  
>> > 4Q09           Submit the I-D on MN Involvement to IESG 
>> > 1Q10           Submit Bulk Refresh I-D to IESG 
>> > 2H10           Recharter or close WG
>> >   
>> I would suggest breaking up WG document adoption and sending 
>> to the IESG separately. Are the problem statements sent to 
>> the IESG at all? Are the documents in the second step problem 
>> statements or solutions? If the latter, its too aggressive schedule.
> 
> Okay, we will think over the schedule again (this is from last
> November).
> 
> Thanks,
> 
> -Rajeev
> 
> 
>> 
>> Jari
>> 
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>> 
> 
> 
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Sat, 11 Apr 2009 22:40:56 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julien,

On 2009/04/11, at 13:40, Julien Laganier wrote:

> Hello Sri,
>
> On Thu, Apr 9, 2009 at 12:07 AM, Sri Gundavelli <sgundave at cisco.com>  
> wrote:
>>
>> [...]
>>
>>>> So, its possible for the MAG to derive that information from the
>>>> network, in many cases, including in 3GPP, as Vijay pointed out
>>>> for single attach.
>>>
>>> This is done by a special L2 message introduced for that - i.e. a  
>>> change
>>> of the host (which is not visible to IETF as it is done at L2 and  
>>> not L3,
>>> but still very real)
>>
>> We can indeed define a L2 message, allow the network to make that
>> decision, or allow it to push policy templates to the terminal.
>>
>> In any case, changes to host, in the form of application requirement
>> or connection manager requirement, or any application layer policy
>> push, does not break IETF standards. If some operator wants to  
>> install
>> such application on the terminal, I wonder why we should have a  
>> problem.
>> Also, IMO, we are dreaming, if we assume that any operator will  
>> qualify
>> any host on their network, with out zero software addition. Looking
>> at EV-DO deployments today, all operators ship connection manager
>> software.
>
> I don't know about EV-DO -- But for sure I wasn't dreaming the many
> times I accessed an HSPA network with my off-the-shelf Linux laptop
> (i.e. _with_ zero software addition.)

Docomo has a connection manager for HSDPA data connection for MAC and  
WIN in Japan!!!!
In addition, user is advised to use this software to connect DoCoMo's  
WiFi network...

http://www.nttdocomo.co.jp/english/service/data/foma/index.html

Not so many people use UNIX laptop these days.
Are you saying the linux is reference implementation for PMIP  
discussion?

regards,
ryuji

regards,
ryuji

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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Sat, 11 Apr 2009 17:02:06 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>  <[email-masked]>  <[email-masked]>  <[email-masked]>  <[email-masked]>  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julien,

On Sat, 11 Apr 2009, Julien Laganier wrote:

> Hello Sri,
>
> On Thu, Apr 9, 2009 at 12:07 AM, Sri Gundavelli <sgundave at cisco.com> wrote:
>>
>> [...]
>>
>>>> So, its possible for the MAG to derive that information from the
>>>> network, in many cases, including in 3GPP, as Vijay pointed out
>>>> for single attach.
>>>
>>> This is done by a special L2 message introduced for that - i.e. a change
>>> of the host (which is not visible to IETF as it is done at L2 and not L3,
>>> but still very real)
>>
>> We can indeed define a L2 message, allow the network to make that
>> decision, or allow it to push policy templates to the terminal.
>>
>> In any case, changes to host, in the form of application requirement
>> or connection manager requirement, or any application layer policy
>> push, does not break IETF standards. If some operator wants to install
>> such application on the terminal, I wonder why we should have a problem.
>> Also, IMO, we are dreaming, if we assume that any operator will qualify
>> any host on their network, with out zero software addition. Looking
>> at EV-DO deployments today, all operators ship connection manager
>> software.
>
> I don't know about EV-DO -- But for sure I wasn't dreaming the many
> times I accessed an HSPA network with my off-the-shelf Linux laptop
> (i.e. _with_ zero software addition.)
>

Sure, the off-the-shelf node can certainly connect to the network over
HSPA. But in the presence of multiple access networks, say WiFI & HSPA,
wonder if it has the intelligence to decide for you which networks it
should use, with or without client mobile IP. If yes, beyond the
driver for the 3g card, there has to be some software (connection mgr)
which has the access preferences. I'm not sure, how that module can be
eliminated.

Regards
Sri

From: julien.laganier.ietf at googlemail.com (Julien Laganier)
Date: Sat, 11 Apr 2009 19:40:37 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Sri,

On Thu, Apr 9, 2009 at 12:07 AM, Sri Gundavelli <sgundave at cisco.com> wrote:
>
> [...]
>
>>> So, its possible for the MAG to derive that information from the
>>> network, in many cases, including in 3GPP, as Vijay pointed out
>>> for single attach.
>>
>> This is done by a special L2 message introduced for that - i.e. a change
>> of the host (which is not visible to IETF as it is done at L2 and not L3,
>> but still very real)
>
> We can indeed define a L2 message, allow the network to make that
> decision, or allow it to push policy templates to the terminal.
>
> In any case, changes to host, in the form of application requirement
> or connection manager requirement, or any application layer policy
> push, does not break IETF standards. If some operator wants to install
> such application on the terminal, I wonder why we should have a problem.
> Also, IMO, we are dreaming, if we assume that any operator will qualify
> any host on their network, with out zero software addition. Looking
> at EV-DO deployments today, all operators ship connection manager
> software.

I don't know about EV-DO -- But for sure I wasn't dreaming the many
times I accessed an HSPA network with my off-the-shelf Linux laptop
(i.e. _with_ zero software addition.)

--julien

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 10 Apr 2009 09:09:03 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

On Fri, 10 Apr 2009, Domagoj Premec wrote:

> Sri,
>
> I think that as part of the netext work we should have a thorough look at
> the "certain advanced handoff operations" and specify exactly how this is
> supposed to work. Leaving this to be solved outside of the IETF is
> suboptimal... RFC 5213 is an IETF standard and we should take care that it
> works well under all scenarios without any unspecified assumption or
> undocumented restrictions.
>

I agree with you. The features that are supported in 5213, obviously
the mobile needs to be able to make use of it, some of the work I
proposed also aligns with this. RFC 5213's focus was on the network
side, we need ot be able to cover all the aspects.

Regards
Sri

> domagoj
>
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 10. travanj 2009 06:42
>> To: Domagoj Premec
>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>> Subject: RE: [Netext] next steps for netext
>>
>> Hi Domagoj,
>>
>>
>> On Thu, 9 Apr 2009, Domagoj Premec wrote:
>>
>>> Sri,
>>>
>>>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>>
>>> I still fail to see how the inter-tech handover works if you don't
>>> assume a constrained enviroment where only attachment
>> through a single
>>> access at a time is allowed. What you say above is a generic
>>> statement, but it does not hold for the generic deployment case.
>>>
>>
>> The specification provides all the required hooks on the network side.
>> There are proper protocol semantics for achieving this.
>> However, on the terminal side, sure, for certain advanced
>> handoff operations, the terminal and the network need to be
>> in sync. If that is through a MN-AR interface, L2, L3 or AAA
>> , is a solution detail.
>>
>>
>> Sri
>>
>>
>>
>>> domagoj
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>> Sent: 09. travanj 2009 00:12
>>>> To: Domagoj Premec
>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>> Subject: RE: [Netext] next steps for netext
>>>>
>>>> Hi Domagoj,
>>>>
>>>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>>>
>>>> For other scenarios of multi-attach, there can be policies on the
>>>> network and the terminal, or a L2 signaling as you prefer, or an
>>>> application signaling ..., but sure, there may be a need for the
>>>> coordination between the terminal and the network. But, we cannot
>>>> equate this requirement with the client-mobility requirement, with
>>>> the mobile involved in signaling.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>
>>>>> Sri,
>>>>>
>>>>> What you're discribing is a specific type of deployment
>>>> where the MN
>>>>> is allowed to attach only through a single access at a
>>>> time. But this
>>>>> prevents multihoming and is not a generic solution. We need
>>>> a generic
>>>>> solution that works with any type of deployment without
>>>> artifical restrictions.
>>>>>
>>>>> domagoj
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>>>> Sent: 08. travanj 2009 23:47
>>>>>> To: Domagoj Premec
>>>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>>>> Subject: RE: [Netext] next steps for netext
>>>>>>
>>>>>> Domagoj,
>>>>>>
>>>>>>
>>>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>>>
>>>>>>> Sri,
>>>>>>>
>>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>>
>>>>>>> I disagree with this statement. In case of inter-tech
>>>> handover, the
>>>>>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>>>>>> Handoff between two different interfaces of the mobile
>>>>>> node". How does
>>>>>>> the new MAG know that the attachment should be treated as a
>>>>>> handover
>>>>>>> and not as a new session? In the absence of any other
>>>>>> indications, the
>>>>>>> MAG will treat this as a new attachment, which results in
>>>>>> multihoming
>>>>>>> with a different prefix and no handover.
>>>>>>>
>>>>>>
>>>>>> Can a deployment have terminals that only do single attach.
>>>>>> Can that information be tied to the mobile's policy profile.
>>>>>> Is it possible such information is available to the MAG ?
>>>>>>
>>>>>> Can AAA or other session manager have the awareness of
>> the current
>>>>>> existing session. Can the MAG leverage such information
>>>> and derive if
>>>>>> its a handover or a new attach ?
>>>>>>
>>>>>> So, its possible for the MAG to derive that information from the
>>>>>> network, in many cases, including in 3GPP, as Vijay
>>>> pointed out for
>>>>>> single attach.
>>>>>>
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> domagoj
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>>>>>> Gundavelli
>>>>>>>> Sent: 08. travanj 2009 21:51
>>>>>>>> To: Basavaraj.Patil at nokia.com
>>>>>>>> Cc: netext at mail.mobileip.jp
>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>
>>>>>>>> I agree, this discussion is going on a different track.
>>>> This wont
>>>>>>>> converge. Secondly, we are bundling every thing together
>>>>>> and making
>>>>>>>> blanket statements. There are statements,
>>>>>> multi-homing/handover does
>>>>>>>> not work in PMIPv6, or that there needs to be an L2
>> interface ..
>>>>>>>> there seems to be lot of assumptions around this, with out
>>>>>> qualifying
>>>>>>>> that, these statements are only creating confusion. Couple
>>>>>> of points:
>>>>>>>>
>>>>>>>> - Multihoming is supported in PMIPv6
>>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>>> - None of these features break or burn the host.
>>>>>>>>
>>>>>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>>>> some one
>>>>>>>> from building an IPv6 enterprise mobility solution based
>>>> on Proxy
>>>>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but
>>>> a protocol
>>>>>>>> that can be deployed in enterprise wireless architectures.
>>>>>> No one can
>>>>>>>> tell me, we cant deploy this protocol for solving
>> micro mobility
>>>>>>>> problems in an integrated wired/wireless AP environments,
>>>>>> targetted
>>>>>>>> for an enterprise.
>>>>>>>>
>>>>>>>>> From the list of proposed items, I'd really hope to
>>>> identify the
>>>>>>>>> work
>>>>>>>> items that does not require extesive debates from the
>> ones that
>>>>>>>> requires fist-fighting.
>>>>>>>>
>>>>>>>> - Flow mobility has the scope from moving individual flows of
>>>>>>>> interest with no relation to prefix, vs moving flows
>> as a bundle
>>>>>>>> associated to a prefix.
>>>>>>>>
>>>>>>>> - Host specific doc, from the point of view of leveraging
>>>>>> what 5213
>>>>>>>> supports, vs, for supporting the new features.
>>>>>>>>
>>>>>>>> - Multi-homing, binding a single prefix to multiple
>>>>>> interfaces, vs,
>>>>>>>> an individual prefix to each interface.
>>>>>>>>
>>>>>>>>
>>>>>>>> We have to qualify the discussions around this, just the
>>>>>> use of the
>>>>>>>> key words multi-homing, inter-tech handovers, flow
>> mobility, and
>>>>>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>>>>>> concern and does not help the discussions. We have to
>>>> state which
>>>>>>>> specific item has issues and under what scenario's.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Sri
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Lets try and keep this discussion focused on technical issues.
>>>>>>>>> The current tone is not very encouraging in some instances.
>>>>>>>>>
>>>>>>>>> The current discussion is overly focused on what 3GPP is
>>>>>>>> doing w.r.t
>>>>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>>>>>> protocols when
>>>>>>>>> they see a good fit for their architecture and problem
>>>> scope. We
>>>>>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>>>>>> instead rely on the IETF to deliver it.
>>>>>>>>> They are free to do whatever they want.
>>>>>>>>>
>>>>>>>>> Within the IETF we can identify what problems or extensions
>>>>>>>> to PMIP6
>>>>>>>>> we want to work on and focus on these. If 3GPP finds
>>>> the solution
>>>>>>>>> applicable, they will use it. The IETF solution has to
>>>>>> address the
>>>>>>>>> generic problem and not tailored for 3GPP (which is what we
>>>>>>>> seem to be doing now).
>>>>>>>>> So maybe we can get down to discussing the problem and
>>>>>>>> scenarios that
>>>>>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>>>>>
>>>>>>>>> In order to make progress, I would suggest that we
>> focus on the
>>>>>>>>> following 3
>>>>>>>>> topics:
>>>>>>>>> A. Multihoming
>>>>>>>>> B. Flow mobility
>>>>>>>>> C. Inter technology handovers
>>>>>>>>>
>>>>>>>>> If we can articulate the scenarios and associated problems
>>>>>>>> with each
>>>>>>>>> of the same, we can then get a better handle on what to
>>>>>> take on in
>>>>>>>>> Netext. And lets not start saying that we already have a
>>>>>>>> solution in I-Dx or I-Dy.
>>>>>>>>>
>>>>>>>>> -Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>>>>>> <vijay at wichorus.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi George,
>>>>>>>>>>
>>>>>>>>>> George Tsirtsis wrote:
>>>>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>>>>>> <vijay at wichorus.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Gerardo,
>>>>>>>>>>>>
>>>>>>>>>>>>> 3GPP has a study item on this feature. There was
>> no PMIPv6
>>>>>>>>>>>>> solutions proposed on any I-D - there is a
>>>>>>>> 3GPP-specific solution
>>>>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>>>>>
>>>>>>>>>>>> This is exactly what I would like to avoid. I would
>>>>>>>> prefer using a
>>>>>>>>>>>> solution developed in the IETF rather than
>> something in 3GPP.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>>>>>> technology for
>>>>>>>>>>> almost as long as the IETF. Getting the IETF to do
>>>>>> something only
>>>>>>>>>>> makes sense if the given protocol has general
>>>>>>>> applicability and does
>>>>>>>>>>> not damage the Internet, which is why we are having this
>>>>>>>> discussion.
>>>>>>>>>>
>>>>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>>>>>> very little
>>>>>>>>>> modifications. They have added some vendor specific
>>>> options for
>>>>>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>>>>>> PMIPv6, it
>>>>>>>>>> doesn't make sense for them to develop a solution on their
>>>>>>>> own. It should be done in the IETF.
>>>>>>>>>>
>>>>>>>>>> And can we please stop the hyperbole about "damaging the
>>>>>>>> Internet"?
>>>>>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>>>>>
>>>>>>>>>>> GT> In another e-mail where you are over-viewing a
>>>>>>>> possible solution
>>>>>>>>>>> to PMIP multihoming you talk about how the MN may use
>>>> an L2 to
>>>>>>>>>>> signal to indicate what flows need to go to a given
>>>>>> MAG. I do not
>>>>>>>>>>> see how the IETF can define a protocol that fully depends
>>>>>>>> on such an
>>>>>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>>>>>> must define
>>>>>>>>>>> it at the IP layer to make sure that this works
>>>> across ALL link
>>>>>>>>>>> layers (which is the main reason the IETF and the
>>>>>> Internet exist).
>>>>>>>>>>
>>>>>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>>>>>> So I don't
>>>>>>>>>> see it as a big issue. You don't need a MN-MAG IP
>> protocol for
>>>>>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>>>>>
>>>>>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>>>>>> does not
>>>>>>>>>> indicate the service identifier. Please see
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>>>>>
>>>>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>>>>>> hurdles to overcome:
>>>>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>>>>>> to define
>>>>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>>>>>
>>>>>>>>>> That is one option, but not required.
>>>>>>>>>>
>>>>>>>>>> Vijay
>>>>>>>>>>
>>>>>>>>>>> 2) Convince people that defining such a client based
>>>>>> protocol in
>>>>>>>>>>> addition to the existing standard (MIPv6) is
>>>> warranted. In the
>>>>>>>>>>> process, explain to people why you want to introduce FA
>>>>>>>>>>> functionality to MIPv6, which is what MAGs become if
>>>> you add an
>>>>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>>>>>
>>>>>>>>>>> George
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>>> 3GPP has not decided yet to do any normative work on
>>>>>> any of the
>>>>>>>>>>>>> solutions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>>>>>> netext at mail.mobileip.jp;
>>>>>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>>>>>> list, sorry for that
>>>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>>>>>> function though.
>>>>>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>>>>>> basis for the
>>>>>>>>>>>>>> claims of 3GPP needing this function. Seems like
>> a baseless
>>>>>>>>>>>>> claim not backed
>>>>>>>>>>>>>> by 3GPP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>>>>>> (discussed at the
>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>>>> large scale managed networks are the main
>> consumers of
>>>>>>>>>>>>> PMIP6 so we
>>>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is mainly true for intra-technology
>> mobility - and
>>>>>>>>>>>>> note that I am
>>>>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>>>>>> homogeneous from a
>>>>>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>>>>>> handovers/multihoming is
>>>>>>>>>>>>>>>>>> not helping as they have
>>>>>>>>>>>>> really set their mind
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>>>>>> going into the
>>>>>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>>>>>> defined in RFC 5213,
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>>>>>> better to fix those
>>>>>>>>>>>>>> PMIP6
>>>>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>>>>>> their own way of
>>>>>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>>>>>> Behalf Of ext
>>>>>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp;
>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
>>>>>> the BoF, so
>>>>>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
>>>>>> wanted PMIP in
>>>>>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing
>>>> solution for
>>>>>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>>>>>> use cases.
>>>>>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
>>>>>> don't know
>>>>>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>>>>>> and PMIP)
>>>>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
>>>>>> need to do
>>>>>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>>>>>> here is "PMIP
>>>>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>>>>>> something
>>>>>>>>>>>>>>>>>>> new", which is completely bogus because
>> PMIP was not
>>>>>>>>>>>>>>>>>>> designed to support those cases because we
>>>> already have
>>>>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>>>>>> my reference to 4830...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>>>>>> someone makes
>>>>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>>>>>> is no such
>>>>>>>>>>>>>>>>>>> argument then the discussion is not a good
>>>> use of time.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>>>>>> MIP. I don't
>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>> the motivation for creating something new.
>>>>>> I've detailed
>>>>>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of
>> client mobility
>>>>>>>>>>>>> management
>>>>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>>>>>> talking about
>>>>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> distinguish modification for mobility
>>>>>> management, which
>>>>>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => I think you're distinguishing between
>>>> modified and
>>>>>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>>>>>> conclusions were that you will either end
>>>> up modifying
>>>>>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's
>>>> was that this
>>>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>>>>>> room was in
>>>>>>>>>>>>>>>>>>>>> agreement as such. At least from the
>> count of hands
>>>>>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>>>>>> question about whether we should work on
>> multihoming
>>>>>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => I think the question changed a few times
>>>>>> :) The final
>>>>>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>>>>>> (which was specific to whether people
>> wanted to work
>>>>>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
>>>>>> for using
>>>>>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
>>>>>> section 4 of
>>>>>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP
>> instead of
>>>>>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Require additional SW and config on the
>> host which
>>>>>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why is there as much of a concern about
>>>> additional SW
>>>>>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway)
>>>> that we do
>>>>>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>>>>>> These were the
>>>>>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't
>> have it both
>>>>>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>>>>>> could specify
>>>>>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
>>>>>> that when a
>>>>>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is why I think we should stick with
>> the charter
>>>>>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I share the same view with respect to all
>> your other
>>>>>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> NetExt mailing list
>>>>>>>> NetExt at mail.mobileip.jp
>>>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Fri, 10 Apr 2009 13:14:36 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

I think that as part of the netext work we should have a thorough look at
the "certain advanced handoff operations" and specify exactly how this is
supposed to work. Leaving this to be solved outside of the IETF is
suboptimal... RFC 5213 is an IETF standard and we should take care that it
works well under all scenarios without any unspecified assumption or
undocumented restrictions.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 10. travanj 2009 06:42
> To: Domagoj Premec
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: RE: [Netext] next steps for netext
> 
> Hi Domagoj,
> 
> 
> On Thu, 9 Apr 2009, Domagoj Premec wrote:
> 
> > Sri,
> >
> >> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
> >
> > I still fail to see how the inter-tech handover works if you don't 
> > assume a constrained enviroment where only attachment 
> through a single 
> > access at a time is allowed. What you say above is a generic 
> > statement, but it does not hold for the generic deployment case.
> >
> 
> The specification provides all the required hooks on the network side.
> There are proper protocol semantics for achieving this. 
> However, on the terminal side, sure, for certain advanced 
> handoff operations, the terminal and the network need to be 
> in sync. If that is through a MN-AR interface, L2, L3 or AAA 
> , is a solution detail.
> 
> 
> Sri
> 
> 
> 
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: 09. travanj 2009 00:12
> >> To: Domagoj Premec
> >> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >> Subject: RE: [Netext] next steps for netext
> >>
> >> Hi Domagoj,
> >>
> >> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
> >>
> >> For other scenarios of multi-attach, there can be policies on the 
> >> network and the terminal, or a L2 signaling as you prefer, or an 
> >> application signaling ..., but sure, there may be a need for the 
> >> coordination between the terminal and the network. But, we cannot 
> >> equate this requirement with the client-mobility requirement, with 
> >> the mobile involved in signaling.
> >>
> >> Sri
> >>
> >>
> >>
> >> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>
> >>> Sri,
> >>>
> >>> What you're discribing is a specific type of deployment
> >> where the MN
> >>> is allowed to attach only through a single access at a
> >> time. But this
> >>> prevents multihoming and is not a generic solution. We need
> >> a generic
> >>> solution that works with any type of deployment without
> >> artifical restrictions.
> >>>
> >>> domagoj
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >>>> Sent: 08. travanj 2009 23:47
> >>>> To: Domagoj Premec
> >>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >>>> Subject: RE: [Netext] next steps for netext
> >>>>
> >>>> Domagoj,
> >>>>
> >>>>
> >>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>>>
> >>>>> Sri,
> >>>>>
> >>>>>> - Inter-tech handovers are supported in PMIPv6
> >>>>>
> >>>>> I disagree with this statement. In case of inter-tech
> >> handover, the
> >>>>> MAG in the new access needs to send a PBU with the HI set to "2:
> >>>>> Handoff between two different interfaces of the mobile
> >>>> node". How does
> >>>>> the new MAG know that the attachment should be treated as a
> >>>> handover
> >>>>> and not as a new session? In the absence of any other
> >>>> indications, the
> >>>>> MAG will treat this as a new attachment, which results in
> >>>> multihoming
> >>>>> with a different prefix and no handover.
> >>>>>
> >>>>
> >>>> Can a deployment have terminals that only do single attach.
> >>>> Can that information be tied to the mobile's policy profile.
> >>>> Is it possible such information is available to the MAG ?
> >>>>
> >>>> Can AAA or other session manager have the awareness of 
> the current 
> >>>> existing session. Can the MAG leverage such information
> >> and derive if
> >>>> its a handover or a new attach ?
> >>>>
> >>>> So, its possible for the MAG to derive that information from the 
> >>>> network, in many cases, including in 3GPP, as Vijay
> >> pointed out for
> >>>> single attach.
> >>>>
> >>>> Sri
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> domagoj
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
> >>>>>> Gundavelli
> >>>>>> Sent: 08. travanj 2009 21:51
> >>>>>> To: Basavaraj.Patil at nokia.com
> >>>>>> Cc: netext at mail.mobileip.jp
> >>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>
> >>>>>> I agree, this discussion is going on a different track.
> >> This wont
> >>>>>> converge. Secondly, we are bundling every thing together
> >>>> and making
> >>>>>> blanket statements. There are statements,
> >>>> multi-homing/handover does
> >>>>>> not work in PMIPv6, or that there needs to be an L2 
> interface ..
> >>>>>> there seems to be lot of assumptions around this, with out
> >>>> qualifying
> >>>>>> that, these statements are only creating confusion. Couple
> >>>> of points:
> >>>>>>
> >>>>>> - Multihoming is supported in PMIPv6
> >>>>>> - Inter-tech handovers are supported in PMIPv6
> >>>>>> - None of these features break or burn the host.
> >>>>>>
> >>>>>> 3GPP is not the only consumer for this work. Nothing stops
> >>>> some one
> >>>>>> from building an IPv6 enterprise mobility solution based
> >> on Proxy
> >>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but
> >> a protocol
> >>>>>> that can be deployed in enterprise wireless architectures.
> >>>> No one can
> >>>>>> tell me, we cant deploy this protocol for solving 
> micro mobility 
> >>>>>> problems in an integrated wired/wireless AP environments,
> >>>> targetted
> >>>>>> for an enterprise.
> >>>>>>
> >>>>>>> From the list of proposed items, I'd really hope to
> >> identify the
> >>>>>>> work
> >>>>>> items that does not require extesive debates from the 
> ones that 
> >>>>>> requires fist-fighting.
> >>>>>>
> >>>>>> - Flow mobility has the scope from moving individual flows of 
> >>>>>> interest with no relation to prefix, vs moving flows 
> as a bundle 
> >>>>>> associated to a prefix.
> >>>>>>
> >>>>>> - Host specific doc, from the point of view of leveraging
> >>>> what 5213
> >>>>>> supports, vs, for supporting the new features.
> >>>>>>
> >>>>>> - Multi-homing, binding a single prefix to multiple
> >>>> interfaces, vs,
> >>>>>> an individual prefix to each interface.
> >>>>>>
> >>>>>>
> >>>>>> We have to qualify the discussions around this, just the
> >>>> use of the
> >>>>>> key words multi-homing, inter-tech handovers, flow 
> mobility, and 
> >>>>>> saying is not for PMIP6, is not accurate, does not justify the 
> >>>>>> concern and does not help the discussions. We have to
> >> state which
> >>>>>> specific item has issues and under what scenario's.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Sri
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Lets try and keep this discussion focused on technical issues.
> >>>>>>> The current tone is not very encouraging in some instances.
> >>>>>>>
> >>>>>>> The current discussion is overly focused on what 3GPP is
> >>>>>> doing w.r.t
> >>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
> >>>> protocols when
> >>>>>>> they see a good fit for their architecture and problem
> >> scope. We
> >>>>>>> cannot tell 3GPP to not develop a feature by themselves and
> >>>>>> instead rely on the IETF to deliver it.
> >>>>>>> They are free to do whatever they want.
> >>>>>>>
> >>>>>>> Within the IETF we can identify what problems or extensions
> >>>>>> to PMIP6
> >>>>>>> we want to work on and focus on these. If 3GPP finds
> >> the solution
> >>>>>>> applicable, they will use it. The IETF solution has to
> >>>> address the
> >>>>>>> generic problem and not tailored for 3GPP (which is what we
> >>>>>> seem to be doing now).
> >>>>>>> So maybe we can get down to discussing the problem and
> >>>>>> scenarios that
> >>>>>>> we would like to work on in Netext as a way of moving forward.
> >>>>>>>
> >>>>>>> In order to make progress, I would suggest that we 
> focus on the 
> >>>>>>> following 3
> >>>>>>> topics:
> >>>>>>> A. Multihoming
> >>>>>>> B. Flow mobility
> >>>>>>> C. Inter technology handovers
> >>>>>>>
> >>>>>>> If we can articulate the scenarios and associated problems
> >>>>>> with each
> >>>>>>> of the same, we can then get a better handle on what to
> >>>> take on in
> >>>>>>> Netext. And lets not start saying that we already have a
> >>>>>> solution in I-Dx or I-Dy.
> >>>>>>>
> >>>>>>> -Raj
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >>>>>> <vijay at wichorus.com> wrote:
> >>>>>>>
> >>>>>>>> Hi George,
> >>>>>>>>
> >>>>>>>> George Tsirtsis wrote:
> >>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli 
> >>>>>>>>> <vijay at wichorus.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi Gerardo,
> >>>>>>>>>>
> >>>>>>>>>>> 3GPP has a study item on this feature. There was 
> no PMIPv6 
> >>>>>>>>>>> solutions proposed on any I-D - there is a
> >>>>>> 3GPP-specific solution
> >>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>>>>>
> >>>>>>>>>> This is exactly what I would like to avoid. I would
> >>>>>> prefer using a
> >>>>>>>>>> solution developed in the IETF rather than 
> something in 3GPP.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
> >>>> technology for
> >>>>>>>>> almost as long as the IETF. Getting the IETF to do
> >>>> something only
> >>>>>>>>> makes sense if the given protocol has general
> >>>>>> applicability and does
> >>>>>>>>> not damage the Internet, which is why we are having this
> >>>>>> discussion.
> >>>>>>>>
> >>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >>>>>> very little
> >>>>>>>> modifications. They have added some vendor specific
> >> options for
> >>>>>>>> carrying some 3GPP specific information, but they are minor 
> >>>>>>>> extensions. So when 3GPP is considering flow mobility for
> >>>>>> PMIPv6, it
> >>>>>>>> doesn't make sense for them to develop a solution on their
> >>>>>> own. It should be done in the IETF.
> >>>>>>>>
> >>>>>>>> And can we please stop the hyperbole about "damaging the
> >>>>>> Internet"?
> >>>>>>>> It is irritating and doesn't contribute to the discussion.
> >>>>>>>>
> >>>>>>>>> GT> In another e-mail where you are over-viewing a
> >>>>>> possible solution
> >>>>>>>>> to PMIP multihoming you talk about how the MN may use
> >> an L2 to
> >>>>>>>>> signal to indicate what flows need to go to a given
> >>>> MAG. I do not
> >>>>>>>>> see how the IETF can define a protocol that fully depends
> >>>>>> on such an
> >>>>>>>>> L2 signal. If such functionality is needed then the IETF
> >>>>>> must define
> >>>>>>>>> it at the IP layer to make sure that this works
> >> across ALL link
> >>>>>>>>> layers (which is the main reason the IETF and the
> >>>> Internet exist).
> >>>>>>>>
> >>>>>>>> Indicating the service identifier during an L2 attachment is 
> >>>>>>>> supported in most accesses that PMIPv6 is being used for.
> >>>>>> So I don't
> >>>>>>>> see it as a big issue. You don't need a MN-MAG IP 
> protocol for 
> >>>>>>>> carrying the service identifier. That would be an overkill.
> >>>>>>>>
> >>>>>>>> Anyway, flow mobility can still be achieved even if the MN
> >>>>>> does not
> >>>>>>>> indicate the service identifier. Please see
> >>>>>>>>
> >>>>>>
> >>>>
> >> 
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>>>>>
> >>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
> >>>>>> hurdles to overcome:
> >>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
> >>>>>> to define
> >>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>>>>>
> >>>>>>>> That is one option, but not required.
> >>>>>>>>
> >>>>>>>> Vijay
> >>>>>>>>
> >>>>>>>>> 2) Convince people that defining such a client based
> >>>> protocol in
> >>>>>>>>> addition to the existing standard (MIPv6) is
> >> warranted. In the
> >>>>>>>>> process, explain to people why you want to introduce FA 
> >>>>>>>>> functionality to MIPv6, which is what MAGs become if
> >> you add an
> >>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>>>>>
> >>>>>>>>> George
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Vijay
> >>>>>>>>>>
> >>>>>>>>>>> 3GPP has not decided yet to do any normative work on
> >>>> any of the
> >>>>>>>>>>> solutions.
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>>>>>> To: Giaretta, Gerardo
> >>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
> >>>> netext at mail.mobileip.jp;
> >>>>>>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>>>>>> list, sorry for that
> >>>>>>>>>>>>> :-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>>>>>> function though.
> >>>>>>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>>>>>> basis for the
> >>>>>>>>>>>> claims of 3GPP needing this function. Seems like 
> a baseless
> >>>>>>>>>>> claim not backed
> >>>>>>>>>>>> by 3GPP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hesham
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Vijay
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>>>>>> (discussed at the
> >>>>>>>>>>>> last
> >>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>>>>>> WiMAX with PMIPv6
> >>>>>>>>>>>>>> working.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>>>> large scale managed networks are the main 
> consumers of
> >>>>>>>>>>> PMIP6 so we
> >>>>>>>>>>>>>> shouldn't
> >>>>>>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is mainly true for intra-technology 
> mobility - and
> >>>>>>>>>>> note that I am
> >>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>>>>>> homogeneous from a
> >>>>>>>>>>>>>> link layer point of view.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Saying to use MIP for inter-access
> >>>>>> handovers/multihoming is
> >>>>>>>>>>>>>>>> not helping as they have
> >>>>>>>>>>> really set their mind
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>>>>>> going into the
> >>>>>>>>>>>>>> reasoning
> >>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>>>>>> defined in RFC 5213,
> >>>>>>>>>>>> has
> >>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>>>>>> better to fix those
> >>>>>>>>>>>> PMIP6
> >>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>>>>>> their own way of
> >>>>>>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> domagoj
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
> >>>> Behalf Of ext
> >>>>>>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; 
> Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
> >>>> the BoF, so
> >>>>>>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
> >>>> wanted PMIP in
> >>>>>>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing
> >> solution for
> >>>>>>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >>>>>> use cases.
> >>>>>>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>>>>>> host-based mobility
> >>>>>>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >>>>>> discussion
> >>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
> >>>> don't know
> >>>>>>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>>>>>> saying:
> >>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >>>>>> and PMIP)
> >>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
> >>>> need to do
> >>>>>>>>>>>>>>>>> something new.
> >>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
> >>>>>> here is "PMIP
> >>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >>>>>> something
> >>>>>>>>>>>>>>>>> new", which is completely bogus because 
> PMIP was not 
> >>>>>>>>>>>>>>>>> designed to support those cases because we
> >> already have
> >>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
> >>>>>> my reference to 4830...
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
> >>>>>> someone makes
> >>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
> >>>>>> is no such
> >>>>>>>>>>>>>>>>> argument then the discussion is not a good
> >> use of time.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
> >>>>>> MIP. I don't
> >>>>>>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>>>>>> the motivation for creating something new.
> >>>> I've detailed
> >>>>>>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of 
> client mobility
> >>>>>>>>>>> management
> >>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>>>>>> seems to be a
> >>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >>>>>> talking about
> >>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> distinguish modification for mobility
> >>>> management, which
> >>>>>>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>>>>>> as the use of
> >>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>>>>>> configure
> >>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => I think you're distinguishing between
> >> modified and
> >>>>>>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>>>>>> the BoF, our
> >>>>>>>>>>>>>>>>>>> conclusions were that you will either end
> >> up modifying
> >>>>>>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>>>>>> stick with MIP.
> >>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's
> >> was that this
> >>>>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>>>>>> this is such a
> >>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>>>>>> room was in
> >>>>>>>>>>>>>>>>>>> agreement as such. At least from the 
> count of hands
> >>>>>>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>>>>>> question about whether we should work on 
> multihoming
> >>>>>>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => I think the question changed a few times
> >>>> :) The final
> >>>>>>>>>>>>>>>>> question
> >>>>>>>>>>>>>>>>>>> (which was specific to whether people 
> wanted to work
> >>>>>>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>>>>>> mentioned here
> >>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
> >>>> for using
> >>>>>>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>>>>>> the host) and
> >>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
> >>>> section 4 of
> >>>>>>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP 
> instead of
> >>>>>>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>>>>>> anyway. However if
> >>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>>>>>> not specify how
> >>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>>>>>> in all L2s,
> >>>>>>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Require additional SW and config on the 
> host which
> >>>>>>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why is there as much of a concern about
> >> additional SW
> >>>>>>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway)
> >> that we do
> >>>>>>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
> >>>> These were the
> >>>>>>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't 
> have it both
> >>>>>>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>>>>>> scope in IETF
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>>>>>> could specify
> >>>>>>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>>>>>> if that is the
> >>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
> >>>> that when a
> >>>>>>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>>>>>> is inferior in
> >>>>>>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is why I think we should stick with 
> the charter
> >>>>>>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I share the same view with respect to all 
> your other
> >>>>>>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>>>>>> mostly flow
> >>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> NetExt mailing list
> >>>>>> NetExt at mail.mobileip.jp
> >>>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 9 Apr 2009 21:41:32 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

On Thu, 9 Apr 2009, Domagoj Premec wrote:

> Sri,
>
>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>
> I still fail to see how the inter-tech handover works if you don't assume a
> constrained enviroment where only attachment through a single access at a
> time is allowed. What you say above is a generic statement, but it does not
> hold for the generic deployment case.
>

The specification provides all the required hooks on the network side.
There are proper protocol semantics for achieving this. However, on the
terminal side, sure, for certain advanced handoff operations, the
terminal and the network need to be in sync. If that is through a MN-AR
interface, L2, L3 or AAA , is a solution detail.

Sri

> domagoj
>
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 09. travanj 2009 00:12
>> To: Domagoj Premec
>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>> Subject: RE: [Netext] next steps for netext
>>
>> Hi Domagoj,
>>
>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>
>> For other scenarios of multi-attach, there can be policies on
>> the network and the terminal, or a L2 signaling as you
>> prefer, or an application signaling ..., but sure, there may
>> be a need for the coordination between the terminal and the
>> network. But, we cannot equate this requirement with the
>> client-mobility requirement, with the mobile involved in signaling.
>>
>> Sri
>>
>>
>>
>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>
>>> Sri,
>>>
>>> What you're discribing is a specific type of deployment
>> where the MN
>>> is allowed to attach only through a single access at a
>> time. But this
>>> prevents multihoming and is not a generic solution. We need
>> a generic
>>> solution that works with any type of deployment without
>> artifical restrictions.
>>>
>>> domagoj
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>> Sent: 08. travanj 2009 23:47
>>>> To: Domagoj Premec
>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>> Subject: RE: [Netext] next steps for netext
>>>>
>>>> Domagoj,
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>
>>>>> Sri,
>>>>>
>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>
>>>>> I disagree with this statement. In case of inter-tech
>> handover, the
>>>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>>>> Handoff between two different interfaces of the mobile
>>>> node". How does
>>>>> the new MAG know that the attachment should be treated as a
>>>> handover
>>>>> and not as a new session? In the absence of any other
>>>> indications, the
>>>>> MAG will treat this as a new attachment, which results in
>>>> multihoming
>>>>> with a different prefix and no handover.
>>>>>
>>>>
>>>> Can a deployment have terminals that only do single attach.
>>>> Can that information be tied to the mobile's policy profile.
>>>> Is it possible such information is available to the MAG ?
>>>>
>>>> Can AAA or other session manager have the awareness of the current
>>>> existing session. Can the MAG leverage such information
>> and derive if
>>>> its a handover or a new attach ?
>>>>
>>>> So, its possible for the MAG to derive that information from the
>>>> network, in many cases, including in 3GPP, as Vijay
>> pointed out for
>>>> single attach.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> domagoj
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>>>> Gundavelli
>>>>>> Sent: 08. travanj 2009 21:51
>>>>>> To: Basavaraj.Patil at nokia.com
>>>>>> Cc: netext at mail.mobileip.jp
>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>
>>>>>> I agree, this discussion is going on a different track.
>> This wont
>>>>>> converge. Secondly, we are bundling every thing together
>>>> and making
>>>>>> blanket statements. There are statements,
>>>> multi-homing/handover does
>>>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
>>>>>> there seems to be lot of assumptions around this, with out
>>>> qualifying
>>>>>> that, these statements are only creating confusion. Couple
>>>> of points:
>>>>>>
>>>>>> - Multihoming is supported in PMIPv6
>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>> - None of these features break or burn the host.
>>>>>>
>>>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>> some one
>>>>>> from building an IPv6 enterprise mobility solution based
>> on Proxy
>>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but
>> a protocol
>>>>>> that can be deployed in enterprise wireless architectures.
>>>> No one can
>>>>>> tell me, we cant deploy this protocol for solving micro mobility
>>>>>> problems in an integrated wired/wireless AP environments,
>>>> targetted
>>>>>> for an enterprise.
>>>>>>
>>>>>>> From the list of proposed items, I'd really hope to
>> identify the
>>>>>>> work
>>>>>> items that does not require extesive debates from the ones that
>>>>>> requires fist-fighting.
>>>>>>
>>>>>> - Flow mobility has the scope from moving individual flows of
>>>>>> interest with no relation to prefix, vs moving flows as a bundle
>>>>>> associated to a prefix.
>>>>>>
>>>>>> - Host specific doc, from the point of view of leveraging
>>>> what 5213
>>>>>> supports, vs, for supporting the new features.
>>>>>>
>>>>>> - Multi-homing, binding a single prefix to multiple
>>>> interfaces, vs,
>>>>>> an individual prefix to each interface.
>>>>>>
>>>>>>
>>>>>> We have to qualify the discussions around this, just the
>>>> use of the
>>>>>> key words multi-homing, inter-tech handovers, flow mobility, and
>>>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>>>> concern and does not help the discussions. We have to
>> state which
>>>>>> specific item has issues and under what scenario's.
>>>>>>
>>>>>> Thanks
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Lets try and keep this discussion focused on technical issues.
>>>>>>> The current tone is not very encouraging in some instances.
>>>>>>>
>>>>>>> The current discussion is overly focused on what 3GPP is
>>>>>> doing w.r.t
>>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>>>> protocols when
>>>>>>> they see a good fit for their architecture and problem
>> scope. We
>>>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>>>> instead rely on the IETF to deliver it.
>>>>>>> They are free to do whatever they want.
>>>>>>>
>>>>>>> Within the IETF we can identify what problems or extensions
>>>>>> to PMIP6
>>>>>>> we want to work on and focus on these. If 3GPP finds
>> the solution
>>>>>>> applicable, they will use it. The IETF solution has to
>>>> address the
>>>>>>> generic problem and not tailored for 3GPP (which is what we
>>>>>> seem to be doing now).
>>>>>>> So maybe we can get down to discussing the problem and
>>>>>> scenarios that
>>>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>>>
>>>>>>> In order to make progress, I would suggest that we focus on the
>>>>>>> following 3
>>>>>>> topics:
>>>>>>> A. Multihoming
>>>>>>> B. Flow mobility
>>>>>>> C. Inter technology handovers
>>>>>>>
>>>>>>> If we can articulate the scenarios and associated problems
>>>>>> with each
>>>>>>> of the same, we can then get a better handle on what to
>>>> take on in
>>>>>>> Netext. And lets not start saying that we already have a
>>>>>> solution in I-Dx or I-Dy.
>>>>>>>
>>>>>>> -Raj
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>>>> <vijay at wichorus.com> wrote:
>>>>>>>
>>>>>>>> Hi George,
>>>>>>>>
>>>>>>>> George Tsirtsis wrote:
>>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>>>> <vijay at wichorus.com>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Gerardo,
>>>>>>>>>>
>>>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>>>> solutions proposed on any I-D - there is a
>>>>>> 3GPP-specific solution
>>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>>>
>>>>>>>>>> This is exactly what I would like to avoid. I would
>>>>>> prefer using a
>>>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>>>> technology for
>>>>>>>>> almost as long as the IETF. Getting the IETF to do
>>>> something only
>>>>>>>>> makes sense if the given protocol has general
>>>>>> applicability and does
>>>>>>>>> not damage the Internet, which is why we are having this
>>>>>> discussion.
>>>>>>>>
>>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>>>> very little
>>>>>>>> modifications. They have added some vendor specific
>> options for
>>>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>>>> PMIPv6, it
>>>>>>>> doesn't make sense for them to develop a solution on their
>>>>>> own. It should be done in the IETF.
>>>>>>>>
>>>>>>>> And can we please stop the hyperbole about "damaging the
>>>>>> Internet"?
>>>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>>>
>>>>>>>>> GT> In another e-mail where you are over-viewing a
>>>>>> possible solution
>>>>>>>>> to PMIP multihoming you talk about how the MN may use
>> an L2 to
>>>>>>>>> signal to indicate what flows need to go to a given
>>>> MAG. I do not
>>>>>>>>> see how the IETF can define a protocol that fully depends
>>>>>> on such an
>>>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>>>> must define
>>>>>>>>> it at the IP layer to make sure that this works
>> across ALL link
>>>>>>>>> layers (which is the main reason the IETF and the
>>>> Internet exist).
>>>>>>>>
>>>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>>>> So I don't
>>>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>>>
>>>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>>>> does not
>>>>>>>> indicate the service identifier. Please see
>>>>>>>>
>>>>>>
>>>>
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>>>
>>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>>>> hurdles to overcome:
>>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>>>> to define
>>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>>>
>>>>>>>> That is one option, but not required.
>>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> 2) Convince people that defining such a client based
>>>> protocol in
>>>>>>>>> addition to the existing standard (MIPv6) is
>> warranted. In the
>>>>>>>>> process, explain to people why you want to introduce FA
>>>>>>>>> functionality to MIPv6, which is what MAGs become if
>> you add an
>>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>>>
>>>>>>>>> George
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Vijay
>>>>>>>>>>
>>>>>>>>>>> 3GPP has not decided yet to do any normative work on
>>>> any of the
>>>>>>>>>>> solutions.
>>>>>>>>>>>
>>>>>>>>>>> Gerardo
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>>>> netext at mail.mobileip.jp;
>>>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>>>> list, sorry for that
>>>>>>>>>>>>> :-)
>>>>>>>>>>>>
>>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>>>> function though.
>>>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>>>> basis for the
>>>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>>>> claim not backed
>>>>>>>>>>>> by 3GPP.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>>>> (discussed at the
>>>>>>>>>>>> last
>>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>>>> PMIP6 so we
>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>>>> note that I am
>>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>>>> homogeneous from a
>>>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>>>> handovers/multihoming is
>>>>>>>>>>>>>>>> not helping as they have
>>>>>>>>>>> really set their mind
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>>>> going into the
>>>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>>>> defined in RFC 5213,
>>>>>>>>>>>> has
>>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>>>> better to fix those
>>>>>>>>>>>> PMIP6
>>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>>>> their own way of
>>>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>>>> Behalf Of ext
>>>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
>>>> the BoF, so
>>>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
>>>> wanted PMIP in
>>>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing
>> solution for
>>>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>>>> use cases.
>>>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>>>> discussion
>>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
>>>> don't know
>>>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>>>> and PMIP)
>>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
>>>> need to do
>>>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>>>> here is "PMIP
>>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>>>> something
>>>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>>>>>> designed to support those cases because we
>> already have
>>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>>>> my reference to 4830...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>>>> someone makes
>>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>>>> is no such
>>>>>>>>>>>>>>>>> argument then the discussion is not a good
>> use of time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>>>> MIP. I don't
>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>> the motivation for creating something new.
>>>> I've detailed
>>>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>>>> management
>>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>>>> talking about
>>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> distinguish modification for mobility
>>>> management, which
>>>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => I think you're distinguishing between
>> modified and
>>>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>>>> conclusions were that you will either end
>> up modifying
>>>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's
>> was that this
>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>>>> room was in
>>>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => I think the question changed a few times
>>>> :) The final
>>>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
>>>> for using
>>>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
>>>> section 4 of
>>>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why is there as much of a concern about
>> additional SW
>>>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway)
>> that we do
>>>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>>>> These were the
>>>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>>>> could specify
>>>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
>>>> that when a
>>>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> NetExt mailing list
>>>>>> NetExt at mail.mobileip.jp
>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 9 Apr 2009 21:27:13 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Teemu,

On Mon, 6 Apr 2009, teemu.savolainen at nokia.com wrote:

> Hi Sri,
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>> At least in my vocabulary that counts as modified host -
>> things are changed in a host to make it behave differently.
>>
>> Perfectly fine, if that is the definition of "modified host".
>> I'd ask, show me a reference implementation of a host, which
>> tells me what is the basic software that is standard and
>> beyond which is considered a modified host. Where is that
>> sacred host stack definition.
>
> There's no such thing as reference host implementation as far as I know. That is exactly the reason why I consider also all "configuration tricks" as host changes - those place assumptions on hosts' capabilities. On some OS'es virtual interfaces can perhaps be configured with few magical commands or scripts, but on some OS'es the same thing requires implementation of new C-code. Thus the claim that with PMIP it is possible to do inter-access mobility is just not true, as it requires *some* changes in at least on some Oses (or alternatively hiding everything below L2). If the PMIP would already support inter-access mobility, it would not require *any* changes. If the inter-access mobility can be realized with a virtual interface, then we could just acknowledge that some host changes are needed, document what they are, and say that realizing those means less effort on some OSes than on others.
>

I agree with your description, it places certain "assumptions" on the
host. In most OS's, it might be about running a tool to enable a
specific configuration, in some cases there might be a new application
required. I did not want this to imply "host change", that is most cases
implies change to certain IETF specifications or protocols, atleast in
the context of IETF discussion.

Regards
Sri

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Thu, 9 Apr 2009 12:02:06 -0400
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj,

I understand this might reach to solution space, but this argument is  
somehow important for this WG.
We can even discuss PMIP extension in MEXT, too. NEMO, DSMIP, other  
MIP-based-protocols are currently discussed at MEXT.

If NeEXT ignores the existing solution available at MEXT, it will be  
insane.
This WG should pay attention to existing approaches first before  
selecting solutions.
It will be disaster to have two different extensions for the same  
things... (specially if LMA and HA are coexisted)

ryuji

On 2009/04/09, at 0:23, <Basavaraj.Patil at nokia.com> <Basavaraj.Patil at nokia.com 
 > wrote:

>
> Hi Ryuji,
>
> Tough question :(
>
> In principle I agree that we should attempt to use the work already  
> done in
> MEXT for MIP6. And given that PMIP6 itself is derived from MIP6 the  
> add-on
> features should follow as well.
>
> However you simply cannot ignore the fact that with MIP6 the MN  
> itself is
> able to do signaling to control flows, or handovers etc. Given the
> difference in the models and the intent to not involve the MN, it  
> might not
> be quite as simple to say that we will inherit and use the work  
> already
> done.
>
> There may be a need to do some adaptations. I don't know the answer  
> really
> because this goes into the solution space (and we are not there  
> yet). I
> agree with your view that we should take the same approach (as MIP6)  
> to
> provide such functionality.
>
> -Raj
>
>
> On 4/8/09 4:52 PM, "ext Ryuji Wakikawa" <ryuji.wakikawa at gmail.com>  
> wrote:
>
>> Hi Raj,
>>
>> Thanks for this. I agree on what you said in your mail.
>> However, I want to ask one more clarification.
>>
>> I don't want to go to MIP6 vs PMIP6 here, but some of extensions
>> (multihoming, flow mobility,
>> LMA redirection aka HAswithc?) are already covered by MIP6 in MEXT.
>> When we need the similar features to PMIP,
>> will NetEXT solution inherit MIP6 and MIP6-based-extension as RFC5213
>> did?
>> One of goal of RFC5213 was to inherit MIP6 spec as much as possible.
>>
>> PMIP specific issues can be solved anyway, but some of common issues
>> can be
>> solved with the similar extensions to MIP6 or with another extensions
>> to MIP6 extension.
>> After PMIP6 deployment, we will have more common issues between MIP6
>> and PMIP6.
>>
>> It makes sense to take the same approach to solve the same goal at
>> MIP6 and PMIP6.
>>
>> regards,
>> ryuji
>>
>>
>>
>> On 2009/04/08, at 16:29, <Basavaraj.Patil at nokia.com>
>> <Basavaraj.Patil at nokia.com
>>> wrote:
>>
>>>
>>> Hello,
>>>
>>> There is an issue in the current debate that we should put to rest.
>>> Netext proposes to extend PMIP6 to support multihoming, flow  
>>> mobility
>>> and inter-technology handovers (in addition to others over which
>>> there is
>>> an agreement on).
>>>
>>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>>> these capabilities currently. I dont think there is any debate about
>>> that.
>>> However there is an interested group of people within the IETF
>>> community who would like to extend PMIP6 to support these features  
>>> as
>>> well.
>>> It is not uncommon in the IETF to have multiple competing protocols
>>> provide similar functionality. The industry will ultimately choose  
>>> an
>>> appropriate solution depending on the needs. So I dont think we can
>>> just quash the idea of working on these extensions simply because we
>>> already have a protocol that does it.
>>> It is also noted that one of the primary reasons for developing  
>>> PMIP6
>>> was to provide mobility without host involvement. The term
>>> "host-changes" in the context of the current discussion are still  
>>> to a
>>> large extent based on the PMIP6 intent. As long as we are not  
>>> defining
>>> a new protocol on the host, we can consider the host as being
>>> unmodified (from this disucssions PoV).
>>>
>>> In summary I would say that this is not a discussion about whether
>>> host based Mobile IP (MIP6) is the appropriate protocol for  
>>> providing
>>> multihoming, Flow mobility and, inter-tech HOs but rather about what
>>> can be done to provide similar capabilities to PMIP6 without  
>>> (grossly)
>>> changing the basic protocol principles.
>>>
>>> -Raj
>>>
>>> P.S: I recognize that some would say that inter-tech HOs and
>>> multihoming are already features supported by PMIP6. In the current
>>> context of Netext, what is being proposed is basically  
>>> enhancements to
>>> PMIP6 that address scenarios not currently in the base spec.
>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Thu, 9 Apr 2009 07:53:08 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

Thanks for your mail. Sorry for the late reply.
Please see inline.

On Mon, 6 Apr 2009, Jari Arkko wrote:

> Sri,
>
> Thanks for your input. Inline:
>
>>  I've a concern with the planned charter. The list is too random and
>>  cherry picked and I dont believe proper input from all the folks went into
>>  this. There are many other items that are required for a reasonable
>>  deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
>>  years, some of them that were left out in the base spec, some that we
>>  realized as gaps when compared to other SDO protocols and some as
>>  optimizations that we realized while implementing PMIP6, these items
>>  should be in the initial scope.
>>
>>  I understand the charter needs to be limited in scope, but just 3 or 4
>>  random items, I'm not sure if this helps in short term PMIP6 requirements.
>>  I've no issue with the currently listed items, but there are other items
>>  that should get equal or higher priority.
>
> I have no problem with adding more. Even the charter says new things can be 
> added.
>
> However, from a process perspective what I did was to take the proposal on 
> the table, i.e., the full BOF scope and see what parts of that we already 
> have an agreement on. I didn't include other things that were not discussed 
> in the BOF. Maybe that would have been useful, but they were not on the 
> table.
>
> We could add more items now, if there's general agreement that those things 
> are useful. However, I do not want to declare an open season on doing 
> everything. We pick a reasonable subset of all proposed work, based on 
> priorities, community agreement that they are the right things to do, 
> management reasons to ensure that we are not doing too much, etc.
>

Ok

>>  For example, item #6, is absolutely required, from the perspective of
>>  having a complete specification of 5213. There we allowed a mobile node to
>>  perform handoff betweek two interfaces. We defined all the hooks on the
>>  network side, but we did not provide how a terminal vendor can support
>>  that. A simple informational draft on how some one move prefixes between
>>  interfaces will greatly help. Some guidance on how to create a virtual
>>  interface and also some related notes for each platform (Linux, BSD,
>>  Android ..etc). This should not fall in the controversial discussion scope
>>  of same address on two interfaces etc, thats a different problem, or about
>>  the issue of enhancing mobile node's capabilities. This is just
>>  informational work, required to leverage what 5213 already supports.
>
> I suspect this is about the scoping of the handoff work. Lets try to figure 
> out what makes sense (I personally believe the above item makes sense, for 
> instance) and what doesn't.
>
> The fact that these parts were not in the charter was not a declaration that 
> we're dismissing them. Its just that we didn't finish the discussion, but I 
> still wanted to let the other things move forward.
>

The current discussions should not have much bearing on this. This is
clearly not about any host changes, some informational work required
for completing 5213.

>>  Item #2, is required. The multimob BOF raised some issues, we need to
>>  show how multicast services can be enabled in PMIP network. May be this
>>  wont require extensions, a simple draft covering those aspects will help.
>
> As you may recall, in the Multimob BOF we did not have an agreement on what 
> exactly is needed, if anything. My own conclusion is that we probably need at 
> least an informational document that explains how to use RFC 5213 for 
> multicast. I think we discussed the possibility of doing this as some kind of 
> AD sponsored document or in one of the relevant WGs, as a joint work between 
> PMIP and multicast experts.
>
> I'm on the fence about adding this work to the charter right now, mainly 
> because the BOF back then was very inconclusive. I'd be happier if I saw an 
> actual well written draft from say you and some of the multicast experts. 
> There's no problem moving good documents forward, even if they are not in the 
> charter of some WG. Then again, I wouldn't necessarily mind a maintenance 
> like item for this in one of the WG charters either.
>

Ok, sure. We can probably first identify the issues and bring that work.

>>  I think, the charter should be bit more relaxed and more extensive. As I
>>  see it, atleast the folks are interested in doing the work. We should add
>>  atleast 4 or 5 more items to this list.
>
> Generally speaking IETF WG charters give specific work items that the WG 
> should work on. I had hoped that the charter text:
>
> "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."
>
> gives an indication that we intend to do more! I am also personally very 
> happy to add more items to the group's charter. All in all, I do know that 
> the current charter is a bit on the thin side -- mostly because the 
> multihoming/interaccess issue is under discussion.
>
> There's also the question of general maintenance items. Some IETF WGs have a 
> general work item to fix problems and issue updates to existing 
> specifications. I think we need to do that for Proxy Mobile IPv6 as well. But 
> we have not decided whether that item should go to NETLMM or NETEXT WG yet. 
> Please rest assured that the work will be possible regardless of this.
>

Thanks

>
>>  5. Group Identifier Support for Proxy Mobile IPv6
>>
>>  This provides a simple and a generic semantic for assigning a group
>>  identifier
>>  to a mobile node's binding. GTP has very similar semantics, Connexion Set
>>  Id.
>>  Both #3 and #4 can leverage this. Additionally, in load balancer systems
>>  where
>>  the load balancer is in path for all signaling messages, it can use this
>>  as
>>  a
>>  tag for redirecting the message.
>>
>>  http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
> Since the bulk registration work is in the charter, can't you do the sensible 
> design (whatever it is) under that? There is no requirement that one charter 
> item equals one document.
>

Sure. This may be covered as part of other work items.

>>  6. Virtual-Interface Support on IP host for supporting Inter-tech
>>  handoffs:
>> 
>>
>>  RFC-5213 supports handoff between two interfaces. The ability to move
>>  prefixes between interfaces. In other words address continuity is assured
>>  with any IPv6 host on the planet and with absolutely no changes. This
>>  meets
>>  even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>>  not assured is the aspect of session continuity. Which requires a virtual
>>  interface implementation on the host, by binding the address/prefix to a
>>  virtual interface and by not exposing the physical interface or by hiding
>>  the handoff events from the layer-3 stack.
>>
>>  In essence, we need an informational specification which provides some
>>  general guidance to how to leverage the feature support provided in
>>  RFC-5213,
>>  along the lines of:
>>
>>  http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
> This is part of the discussion that we need to finish. But I plan to let the 
> rest of the stuff move forward even before we have done that.
>

This is for completing 5213. An informational draft on how to use
5213 featrures, really needed. And this should be in non controverisal
in scope.

>
>>  9. Partial Handoff Support
>>
>>  We are missing some semantics in 5213 for moving a subset of the prefixes
>>  between interfaces as part of the inter-tech handoff. This is about
>>  defining
>>  a new handoff value. This allows partial flow management, but moving the
>>  flows associated to a prefix, as a whole group.
>>
>>  http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00 
>> 
>
> A part of the topic we still need to discuss...

This is minor optimization to what 5213 already supports. Its
about providing a semantic on the network side. We dont have to
tie this to the other larger flow mgmt features, either way ..

>>  11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
> Can you expand on this?
>

This is for delegating prefix to a mobile node in a PMIP environment.
How the MN can use DHCP PD or other mechanisms to obtain a prefix.

Sri

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Thu, 9 Apr 2009 10:08:58 +0100
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hesham, thanks for this e-mail.

It is exactly what a number of people have been calling for, first
during the BOF, and since then on the list.
Part of the problem in this discussion has been that people are
selective to the "technical argument" they want to hear.

Hesham below (and others before him)  ask for technical justification
of why the work needs to be done.
Others have been demanding that we accept the need to do this as a
given and discuss the solutions directly.

These are both technical discussions and we need the first before we
get into the second.

Regards
George

On Thu, Apr 9, 2009 at 4:21 AM, Hesham Soliman <hesham at elevatemobile.com> wrote:
> Hi Raj,
>
> Thank you for responding to my question! I'm glad someone is listening.
>
>
> On 9/04/09 3:05 PM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
> wrote:
>
>>
>> Hi Hesham,
>>
>> I have seen you asking for a problem statement in several emails now and
>> none has been forthcoming so far. So let me try to understand your view:
>>
>> Netext proposes to extend PMIP6 to support flow mobility, address several
>> multihoming scenarios and, support intertechnology handovers.
>>
>> Are you asking why we need to work on these features for PMIP6? Obviously
>> from the perspective of protocols specified in the IETF, we do recognize
>> that multihoming, flow mobility and intertechnology handovers can be
>> provided by Mobile IPv6. So are you of the opinion that given the
>> availability of a solution in the IETF for these problems there is no need
>> to work on these?
>
> => No. Here is what I think in the abstract and how it applies to this
> particular case. A problem statement should explain the problem, discuss the
> state of the art, then show why the state of the art doesn't solve the
> problem. Based on this, one can conclude one of two things:
> 1. We need to modify the state of the art to solve the problem, or,
> 2. We need something new because modifying the above is not going to work
> (for many possible reasons).
>
> The choice between 1) and 2) obviously involves a solution space discussion
> once the problem is defined.
> For this BoF, this means:
> - Define the problem: a host needs to to able to send/receive packets on
> multiple interfaces ....etc, deployment issues, ....etc
> - Explain why the state of the art is not sufficient: PMIP doesn't solve
> this because..., MIP doesn't solve this because ... Something else....etc
>
> Then we can see real reasons for deciding to go one way or another. Of
> course what happened so far is that people essentially say one of three
> things:
> A. PMIP doesn't solve this so we need something (completely ignoring MIP),
> or,
> B. MIP solves this but there must be more than one way of doing it, or,
> C. There is an unofficial, unstated requirement from SDOs that we must
> fullfil without discussion.
>
> A) is obviously incomplete, B) is utter nonsense and C) is dangerous.
>
>>
>> If the question is about what is the problem w.r.t multihoming in the case
>> of PMIP6 and respectively other features as well, please do review the PS
>> I-Ds ( draft-jeyatharan-netext-multihoming-ps-01,
>> draft-krishnan-netext-intertech-ps-00). If these fall short of explaining
>> what is the problem, then we need to do a better job.
>
> => As I said before draft-krishnan and Suresh's presentation in the BoF
> effectively say "don't do that". draft-jeyatharan falls under A) above. The
> problem with A) above is that PMIP was never designed to solve this problem.
> According to the NETLMM PS, and James Kempf's comments (and the NETLMM
> charter), this problem was supposed to be solved by MIPv6. So, to write a PS
> saying PMIP doesn't solve the problem is a rhetorical ps.
>
>>
>> Let me also say that justifications for creating a WG is not the main
>> driver. Far from it... I do agree that the IETF should charter work which is
>> useful and hence am hoping that through this discussion we will able to get
>> a better grasp on this set of topics over which there is a disagreement.
>> Rajeev also mentioned earlier that the intent is not to achieve parity in
>> terms of features supported by PMIP6.
>>
>> It would be useful to understand your PoV (might be challenging given the
>> CINR) as to why you believe there is no real PS.
>
> => I hope this helps. I'm happy to discuss these issues on the list because
> they're relevant. I don't think it's useful to discuss other "howto" threads
> so I'll stay away from them.
>
> Hesham
>
>>
>> -Raj
>>
>> On 4/8/09 5:03 PM, "ext Hesham Soliman" <hesham at elevatemobile.com> wrote:
>>
>>> Hi Raj,
>>>
>>>
>>> On 9/04/09 7:29 AM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
>>> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> There is an issue in the current debate that we should put to rest.
>>>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>>>> and inter-technology handovers (in addition to others over which there is
>>>> an agreement on).
>>>>
>>>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>>>> these capabilities currently. I dont think there is any debate about
>>>> that.
>>>> However there is an interested group of people within the IETF
>>>> community who would like to extend PMIP6 to support these features as
>>>> well.
>>>
>>> => Ok but without a PS, without justification, nothing? I mean if that's the
>>> case why have a BoF? Everyone keeps talking about the market needs. If this
>>> is the only reason for having these functions then we may as well send a
>>> business plan to Jari instead of having a BoF :). Market needs usually tell
>>> us the problem that needs to be solved, not *how* to solve it.
>>>
>>>> It is not uncommon in the IETF to have multiple competing protocols
>>>> provide similar functionality. The industry will ultimately choose an
>>>> appropriate solution depending on the needs. So I dont think we can
>>>> just quash the idea of working on these extensions simply because we
>>>> already have a protocol that does it.
>>>> It is also noted that one of the primary reasons for developing PMIP6
>>>> was to provide mobility without host involvement.
>>>
>>> => Yes but least for netlmm there was a PS and *some* technical arguments.
>>> Mostly bogus IMO but at least they took place. Here everyone is singing in
>>> concert about how to solve things and completely refusing to say why.
>>> Actually some people explicitly said that on the list.
>>>
>>> It's sad that this level of discussion is taking place to justify a WG.
>>> Remember the discussions you had to manage for PANA or other WGs you
>>> chaired? Very different. I think it's good that you're encouraging people to
>>> discuss the technical problems, and it's good that they're agreeing, but
>>> unfortunately it's not happening. That should tell us something...
>>>
>>> Hesham
>>>
>>>
>>
>
>
> _______________________________________________
> 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: Thu, 9 Apr 2009 06:23:24 +0200
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Ryuji,

Tough question :(

In principle I agree that we should attempt to use the work already done in
MEXT for MIP6. And given that PMIP6 itself is derived from MIP6 the add-on
features should follow as well.

However you simply cannot ignore the fact that with MIP6 the MN itself is
able to do signaling to control flows, or handovers etc. Given the
difference in the models and the intent to not involve the MN, it might not
be quite as simple to say that we will inherit and use the work already
done. 

There may be a need to do some adaptations. I don't know the answer really
because this goes into the solution space (and we are not there yet). I
agree with your view that we should take the same approach (as MIP6) to
provide such functionality.

-Raj  

On 4/8/09 4:52 PM, "ext Ryuji Wakikawa" <ryuji.wakikawa at gmail.com> wrote:

> Hi Raj,
> 
> Thanks for this. I agree on what you said in your mail.
> However, I want to ask one more clarification.
> 
> I don't want to go to MIP6 vs PMIP6 here, but some of extensions
> (multihoming, flow mobility,
> LMA redirection aka HAswithc?) are already covered by MIP6 in MEXT.
> When we need the similar features to PMIP,
> will NetEXT solution inherit MIP6 and MIP6-based-extension as RFC5213
> did?
> One of goal of RFC5213 was to inherit MIP6 spec as much as possible.
> 
> PMIP specific issues can be solved anyway, but some of common issues
> can be
> solved with the similar extensions to MIP6 or with another extensions
> to MIP6 extension.
> After PMIP6 deployment, we will have more common issues between MIP6
> and PMIP6.
> 
> It makes sense to take the same approach to solve the same goal at
> MIP6 and PMIP6.
> 
> regards,
> ryuji
> 
> 
> 
> On 2009/04/08, at 16:29, <Basavaraj.Patil at nokia.com>
> <Basavaraj.Patil at nokia.com
>> wrote:
> 
>> 
>> Hello,
>> 
>> There is an issue in the current debate that we should put to rest.
>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>> and inter-technology handovers (in addition to others over which
>> there is
>> an agreement on).
>> 
>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>> these capabilities currently. I dont think there is any debate about
>> that.
>> However there is an interested group of people within the IETF
>> community who would like to extend PMIP6 to support these features as
>> well.
>> It is not uncommon in the IETF to have multiple competing protocols
>> provide similar functionality. The industry will ultimately choose an
>> appropriate solution depending on the needs. So I dont think we can
>> just quash the idea of working on these extensions simply because we
>> already have a protocol that does it.
>> It is also noted that one of the primary reasons for developing PMIP6
>> was to provide mobility without host involvement. The term
>> "host-changes" in the context of the current discussion are still to a
>> large extent based on the PMIP6 intent. As long as we are not defining
>> a new protocol on the host, we can consider the host as being
>> unmodified (from this disucssions PoV).
>> 
>> In summary I would say that this is not a discussion about whether
>> host based Mobile IP (MIP6) is the appropriate protocol for providing
>> multihoming, Flow mobility and, inter-tech HOs but rather about what
>> can be done to provide similar capabilities to PMIP6 without (grossly)
>> changing the basic protocol principles.
>> 
>> -Raj
>> 
>> P.S: I recognize that some would say that inter-tech HOs and
>> multihoming are already features supported by PMIP6. In the current
>> context of Netext, what is being proposed is basically enhancements to
>> PMIP6 that address scenarios not currently in the base spec.
>> 
>> 
>> _______________________________________________
>> 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: Thu, 9 Apr 2009 06:14:49 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Sri,

On 4/8/09 5:35 PM, "Sri Gundavelli" <sgundave at cisco.com> wrote:

> Hi Gerardo,
>
>> What is the different between:
>> - the mobile sending a L2 message named "Attach Type" which triggers the PBU
>> and the HI included in it
>> - the mobile sending a L3 message named "Registration Request" or "Binding
>> Update"
>>
>
> Sure, there is a difference:
>
> - The mobile making a simple attach decision, vs doing all the
>    protocol work specified in MIPv6, DSMIP, IKE and IPsec specs.
>    Constant signaling, tunneling over the air link.
>
> - Building a Mobile IPv6 stack, IKEv2, IPsec, DSMIP6 stack on to
>    Windows, all variants of Linux, MAC OS/X .... zillion other
>    platforms and doing interop testing. Vs, building a simple
>    application for L2 triggers, or modifying client stack for the
>    same, the efforts are of different order.
>
> The simple L2 message, saves me from all the above.

Changing L2 is not an easy task given that most of the L2 stuff is in
silicon. It is easier to change things in an IP stack than to think that
changes to L2 can be made (especially in L2s that are already in use). As
Gerardo has said it is just not possible for example to change 802.11 or
802.16e today anymore. And the same applies for a lot of other L2s. So
punting the problem over to L2 is not really solving anything.

> And I
> cant convince Apple to bundle MIPv6 stack or atleast allow me to
> build it using their SDK.

I don't know why the IETF has to convince vendors to implement a protocol.
If they see a need or use for it they will do so. This has been the case
with MIP4, right? You don't find MIP4 in your garden variety OS. But it is
still implemented and deployed in certain networks today. There are ways of
how you can get around and build MIP6 support for a host even without
necessarily getting support from whatever SDK is available for that.

>
> So, there are differences. The pain points are different.

Yes, there is always a pain point :) But just saying that the pain point of
doing it in L2 is smaller is a misconception (IMHO).

-Raj

>
> Sri
>
>
>
>
>> To me the difference is just that IETF can work on (i.e. define, extend) the
>> latter but not on the former. And that the latter works on any L2 while the
>> former is tied to a particular technology.
>>
>> Gerardo
>>
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp]
>>> On Behalf Of Sri Gundavelli
>>> Sent: Wednesday, April 08, 2009 3:12 PM
>>> To: Domagoj Premec
>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] next steps for netext
>>>
>>> Hi Domagoj,
>>>
>>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>>
>>> For other scenarios of multi-attach, there can be policies
>>> on the network and the terminal, or a L2 signaling as you
>>> prefer, or an application signaling ..., but sure, there
>>> may be a need for the coordination between the terminal and
>>> the network. But, we cannot equate this requirement with
>>> the client-mobility requirement, with the mobile involved
>>> in signaling.
>>>
>>> Sri
>>>
>>>
>>>
>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>
>>>> Sri,
>>>>
>>>> What you're discribing is a specific type of deployment where the MN is
>>>> allowed to attach only through a single access at a time. But this prevents
>>>> multihoming and is not a generic solution. We need a generic solution that
>>>> works with any type of deployment without artifical restrictions.
>>>>
>>>> domagoj
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>>> Sent: 08. travanj 2009 23:47
>>>>> To: Domagoj Premec
>>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>>> Subject: RE: [Netext] next steps for netext
>>>>>
>>>>> Domagoj,
>>>>>
>>>>>
>>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>>
>>>>>> Sri,
>>>>>>
>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>
>>>>>> I disagree with this statement. In case of inter-tech handover, the
>>>>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>>>>> Handoff between two different interfaces of the mobile
>>>>> node". How does
>>>>>> the new MAG know that the attachment should be treated as a
>>>>> handover
>>>>>> and not as a new session? In the absence of any other
>>>>> indications, the
>>>>>> MAG will treat this as a new attachment, which results in
>>>>> multihoming
>>>>>> with a different prefix and no handover.
>>>>>>
>>>>>
>>>>> Can a deployment have terminals that only do single attach.
>>>>> Can that information be tied to the mobile's policy profile.
>>>>> Is it possible such information is available to the MAG ?
>>>>>
>>>>> Can AAA or other session manager have the awareness of the
>>>>> current existing session. Can the MAG leverage such
>>>>> information and derive if its a handover or a new attach ?
>>>>>
>>>>> So, its possible for the MAG to derive that information from
>>>>> the network, in many cases, including in 3GPP, as Vijay
>>>>> pointed out for single attach.
>>>>>
>>>>> Sri
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> domagoj
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>>>>> Gundavelli
>>>>>>> Sent: 08. travanj 2009 21:51
>>>>>>> To: Basavaraj.Patil at nokia.com
>>>>>>> Cc: netext at mail.mobileip.jp
>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>
>>>>>>> I agree, this discussion is going on a different track. This wont
>>>>>>> converge. Secondly, we are bundling every thing together
>>>>> and making
>>>>>>> blanket statements. There are statements,
>>>>> multi-homing/handover does
>>>>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
>>>>>>> there seems to be lot of assumptions around this, with out
>>>>> qualifying
>>>>>>> that, these statements are only creating confusion. Couple
>>>>> of points:
>>>>>>>
>>>>>>> - Multihoming is supported in PMIPv6
>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>> - None of these features break or burn the host.
>>>>>>>
>>>>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>>> some one
>>>>>>> from building an IPv6 enterprise mobility solution based on Proxy
>>>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
>>>>>>> that can be deployed in enterprise wireless architectures.
>>>>> No one can
>>>>>>> tell me, we cant deploy this protocol for solving micro mobility
>>>>>>> problems in an integrated wired/wireless AP environments,
>>>>> targetted
>>>>>>> for an enterprise.
>>>>>>>
>>>>>>>> From the list of proposed items, I'd really hope to identify the
>>>>>>>> work
>>>>>>> items that does not require extesive debates from the ones that
>>>>>>> requires fist-fighting.
>>>>>>>
>>>>>>> - Flow mobility has the scope from moving individual flows of
>>>>>>> interest with no relation to prefix, vs moving flows as a bundle
>>>>>>> associated to a prefix.
>>>>>>>
>>>>>>> - Host specific doc, from the point of view of leveraging
>>>>> what 5213
>>>>>>> supports, vs, for supporting the new features.
>>>>>>>
>>>>>>> - Multi-homing, binding a single prefix to multiple
>>>>> interfaces, vs,
>>>>>>> an individual prefix to each interface.
>>>>>>>
>>>>>>>
>>>>>>> We have to qualify the discussions around this, just the
>>>>> use of the
>>>>>>> key words multi-homing, inter-tech handovers, flow mobility, and
>>>>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>>>>> concern and does not help the discussions. We have to state which
>>>>>>> specific item has issues and under what scenario's.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Sri
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Lets try and keep this discussion focused on technical issues.
>>>>>>>> The current tone is not very encouraging in some instances.
>>>>>>>>
>>>>>>>> The current discussion is overly focused on what 3GPP is
>>>>>>> doing w.r.t
>>>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>>>>> protocols when
>>>>>>>> they see a good fit for their architecture and problem scope. We
>>>>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>>>>> instead rely on the IETF to deliver it.
>>>>>>>> They are free to do whatever they want.
>>>>>>>>
>>>>>>>> Within the IETF we can identify what problems or extensions
>>>>>>> to PMIP6
>>>>>>>> we want to work on and focus on these. If 3GPP finds the solution
>>>>>>>> applicable, they will use it. The IETF solution has to
>>>>> address the
>>>>>>>> generic problem and not tailored for 3GPP (which is what we
>>>>>>> seem to be doing now).
>>>>>>>> So maybe we can get down to discussing the problem and
>>>>>>> scenarios that
>>>>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>>>>
>>>>>>>> In order to make progress, I would suggest that we focus on the
>>>>>>>> following 3
>>>>>>>> topics:
>>>>>>>> A. Multihoming
>>>>>>>> B. Flow mobility
>>>>>>>> C. Inter technology handovers
>>>>>>>>
>>>>>>>> If we can articulate the scenarios and associated problems
>>>>>>> with each
>>>>>>>> of the same, we can then get a better handle on what to
>>>>> take on in
>>>>>>>> Netext. And lets not start saying that we already have a
>>>>>>> solution in I-Dx or I-Dy.
>>>>>>>>
>>>>>>>> -Raj
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>>>>> <vijay at wichorus.com> wrote:
>>>>>>>>
>>>>>>>>> Hi George,
>>>>>>>>>
>>>>>>>>> George Tsirtsis wrote:
>>>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>>>>> <vijay at wichorus.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Gerardo,
>>>>>>>>>>>
>>>>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>>>>> solutions proposed on any I-D - there is a
>>>>>>> 3GPP-specific solution
>>>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>>>>
>>>>>>>>>>> This is exactly what I would like to avoid. I would
>>>>>>> prefer using a
>>>>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>>>>> technology for
>>>>>>>>>> almost as long as the IETF. Getting the IETF to do
>>>>> something only
>>>>>>>>>> makes sense if the given protocol has general
>>>>>>> applicability and does
>>>>>>>>>> not damage the Internet, which is why we are having this
>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>>>>> very little
>>>>>>>>> modifications. They have added some vendor specific options for
>>>>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>>>>> PMIPv6, it
>>>>>>>>> doesn't make sense for them to develop a solution on their
>>>>>>> own. It should be done in the IETF.
>>>>>>>>>
>>>>>>>>> And can we please stop the hyperbole about "damaging the
>>>>>>> Internet"?
>>>>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>>>>
>>>>>>>>>> GT> In another e-mail where you are over-viewing a
>>>>>>> possible solution
>>>>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>>>>>>> signal to indicate what flows need to go to a given
>>>>> MAG. I do not
>>>>>>>>>> see how the IETF can define a protocol that fully depends
>>>>>>> on such an
>>>>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>>>>> must define
>>>>>>>>>> it at the IP layer to make sure that this works across ALL link
>>>>>>>>>> layers (which is the main reason the IETF and the
>>>>> Internet exist).
>>>>>>>>>
>>>>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>>>>> So I don't
>>>>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>>>>
>>>>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>>>>> does not
>>>>>>>>> indicate the service identifier. Please see
>>>>>>>>>
>>>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>>>>
>>>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>>>>> hurdles to overcome:
>>>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>>>>> to define
>>>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>>>>
>>>>>>>>> That is one option, but not required.
>>>>>>>>>
>>>>>>>>> Vijay
>>>>>>>>>
>>>>>>>>>> 2) Convince people that defining such a client based
>>>>> protocol in
>>>>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>>>>>>> process, explain to people why you want to introduce FA
>>>>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>>>>
>>>>>>>>>> George
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Vijay
>>>>>>>>>>>
>>>>>>>>>>>> 3GPP has not decided yet to do any normative work on
>>>>> any of the
>>>>>>>>>>>> solutions.
>>>>>>>>>>>>
>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>>>>> netext at mail.mobileip.jp;
>>>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>>>>> list, sorry for that
>>>>>>>>>>>> :-)
>>>>>>>>>>>>
>>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>>>>> function though.
>>>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>>>>> basis for the
>>>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>>>>> claim not backed
>>>>>>>>>>>> by 3GPP.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>>>>> (discussed at the
>>>>>>>>>>>> last
>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>> working.
>>>>>>>>>>>>
>>>>>>>>>>>> Such
>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>>>>> PMIP6 so we
>>>>>>>>>>>> shouldn't
>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>
>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>>>>> note that I am
>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>>>>> homogeneous from a
>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>
>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>
>>>>>>>>>>>> Saying to use MIP for inter-access
>>>>>>> handovers/multihoming is
>>>>>>>>>>>> not helping as they have
>>>>>>>>>>>> really set their mind
>>>>>>>>>>>> on
>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>>>>> going into the
>>>>>>>>>>>> reasoning
>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>>>>> defined in RFC 5213,
>>>>>>>>>>>> has
>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>>>>> better to fix those
>>>>>>>>>>>> PMIP6
>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>>>>> their own way of
>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>
>>>>>>>>>>>> domagoj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>>>>> Behalf Of ext
>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => We're discussing a problem statement for
>>>>> the BoF, so
>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>> appropriate as a reference for why people
>>>>> wanted PMIP in
>>>>>>>>>>>> the first place.
>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>> network-based
>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>>>>> use cases.
>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>
>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>>>>> host-based mobility
>>>>>>>>>>>> protocol again.
>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>>>>> discussion
>>>>>>>>>>>> and this discussion on the list. The reason I
>>>>> don't know
>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>> saying:
>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>>>>> and PMIP)
>>>>>>>>>>>> and here is why they don't work, therefore we
>>>>> need to do
>>>>>>>>>>>> something new.
>>>>>>>>>>>> That's what a PS should say. What's being said
>>>>>>> here is "PMIP
>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>>>>> something
>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>> something else for supporting those cases. Hence
>>>>>>> my reference to 4830...
>>>>>>>>>>>>
>>>>>>>>>>>> I'm going to retire from the discussion till
>>>>>>> someone makes
>>>>>>>>>>>> the argument above. Because I feel that if there
>>>>>>> is no such
>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => Yes, additional software like the existing
>>>>>>> MIP. I don't
>>>>>>>>>>>> understand
>>>>>>>>>>>> the motivation for creating something new.
>>>>> I've detailed
>>>>>>>>>>>> this in my
>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>
>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>>>>> management
>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>>>>> seems to be a
>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>>>>> talking about
>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>> marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>
>>>>>>>>>>>> distinguish modification for mobility
>>>>> management, which
>>>>>>>>>>>> is not what
>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>>>>> as the use of
>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>>>>> configure
>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>
>>>>>>>>>>>> marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>> unmodified
>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>>>>> the BoF, our
>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>> the host
>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>>>>> stick with MIP.
>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>> is not a
>>>>>>>>>>>> good way to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>>>>> this is such a
>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>>>>> room was in
>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>> raised for the
>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>> and intertech
>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => I think the question changed a few times
>>>>> :) The final
>>>>>>>>>>>> question
>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>> with this or
>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>>>>> mentioned here
>>>>>>>>>>>> because they were one of the very few reasons
>>>>> for using
>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>>>>> the host) and
>>>>>>>>>>>> signalling from the MN. You can see them in
>>>>> section 4 of
>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>> relying on a
>>>>>>>>>>>> solution that will:
>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>>>>> anyway. However if
>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>>>>> not specify how
>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>>>>> in all L2s,
>>>>>>>>>>>> doesn't require
>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>> confusing host
>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>> is not done
>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>> or config?
>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>> in the IETF
>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>>>>> changes to SW etc.
>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>>>>> These were the
>>>>>>>>>>>> reasons for
>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>> ways, or can
>>>>>>>>>>>> we? :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>>>>> scope in IETF
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>>>>> could specify
>>>>>>>>>>>> (informatively)
>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>>>>> if that is the
>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => We can, but I don't know why we should do
>>>>> that when a
>>>>>>>>>>>> solution
>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>>>>> is inferior in
>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -Raj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>> comments.
>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>> basic handoff
>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>>>>> mostly flow
>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>> Sri
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Thu, 9 Apr 2009 06:05:11 +0200
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Hesham,

I have seen you asking for a problem statement in several emails now and
none has been forthcoming so far. So let me try to understand your view:

Netext proposes to extend PMIP6 to support flow mobility, address several
multihoming scenarios and, support intertechnology handovers.

Are you asking why we need to work on these features for PMIP6? Obviously
from the perspective of protocols specified in the IETF, we do recognize
that multihoming, flow mobility and intertechnology handovers can be
provided by Mobile IPv6. So are you of the opinion that given the
availability of a solution in the IETF for these problems there is no need
to work on these?

If the question is about what is the problem w.r.t multihoming in the case
of PMIP6 and respectively other features as well, please do review the PS
I-Ds ( draft-jeyatharan-netext-multihoming-ps-01,
draft-krishnan-netext-intertech-ps-00). If these fall short of explaining
what is the problem, then we need to do a better job.

Let me also say that justifications for creating a WG is not the main
driver. Far from it... I do agree that the IETF should charter work which is
useful and hence am hoping that through this discussion we will able to get
a better grasp on this set of topics over which there is a disagreement.
Rajeev also mentioned earlier that the intent is not to achieve parity in
terms of features supported by PMIP6.

It would be useful to understand your PoV (might be challenging given the
CINR) as to why you believe there is no real PS.

-Raj

On 4/8/09 5:03 PM, "ext Hesham Soliman" <hesham at elevatemobile.com> wrote:

> Hi Raj,
> 
> 
> On 9/04/09 7:29 AM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
> wrote:
> 
>> 
>> Hello,
>> 
>> There is an issue in the current debate that we should put to rest.
>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>> and inter-technology handovers (in addition to others over which there is
>> an agreement on).
>> 
>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>> these capabilities currently. I dont think there is any debate about
>> that.
>> However there is an interested group of people within the IETF
>> community who would like to extend PMIP6 to support these features as
>> well.
> 
> => Ok but without a PS, without justification, nothing? I mean if that's the
> case why have a BoF? Everyone keeps talking about the market needs. If this
> is the only reason for having these functions then we may as well send a
> business plan to Jari instead of having a BoF :). Market needs usually tell
> us the problem that needs to be solved, not *how* to solve it.
> 
>> It is not uncommon in the IETF to have multiple competing protocols
>> provide similar functionality. The industry will ultimately choose an
>> appropriate solution depending on the needs. So I dont think we can
>> just quash the idea of working on these extensions simply because we
>> already have a protocol that does it.
>> It is also noted that one of the primary reasons for developing PMIP6
>> was to provide mobility without host involvement.
> 
> => Yes but least for netlmm there was a PS and *some* technical arguments.
> Mostly bogus IMO but at least they took place. Here everyone is singing in
> concert about how to solve things and completely refusing to say why.
> Actually some people explicitly said that on the list.
> 
> It's sad that this level of discussion is taking place to justify a WG.
> Remember the discussions you had to manage for PANA or other WGs you
> chaired? Very different. I think it's good that you're encouraging people to
> discuss the technical problems, and it's good that they're agreeing, but
> unfortunately it's not happening. That should tell us something...
> 
> Hesham
> 
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Thu, 09 Apr 2009 14:21:00 +1100
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj, 

Thank you for responding to my question! I'm glad someone is listening.

On 9/04/09 3:05 PM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
wrote:

> 
> Hi Hesham,
> 
> I have seen you asking for a problem statement in several emails now and
> none has been forthcoming so far. So let me try to understand your view:
> 
> Netext proposes to extend PMIP6 to support flow mobility, address several
> multihoming scenarios and, support intertechnology handovers.
> 
> Are you asking why we need to work on these features for PMIP6? Obviously
> from the perspective of protocols specified in the IETF, we do recognize
> that multihoming, flow mobility and intertechnology handovers can be
> provided by Mobile IPv6. So are you of the opinion that given the
> availability of a solution in the IETF for these problems there is no need
> to work on these?

=> No. Here is what I think in the abstract and how it applies to this
particular case. A problem statement should explain the problem, discuss the
state of the art, then show why the state of the art doesn't solve the
problem. Based on this, one can conclude one of two things:
1. We need to modify the state of the art to solve the problem, or,
2. We need something new because modifying the above is not going to work
(for many possible reasons).

The choice between 1) and 2) obviously involves a solution space discussion
once the problem is defined.
For this BoF, this means:
- Define the problem: a host needs to to able to send/receive packets on
multiple interfaces ....etc, deployment issues, ....etc
- Explain why the state of the art is not sufficient: PMIP doesn't solve
this because..., MIP doesn't solve this because ... Something else....etc

Then we can see real reasons for deciding to go one way or another. Of
course what happened so far is that people essentially say one of three
things:
A. PMIP doesn't solve this so we need something (completely ignoring MIP),
or,
B. MIP solves this but there must be more than one way of doing it, or,
C. There is an unofficial, unstated requirement from SDOs that we must
fullfil without discussion.

A) is obviously incomplete, B) is utter nonsense and C) is dangerous.

> 
> If the question is about what is the problem w.r.t multihoming in the case
> of PMIP6 and respectively other features as well, please do review the PS
> I-Ds ( draft-jeyatharan-netext-multihoming-ps-01,
> draft-krishnan-netext-intertech-ps-00). If these fall short of explaining
> what is the problem, then we need to do a better job.

=> As I said before draft-krishnan and Suresh's presentation in the BoF
effectively say "don't do that". draft-jeyatharan falls under A) above. The
problem with A) above is that PMIP was never designed to solve this problem.
According to the NETLMM PS, and James Kempf's comments (and the NETLMM
charter), this problem was supposed to be solved by MIPv6. So, to write a PS
saying PMIP doesn't solve the problem is a rhetorical ps.

> 
> Let me also say that justifications for creating a WG is not the main
> driver. Far from it... I do agree that the IETF should charter work which is
> useful and hence am hoping that through this discussion we will able to get
> a better grasp on this set of topics over which there is a disagreement.
> Rajeev also mentioned earlier that the intent is not to achieve parity in
> terms of features supported by PMIP6.
> 
> It would be useful to understand your PoV (might be challenging given the
> CINR) as to why you believe there is no real PS.

=> I hope this helps. I'm happy to discuss these issues on the list because
they're relevant. I don't think it's useful to discuss other "howto" threads
so I'll stay away from them.

Hesham

> 
> -Raj
> 
> On 4/8/09 5:03 PM, "ext Hesham Soliman" <hesham at elevatemobile.com> wrote:
> 
>> Hi Raj,
>> 
>> 
>> On 9/04/09 7:29 AM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
>> wrote:
>> 
>>> 
>>> Hello,
>>> 
>>> There is an issue in the current debate that we should put to rest.
>>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>>> and inter-technology handovers (in addition to others over which there is
>>> an agreement on).
>>> 
>>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>>> these capabilities currently. I dont think there is any debate about
>>> that.
>>> However there is an interested group of people within the IETF
>>> community who would like to extend PMIP6 to support these features as
>>> well.
>> 
>> => Ok but without a PS, without justification, nothing? I mean if that's the
>> case why have a BoF? Everyone keeps talking about the market needs. If this
>> is the only reason for having these functions then we may as well send a
>> business plan to Jari instead of having a BoF :). Market needs usually tell
>> us the problem that needs to be solved, not *how* to solve it.
>> 
>>> It is not uncommon in the IETF to have multiple competing protocols
>>> provide similar functionality. The industry will ultimately choose an
>>> appropriate solution depending on the needs. So I dont think we can
>>> just quash the idea of working on these extensions simply because we
>>> already have a protocol that does it.
>>> It is also noted that one of the primary reasons for developing PMIP6
>>> was to provide mobility without host involvement.
>> 
>> => Yes but least for netlmm there was a PS and *some* technical arguments.
>> Mostly bogus IMO but at least they took place. Here everyone is singing in
>> concert about how to solve things and completely refusing to say why.
>> Actually some people explicitly said that on the list.
>> 
>> It's sad that this level of discussion is taking place to justify a WG.
>> Remember the discussions you had to manage for PANA or other WGs you
>> chaired? Very different. I think it's good that you're encouraging people to
>> discuss the technical problems, and it's good that they're agreeing, but
>> unfortunately it's not happening. That should tell us something...
>> 
>> Hesham
>> 
>> 
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 9 Apr 2009 09:43:15 +0800
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Behcet,

Well, if MN does not want any advanced features but wants basic IP connectivity while moving, then these MN's can remain. However, if they want
Advanced featrues, then they need chnages. I think the question is the degree. I think this should be very minimal.

I hope you agree.

BR,
Mohana

________________________________________
From: Behcet Sarikaya [mailto:behcetsarikaya at yahoo.com] 
Sent: Wednesday, April 08, 2009 10:20 PM
To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext

Hi Mohana,
? Pls find a little comment below.
Regards,
?
Behcet
________________________________________
From: Mohana Jeyatharan <Mohana.Jeyatharan at sg.panasonic.com>
To: "Koodli, Rajeev" <rkoodli at starentnetworks.com>; netext at mail.mobileip.jp
Sent: Wednesday, April 8, 2009 12:41:49 AM
Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext

Hi Rajeev and All,

I like the summary you have put forward here. As you have mentioned and many others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
Currently we have a scenario where the MN MUST use PMIPv6 for mobility management for its multiple interfaces. I do not want to quote SDO, but
3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or s2b(WLAN) interface. Then if this MN wants multihoming, flow mobility etc, how can we do this? Are we going to run MIP6 ony for multihoimg purpose, on top of PMIP being used in corenetwork. Is this a good idea or are we going to do major multihoming work in MAG-LMA path and do some minor modifications to MN to keep it light weight as far as protocol modification is concerned. The second option seems more logical for pure PMIpv6 scenario. Reason is: operator may not allov two mobility manamgement protocols running just to achieve multihoming and what if the MN does not have MIP6 stack implemented. 
?
[behcet] Then this simple question comes to one's mind: what if MN does not have these some minor modifications to MN??you mentioned above? 
How do we interoperate these MNs?

For scenarios where MIP6 is used to handle mobility for all interfaces, then client based multihoming given as extensions of MIP6 is excellent. No one can deny this. For mixed scenarios such as PMIP and CMIP scenarios involving multiple inetrafces, then again probably MIP6 based multihoming may be ideal. This is something we need to explore as well.

But our discussion currently at Netext is, operator decides PMIPv6 for all interfaces and what solution do we have for multihoming and flow mobility? I think we should think along these lines. Is this PMIPv6 multihoming solution identical to MIP6 Multihoming solution. I don't think so. So we need to look at some drafts available that handles PMIPv6 multihoming and flow mobility and see the changes in UE and some functional modules introduced in architectural entities, to understand the differences. If same then no need of any new work. If different then need to look at benefits. Can we reduce signaling in MN-AR interface, can we make the protocol chnages of a leagcy MN minimal, can we reduce core network signaling. All such criteria need to be taken into account for comparision.

Well if the operator does not mind CMIP running over PMIP fine and good. 
But, what if not....

Thanks.
BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> Sent: Wednesday, April 08, 2009 7:46 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> 
> 
> Folks,
> 
> Let's step back a bit..It doesn't help to pit one protocol against another
> like this, especially when they are both developed by us :-)
> 
> If the problem is well-understood - i.e., how to selectively move flows
> across interfaces for MIP, the same problem is being investigated here for
> PMIP6. Why? With multiple interfaces, there seems to be interest in this
> (so-called flow mobility). How will this work? We don't know yet, we don't
> have a standards spec, but there are a few drafts. We are only setting the
> stage for solution(s).
> 
> Given this, we should try to focus on investigating the problem and
> agreeing on how to go about working on a protocol specification. People
> already know they could use MIP6 for this. We could re-state it surely,
> but that cannot be the only approach.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> > Sent: Tuesday, April 07, 2009 3:27 PM
> > To: Vijay Devarapalli
> > Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next
> > steps for netext
> >
> >
> >
> >
> > On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >
> > > Hesham Soliman wrote:
> > >> I don't know which people you're talking about or on which planet
> > >> this stuff is being deployed.
> > >
> > > Thats easy. Search for "LTE HRPD" at google.com. :)
> > >
> > >> In any case, I'm interested in discussing technical
> > aspects of this
> > >> work and I have zero interest in politics and projections.
> > >
> > > But I don't see that. You seem to want to tell people to use Mobile
> > > IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> >
> > => I'm not *telling* people to do it, I'm arguing that this
> > is the best approach. All I'm getting back is "SDOx want
> > this" and "people want this"
> > and "the ship has sailed". It's very frustrating to have a
> > discussion like this instead of showing a real PS.
> >
> > >
> > > FWIW, the way I see it, the flow mobility solution for
> > PMIPv6 does not
> > > have to be that different from what we have for MIPv6.
> > Instead of the
> > > mobile node sending the service selection option (defined
> > in RFC 5149)
> > > and flow identification option in the BU, it?s the MAG that
> > sends this
> > > information in the PBU. The solution is the same. You tell
> > the HA or
> > > the LMA which flow filters to install.
> > >
> > > The solution could be along the lines I wrote in section 3.3 of
> > > draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > Nov 2007).
> > > It says
> >
> > => If there is a solution to be had I don't care whether it
> > uses our draft or something new. My point is that making
> > those decisions in the network just doesn't work. Yes there
> > bits on the wire that can do anything but the decision to
> > trigger these actions in the network is flawed.. And without
> > getting into too much detail, before we decide to go one way
> > or another, I think a technical argument needs to be made
> > about "why" it's needed and not "how" it might work. This
> > might sound old-fashioned these days but I find it difficult
> > to rubber stamp things without understanding why.
> > This is all I'm going to say about this BoF unless someone
> > has a PS to discuss.
> >
> > Hesham
> >
> > >
> > >? ? For this scenario to work, the mobile node must be able
> > to indicate
> > >? ? to the attached MAG which flow will be sent over the
> > attachment to
> > >? ? the MAG.? It may do this by indicating the service
> > identifer during
> > >? ? the layer 2 attachment to the MAG.? The service identifier is
> > >? ? described in [4].? The MAG, in turn must include the
> > flow information
> > >? ? in the Proxy Binding Update sent to the LMA.? The MAG
> > may use the
> > >? ? Service Selection option [4] in the Proxy Binding
> > Update to indicate
> > >? ? the flow information.? The MAG may also contruct a flow
> > filter and
> > >? ? convey the information in the Proxy Binding Update.
> > See [3] for more
> > >? ? information on carrying flow filters in the proxy
> > binding update.
> > >
> > >? ? The LMA processes the Proxy Binding Update from the MAG
> > and creates a
> > >? ? filter based on the flow information.? The flow filters
> > may be stored
> > >? ? in the binding cache entry for the mobile node.
> > >
> > >? ? [3]? Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> > >? ? ? ? ? Support", draft-soliman-monami6-flow-binding-04 (work in
> > >? ? ? ? ? progress), March 2007.
> > >
> > >? ? [4]? Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > >? ? ? ? ? Selection for Mobile IPv6",
> > draft-korhonen-mip6-service-04 (work
> > >? ? ? ? ? in progress), October 2007.
> > >
> > > [4] got published as RFC 5149.
> > >
> > > Anyway, I don't think we should get into discussing
> > solutions at this
> > > point. The above is to just show that the MIPv6 solutions can be
> > > re-used for PMIPv6. We don't have to re-invent what we have
> > done in the IETF so far.
> > >
> > > I would prefer that we let the market decide whether they
> > want to go
> > > with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > or PMIPv6.
> > > that would be a political discussion. :)
> > >
> > > Vijay
> > >
> > >>
> > >> Hesham
> > >>
> > >>
> > >> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>
> > >>> George, Hesham,
> > >>>
> > >>> I don't see the point in having philosophical discussions
> > on whether
> > >>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > point. That
> > >>> ship has sailed. What we have as a reality is folks deploying
> > >>> systems with inter access technology handovers with PMIPv6 as the
> > >>> mobility management protocol. Asking these folks to now
> > use Mobile
> > >>> IPv6 does not help anyone, IMHO.
> > >>>
> > >>> Vijay
> > >>>
> > >>
> > >>
> > >
> >
> >
> >
> > _______________________________________________
> > 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

_______________________________________________
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: Thu, 9 Apr 2009 09:24:26 +0800
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

Thanks for your reply. Please see reply in-line.

BR,
Mohana

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:gerardog at qualcomm.com]
> Sent: Wednesday, April 08, 2009 10:12 PM
> To: Mohana Jeyatharan; Hesham Soliman; Koodli, Rajeev;
> netext at mail.mobileip.jp
> Subject: RE: [Netext] Keep missing the point .. Re: next steps for netext
> 
> Hi Mohana,
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp]
> > On Behalf Of Mohana Jeyatharan
> > Sent: Wednesday, April 08, 2009 12:36 AM
> > To: Hesham Soliman; Koodli, Rajeev; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> netext
> >
> > Hi,
> >
> > What I meant is a legacy MN attaching via multiple interfaces, then the
> > default mechansim is GTP/PMIP via LTE and PMIP via non-3GP. Reference TS
> > 23.401, TS 23.402. This is why I mentioned must for such MNs.
> >
> 
> Uhm, this sounds at least weird to me. How can a legacy MN supports LTE?

What I meant is MN that does not have a client stack to handle mobility managemnt. Anyway, you would know better, but from what I have read,
the S-GW-P-GW interface is common to UTRAN, GERAN, HRPD access. All IP traffic via this interface. So it is not only LTE terminals but legacy terminals that have been there for couple of years.

> Based on TS 23.402, the support of PMIPv6 for inter-technology handovers
> and the support of DSMIPv6 are both optional in the MN/UE.
> 
> If the MN/UE does not support either PMIPv6 for inter-technology handovers
> or DSMIPv6, then PMIPv6 is used for basic connectivity but no IP address
> preservation is provided.

You are right. The session continuity is a configurable parameter. If needed then DSMIP or PMIP should support this. DSMIP can use BU and PMIP also has this HI flag=2. That is seemless handoff during inter technology switching.

> Gerardo
> 
> PS: Yes, 3GPP recognized about two years ago that a MN needs to support
> something new to support inter-system handovers with PMIPv6
> 
> > If MN has CMIP, then the 3GPP spec TS 23.402 says the MN can possibly
> > negotiate a preferred mobility management mode or in some static
> configuration
> > the network may decide on the mobility mode. In this case, ok, CMIP can
> be
> > used if the operator allows it.
> >
> >
> > So I was just focusing on the first part.
> >
> > BR,
> > Mohana
> >
> > > -----Original Message-----
> > > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > > Sent: Wednesday, April 08, 2009 2:06 PM
> > > To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> netext
> > >
> > >
> > >
> > >
> > > On 8/04/09 4:41 PM, "Mohana Jeyatharan"
> > > <Mohana.Jeyatharan at sg.panasonic.com>
> > > wrote:
> > >
> > > > Hi Rajeev and All,
> > > >
> > > > I like the summary you have put forward here. As you have mentioned
> and
> > > many
> > > > others in the ML, this discussion is not about MIP6 , PMIPv6
> comparison.
> > > > Currently we have a scenario where the MN MUST use PMIPv6 for
> mobility
> > > > management for its multiple interfaces. I do not want to quote SDO,
> but
> > > > 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX)
> or
> > > > s2b(WLAN) interface.
> > >
> > > => If you're going to say "MUST" then yes you must quote that
> requirement.
> > > If it came from an SDO then please send us a reference to that. Other
> 3GPP
> > > people don't agree with you and stated that publicly on the list.
> > >
> > > Hesham
> > >
> > > Then if this MN wants multihoming, flow mobility etc, how
> > > > can we do this? Are we going to run MIP6 ony for multihoimg purpose,
> on
> > > top of
> > > > PMIP being used in corenetwork. Is this a good idea or are we going
> to
> > > do
> > > > major multihoming work in MAG-LMA path and do some minor
> modifications
> > > to MN
> > > > to keep it light weight as far as protocol modification is
> concerned.
> > > The
> > > > second option seems more logical for pure PMIpv6 scenario. Reason
> is:
> > > operator
> > > > may not allov two mobility manamgement protocols running just to
> achieve
> > > > multihoming and what if the MN does not have MIP6 stack implemented.
> > > >
> > > > For scenarios where MIP6 is used to handle mobility for all
> interfaces,
> > > then
> > > > client based multihoming given as extensions of MIP6 is excellent.
> No
> > > one can
> > > > deny this. For mixed scenarios such as PMIP and CMIP scenarios
> involving
> > > > multiple inetrafces, then again probably MIP6 based multihoming may
> be
> > > ideal.
> > > > This is something we need to explore as well.
> > > >
> > > > But our discussion currently at Netext is, operator decides PMIPv6
> for
> > > all
> > > > interfaces and what solution do we have for multihoming and flow
> > > mobility? I
> > > > think we should think along these lines. Is this PMIPv6 multihoming
> > > solution
> > > > identical to MIP6 Multihoming solution. I don't think so. So we need
> to
> > > look
> > > > at some drafts available that handles PMIPv6 multihoming and flow
> > > mobility and
> > > > see the changes in UE and some functional modules introduced in
> > > architectural
> > > > entities, to understand the differences. If same then no need of any
> new
> > > work.
> > > > If different then need to look at benefits. Can we reduce signaling
> in
> > > MN-AR
> > > > interface, can we make the protocol chnages of a leagcy MN minimal,
> can
> > > we
> > > > reduce core network signaling. All such criteria need to be taken
> into
> > > account
> > > > for comparision.
> > > >
> > > > Well if the operator does not mind CMIP running over PMIP fine and
> good.
> > > > But, what if not....
> > > >
> > > > Thanks.
> > > > BR,
> > > > Mohana
> > > >
> > > >> -----Original Message-----
> > > >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> > > >> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> > > >> Sent: Wednesday, April 08, 2009 7:46 AM
> > > >> To: netext at mail.mobileip.jp
> > > >> Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> > > netext
> > > >>
> > > >>
> > > >>
> > > >> Folks,
> > > >>
> > > >> Let's step back a bit..It doesn't help to pit one protocol against
> > > another
> > > >> like this, especially when they are both developed by us :-)
> > > >>
> > > >> If the problem is well-understood - i.e., how to selectively move
> flows
> > > >> across interfaces for MIP, the same problem is being investigated
> here
> > > for
> > > >> PMIP6. Why? With multiple interfaces, there seems to be interest in
> > > this
> > > >> (so-called flow mobility). How will this work? We don't know yet,
> we
> > > don't
> > > >> have a standards spec, but there are a few drafts. We are only
> setting
> > > the
> > > >> stage for solution(s).
> > > >>
> > > >> Given this, we should try to focus on investigating the problem and
> > > >> agreeing on how to go about working on a protocol specification.
> People
> > > >> already know they could use MIP6 for this. We could re-state it
> surely,
> > > >> but that cannot be the only approach.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> -Rajeev
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: netext-bounces at mail.mobileip.jp
> > > >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham
> Soliman
> > > >>> Sent: Tuesday, April 07, 2009 3:27 PM
> > > >>> To: Vijay Devarapalli
> > > >>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > > >>> Subject: Re: [Netext] Keep missing the point .. Re: next
> > > >>> steps for netext
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com>
> wrote:
> > > >>>
> > > >>>> Hesham Soliman wrote:
> > > >>>>> I don't know which people you're talking about or on which
> planet
> > > >>>>> this stuff is being deployed.
> > > >>>>
> > > >>>> Thats easy. Search for "LTE HRPD" at google.com. :)
> > > >>>>
> > > >>>>> In any case, I'm interested in discussing technical
> > > >>> aspects of this
> > > >>>>> work and I have zero interest in politics and projections.
> > > >>>>
> > > >>>> But I don't see that. You seem to want to tell people to use
> Mobile
> > > >>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> > > >>>
> > > >>> => I'm not *telling* people to do it, I'm arguing that this
> > > >>> is the best approach. All I'm getting back is "SDOx want
> > > >>> this" and "people want this"
> > > >>> and "the ship has sailed". It's very frustrating to have a
> > > >>> discussion like this instead of showing a real PS.
> > > >>>
> > > >>>>
> > > >>>> FWIW, the way I see it, the flow mobility solution for
> > > >>> PMIPv6 does not
> > > >>>> have to be that different from what we have for MIPv6.
> > > >>> Instead of the
> > > >>>> mobile node sending the service selection option (defined
> > > >>> in RFC 5149)
> > > >>>> and flow identification option in the BU, it?s the MAG that
> > > >>> sends this
> > > >>>> information in the PBU. The solution is the same. You tell
> > > >>> the HA or
> > > >>>> the LMA which flow filters to install.
> > > >>>>
> > > >>>> The solution could be along the lines I wrote in section 3.3 of
> > > >>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > > >>> Nov 2007).
> > > >>>> It says
> > > >>>
> > > >>> => If there is a solution to be had I don't care whether it
> > > >>> uses our draft or something new. My point is that making
> > > >>> those decisions in the network just doesn't work. Yes there
> > > >>> bits on the wire that can do anything but the decision to
> > > >>> trigger these actions in the network is flawed. And without
> > > >>> getting into too much detail, before we decide to go one way
> > > >>> or another, I think a technical argument needs to be made
> > > >>> about "why" it's needed and not "how" it might work. This
> > > >>> might sound old-fashioned these days but I find it difficult
> > > >>> to rubber stamp things without understanding why.
> > > >>> This is all I'm going to say about this BoF unless someone
> > > >>> has a PS to discuss.
> > > >>>
> > > >>> Hesham
> > > >>>
> > > >>>>
> > > >>>>     For this scenario to work, the mobile node must be able
> > > >>> to indicate
> > > >>>>     to the attached MAG which flow will be sent over the
> > > >>> attachment to
> > > >>>>     the MAG.  It may do this by indicating the service
> > > >>> identifer during
> > > >>>>     the layer 2 attachment to the MAG.  The service identifier is
> > > >>>>     described in [4].  The MAG, in turn must include the
> > > >>> flow information
> > > >>>>     in the Proxy Binding Update sent to the LMA.  The MAG
> > > >>> may use the
> > > >>>>     Service Selection option [4] in the Proxy Binding
> > > >>> Update to indicate
> > > >>>>     the flow information.  The MAG may also contruct a flow
> > > >>> filter and
> > > >>>>     convey the information in the Proxy Binding Update.
> > > >>> See [3] for more
> > > >>>>     information on carrying flow filters in the proxy
> > > >>> binding update.
> > > >>>>
> > > >>>>     The LMA processes the Proxy Binding Update from the MAG
> > > >>> and creates a
> > > >>>>     filter based on the flow information.  The flow filters
> > > >>> may be stored
> > > >>>>     in the binding cache entry for the mobile node.
> > > >>>>
> > > >>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo
> Basic
> > > >>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
> > > >>>>          progress), March 2007.
> > > >>>>
> > > >>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > > >>>>          Selection for Mobile IPv6",
> > > >>> draft-korhonen-mip6-service-04 (work
> > > >>>>          in progress), October 2007.
> > > >>>>
> > > >>>> [4] got published as RFC 5149.
> > > >>>>
> > > >>>> Anyway, I don't think we should get into discussing
> > > >>> solutions at this
> > > >>>> point. The above is to just show that the MIPv6 solutions can be
> > > >>>> re-used for PMIPv6. We don't have to re-invent what we have
> > > >>> done in the IETF so far.
> > > >>>>
> > > >>>> I would prefer that we let the market decide whether they
> > > >>> want to go
> > > >>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > > >>> or PMIPv6.
> > > >>>> that would be a political discussion. :)
> > > >>>>
> > > >>>> Vijay
> > > >>>>
> > > >>>>>
> > > >>>>> Hesham
> > > >>>>>
> > > >>>>>
> > > >>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com>
> wrote:
> > > >>>>>
> > > >>>>>> George, Hesham,
> > > >>>>>>
> > > >>>>>> I don't see the point in having philosophical discussions
> > > >>> on whether
> > > >>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > > >>> point. That
> > > >>>>>> ship has sailed. What we have as a reality is folks deploying
> > > >>>>>> systems with inter access technology handovers with PMIPv6 as
> the
> > > >>>>>> mobility management protocol. Asking these folks to now
> > > >>> use Mobile
> > > >>>>>> IPv6 does not help anyone, IMHO.
> > > >>>>>>
> > > >>>>>> Vijay
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> 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
> > > >
> > > > _______________________________________________
> > > > 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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 15:47:39 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Gerardo,

Have these items in two columns and do your
comparisions. We wont converge, as we have
different goals. But, we both know the answer,
and its the same.

Any case, as Raj pointed out, lets move away
from the client-based vs network-based mobility
debate. I truely believe, both are needed, its
not the battle for one. But, I've a problem if
we restrict one from feature addition.

Regards
Sri

On Wed, 8 Apr 2009, Giaretta, Gerardo wrote:

>>
>> Hi Gerardo,
>>
>>> What is the different between:
>>> - the mobile sending a L2 message named "Attach Type" which triggers the PBU
>> and the HI included in it
>>> - the mobile sending a L3 message named "Registration Request" or "Binding
>> Update"
>>>
>>
>> Sure, there is a difference:
>>
>> - The mobile making a simple attach decision, vs doing all the
>>    protocol work specified in MIPv6, DSMIP, IKE and IPsec specs.
>>    Constant signaling, tunneling over the air link.
>>
>
> Constant signaling???
>
> For tunneling over the air IETF already defined solutions. You will need ROHC with or without MIPv6 (i.e. for VoIP)
>
>> - Building a Mobile IPv6 stack, IKEv2, IPsec, DSMIP6 stack on to
>>    Windows, all variants of Linux, MAC OS/X .... zillion other
>>    platforms and doing interop testing.
>
> Indeed, you are not doing interop testing because your L2 colleagues need to do them, you are just moving the problem to another department.
>
>>   Vs, building a simple
>>    application for L2 triggers, or modifying client stack for the
>>    same, the efforts are of different order.
>>
>> The simple L2 message, saves me from all the above.
>
> Just because you don't implement it and others specify and implement it :-)
> And other SDOs will define different L2 messages which may not provide all enough information for your MAG.
>
>> And I
>> cant convince Apple to bundle MIPv6 stack or atleast allow me to
>> build it using their SDK.
>>
>
> OK, convince them to go to change 802.11 standard and to implement a L2 indication for PMIPv6 then ;-)
> And also to change the 3G standard and to implement the L2 indication for PMIPv6 also there.
>
> Gerardo
>
>> So, there are differences. The pain points are different.
>>
>> Sri
>>
>>
>>
>>
>>> To me the difference is just that IETF can work on (i.e. define, extend) the
>> latter but not on the former. And that the latter works on any L2 while the
>> former is tied to a particular technology.
>>>
>>> Gerardo
>>>
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp]
>>>> On Behalf Of Sri Gundavelli
>>>> Sent: Wednesday, April 08, 2009 3:12 PM
>>>> To: Domagoj Premec
>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>> Subject: Re: [Netext] next steps for netext
>>>>
>>>> Hi Domagoj,
>>>>
>>>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>>>
>>>> For other scenarios of multi-attach, there can be policies
>>>> on the network and the terminal, or a L2 signaling as you
>>>> prefer, or an application signaling ..., but sure, there
>>>> may be a need for the coordination between the terminal and
>>>> the network. But, we cannot equate this requirement with
>>>> the client-mobility requirement, with the mobile involved
>>>> in signaling.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>
>>>>> Sri,
>>>>>
>>>>> What you're discribing is a specific type of deployment where the MN is
>>>>> allowed to attach only through a single access at a time. But this
>> prevents
>>>>> multihoming and is not a generic solution. We need a generic solution that
>>>>> works with any type of deployment without artifical restrictions.
>>>>>
>>>>> domagoj
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>>>> Sent: 08. travanj 2009 23:47
>>>>>> To: Domagoj Premec
>>>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>>>> Subject: RE: [Netext] next steps for netext
>>>>>>
>>>>>> Domagoj,
>>>>>>
>>>>>>
>>>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>>>
>>>>>>> Sri,
>>>>>>>
>>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>>
>>>>>>> I disagree with this statement. In case of inter-tech handover, the
>>>>>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>>>>>> Handoff between two different interfaces of the mobile
>>>>>> node". How does
>>>>>>> the new MAG know that the attachment should be treated as a
>>>>>> handover
>>>>>>> and not as a new session? In the absence of any other
>>>>>> indications, the
>>>>>>> MAG will treat this as a new attachment, which results in
>>>>>> multihoming
>>>>>>> with a different prefix and no handover.
>>>>>>>
>>>>>>
>>>>>> Can a deployment have terminals that only do single attach.
>>>>>> Can that information be tied to the mobile's policy profile.
>>>>>> Is it possible such information is available to the MAG ?
>>>>>>
>>>>>> Can AAA or other session manager have the awareness of the
>>>>>> current existing session. Can the MAG leverage such
>>>>>> information and derive if its a handover or a new attach ?
>>>>>>
>>>>>> So, its possible for the MAG to derive that information from
>>>>>> the network, in many cases, including in 3GPP, as Vijay
>>>>>> pointed out for single attach.
>>>>>>
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> domagoj
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>>>>>> Gundavelli
>>>>>>>> Sent: 08. travanj 2009 21:51
>>>>>>>> To: Basavaraj.Patil at nokia.com
>>>>>>>> Cc: netext at mail.mobileip.jp
>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>
>>>>>>>> I agree, this discussion is going on a different track. This wont
>>>>>>>> converge. Secondly, we are bundling every thing together
>>>>>> and making
>>>>>>>> blanket statements. There are statements,
>>>>>> multi-homing/handover does
>>>>>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
>>>>>>>> there seems to be lot of assumptions around this, with out
>>>>>> qualifying
>>>>>>>> that, these statements are only creating confusion. Couple
>>>>>> of points:
>>>>>>>>
>>>>>>>> - Multihoming is supported in PMIPv6
>>>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>>>> - None of these features break or burn the host.
>>>>>>>>
>>>>>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>>>> some one
>>>>>>>> from building an IPv6 enterprise mobility solution based on Proxy
>>>>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
>>>>>>>> that can be deployed in enterprise wireless architectures.
>>>>>> No one can
>>>>>>>> tell me, we cant deploy this protocol for solving micro mobility
>>>>>>>> problems in an integrated wired/wireless AP environments,
>>>>>> targetted
>>>>>>>> for an enterprise.
>>>>>>>>
>>>>>>>>> From the list of proposed items, I'd really hope to identify the
>>>>>>>>> work
>>>>>>>> items that does not require extesive debates from the ones that
>>>>>>>> requires fist-fighting.
>>>>>>>>
>>>>>>>> - Flow mobility has the scope from moving individual flows of
>>>>>>>> interest with no relation to prefix, vs moving flows as a bundle
>>>>>>>> associated to a prefix.
>>>>>>>>
>>>>>>>> - Host specific doc, from the point of view of leveraging
>>>>>> what 5213
>>>>>>>> supports, vs, for supporting the new features.
>>>>>>>>
>>>>>>>> - Multi-homing, binding a single prefix to multiple
>>>>>> interfaces, vs,
>>>>>>>> an individual prefix to each interface.
>>>>>>>>
>>>>>>>>
>>>>>>>> We have to qualify the discussions around this, just the
>>>>>> use of the
>>>>>>>> key words multi-homing, inter-tech handovers, flow mobility, and
>>>>>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>>>>>> concern and does not help the discussions. We have to state which
>>>>>>>> specific item has issues and under what scenario's.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Sri
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Lets try and keep this discussion focused on technical issues.
>>>>>>>>> The current tone is not very encouraging in some instances.
>>>>>>>>>
>>>>>>>>> The current discussion is overly focused on what 3GPP is
>>>>>>>> doing w.r.t
>>>>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>>>>>> protocols when
>>>>>>>>> they see a good fit for their architecture and problem scope. We
>>>>>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>>>>>> instead rely on the IETF to deliver it.
>>>>>>>>> They are free to do whatever they want.
>>>>>>>>>
>>>>>>>>> Within the IETF we can identify what problems or extensions
>>>>>>>> to PMIP6
>>>>>>>>> we want to work on and focus on these. If 3GPP finds the solution
>>>>>>>>> applicable, they will use it. The IETF solution has to
>>>>>> address the
>>>>>>>>> generic problem and not tailored for 3GPP (which is what we
>>>>>>>> seem to be doing now).
>>>>>>>>> So maybe we can get down to discussing the problem and
>>>>>>>> scenarios that
>>>>>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>>>>>
>>>>>>>>> In order to make progress, I would suggest that we focus on the
>>>>>>>>> following 3
>>>>>>>>> topics:
>>>>>>>>> A. Multihoming
>>>>>>>>> B. Flow mobility
>>>>>>>>> C. Inter technology handovers
>>>>>>>>>
>>>>>>>>> If we can articulate the scenarios and associated problems
>>>>>>>> with each
>>>>>>>>> of the same, we can then get a better handle on what to
>>>>>> take on in
>>>>>>>>> Netext. And lets not start saying that we already have a
>>>>>>>> solution in I-Dx or I-Dy.
>>>>>>>>>
>>>>>>>>> -Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>>>>>> <vijay at wichorus.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi George,
>>>>>>>>>>
>>>>>>>>>> George Tsirtsis wrote:
>>>>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>>>>>> <vijay at wichorus.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Gerardo,
>>>>>>>>>>>>
>>>>>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>>>>>> solutions proposed on any I-D - there is a
>>>>>>>> 3GPP-specific solution
>>>>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>>>>>
>>>>>>>>>>>> This is exactly what I would like to avoid. I would
>>>>>>>> prefer using a
>>>>>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>>>>>> technology for
>>>>>>>>>>> almost as long as the IETF. Getting the IETF to do
>>>>>> something only
>>>>>>>>>>> makes sense if the given protocol has general
>>>>>>>> applicability and does
>>>>>>>>>>> not damage the Internet, which is why we are having this
>>>>>>>> discussion.
>>>>>>>>>>
>>>>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>>>>>> very little
>>>>>>>>>> modifications. They have added some vendor specific options for
>>>>>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>>>>>> PMIPv6, it
>>>>>>>>>> doesn't make sense for them to develop a solution on their
>>>>>>>> own. It should be done in the IETF.
>>>>>>>>>>
>>>>>>>>>> And can we please stop the hyperbole about "damaging the
>>>>>>>> Internet"?
>>>>>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>>>>>
>>>>>>>>>>> GT> In another e-mail where you are over-viewing a
>>>>>>>> possible solution
>>>>>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>>>>>>>> signal to indicate what flows need to go to a given
>>>>>> MAG. I do not
>>>>>>>>>>> see how the IETF can define a protocol that fully depends
>>>>>>>> on such an
>>>>>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>>>>>> must define
>>>>>>>>>>> it at the IP layer to make sure that this works across ALL link
>>>>>>>>>>> layers (which is the main reason the IETF and the
>>>>>> Internet exist).
>>>>>>>>>>
>>>>>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>>>>>> So I don't
>>>>>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>>>>>
>>>>>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>>>>>> does not
>>>>>>>>>> indicate the service identifier. Please see
>>>>>>>>>>
>>>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>>>>>
>>>>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>>>>>> hurdles to overcome:
>>>>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>>>>>> to define
>>>>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>>>>>
>>>>>>>>>> That is one option, but not required.
>>>>>>>>>>
>>>>>>>>>> Vijay
>>>>>>>>>>
>>>>>>>>>>> 2) Convince people that defining such a client based
>>>>>> protocol in
>>>>>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>>>>>>>> process, explain to people why you want to introduce FA
>>>>>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>>>>>
>>>>>>>>>>> George
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>>> 3GPP has not decided yet to do any normative work on
>>>>>> any of the
>>>>>>>>>>>>> solutions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>>>>>> netext at mail.mobileip.jp;
>>>>>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>>>>>> list, sorry for that
>>>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>>>>>> function though.
>>>>>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>>>>>> basis for the
>>>>>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>>>>>> claim not backed
>>>>>>>>>>>>>> by 3GPP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>>>>>> (discussed at the
>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>>>>>> PMIP6 so we
>>>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>>>>>> note that I am
>>>>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>>>>>> homogeneous from a
>>>>>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>>>>>> handovers/multihoming is
>>>>>>>>>>>>>>>>>> not helping as they have
>>>>>>>>>>>>> really set their mind
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>>>>>> going into the
>>>>>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>>>>>> defined in RFC 5213,
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>>>>>> better to fix those
>>>>>>>>>>>>>> PMIP6
>>>>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>>>>>> their own way of
>>>>>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>>>>>> Behalf Of ext
>>>>>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
>>>>>> the BoF, so
>>>>>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
>>>>>> wanted PMIP in
>>>>>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>>>>>> use cases.
>>>>>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
>>>>>> don't know
>>>>>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>>>>>> and PMIP)
>>>>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
>>>>>> need to do
>>>>>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>>>>>> here is "PMIP
>>>>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>>>>>> something
>>>>>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>>>>>> my reference to 4830...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>>>>>> someone makes
>>>>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>>>>>> is no such
>>>>>>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>>>>>> MIP. I don't
>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>> the motivation for creating something new.
>>>>>> I've detailed
>>>>>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>>>>>> management
>>>>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>>>>>> talking about
>>>>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> distinguish modification for mobility
>>>>>> management, which
>>>>>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>>>>>> room was in
>>>>>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => I think the question changed a few times
>>>>>> :) The final
>>>>>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
>>>>>> for using
>>>>>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
>>>>>> section 4 of
>>>>>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>>>>>> These were the
>>>>>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>>>>>> could specify
>>>>>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
>>>>>> that when a
>>>>>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>
>

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Wed, 8 Apr 2009 15:41:46 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>
> Hi Gerardo,
>
> > What is the different between:
> > - the mobile sending a L2 message named "Attach Type" which triggers the PBU
> and the HI included in it
> > - the mobile sending a L3 message named "Registration Request" or "Binding
> Update"
> >
>
> Sure, there is a difference:
>
> - The mobile making a simple attach decision, vs doing all the
>    protocol work specified in MIPv6, DSMIP, IKE and IPsec specs.
>    Constant signaling, tunneling over the air link.
>

Constant signaling???

For tunneling over the air IETF already defined solutions. You will need ROHC with or without MIPv6 (i.e. for VoIP)

> - Building a Mobile IPv6 stack, IKEv2, IPsec, DSMIP6 stack on to
>    Windows, all variants of Linux, MAC OS/X .... zillion other
>    platforms and doing interop testing.

Indeed, you are not doing interop testing because your L2 colleagues need to do them, you are just moving the problem to another department.

>   Vs, building a simple
>    application for L2 triggers, or modifying client stack for the
>    same, the efforts are of different order.
>
> The simple L2 message, saves me from all the above.

Just because you don't implement it and others specify and implement it :-)
And other SDOs will define different L2 messages which may not provide all enough information for your MAG.

> And I
> cant convince Apple to bundle MIPv6 stack or atleast allow me to
> build it using their SDK.
>

OK, convince them to go to change 802.11 standard and to implement a L2 indication for PMIPv6 then ;-)
And also to change the 3G standard and to implement the L2 indication for PMIPv6 also there.

Gerardo

> So, there are differences. The pain points are different.
>
> Sri
>
>
>
>
> > To me the difference is just that IETF can work on (i.e. define, extend) the
> latter but not on the former. And that the latter works on any L2 while the
> former is tied to a particular technology.
> >
> > Gerardo
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp]
> >> On Behalf Of Sri Gundavelli
> >> Sent: Wednesday, April 08, 2009 3:12 PM
> >> To: Domagoj Premec
> >> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >> Subject: Re: [Netext] next steps for netext
> >>
> >> Hi Domagoj,
> >>
> >> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
> >>
> >> For other scenarios of multi-attach, there can be policies
> >> on the network and the terminal, or a L2 signaling as you
> >> prefer, or an application signaling ..., but sure, there
> >> may be a need for the coordination between the terminal and
> >> the network. But, we cannot equate this requirement with
> >> the client-mobility requirement, with the mobile involved
> >> in signaling.
> >>
> >> Sri
> >>
> >>
> >>
> >> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>
> >>> Sri,
> >>>
> >>> What you're discribing is a specific type of deployment where the MN is
> >>> allowed to attach only through a single access at a time. But this
> prevents
> >>> multihoming and is not a generic solution. We need a generic solution that
> >>> works with any type of deployment without artifical restrictions.
> >>>
> >>> domagoj
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >>>> Sent: 08. travanj 2009 23:47
> >>>> To: Domagoj Premec
> >>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >>>> Subject: RE: [Netext] next steps for netext
> >>>>
> >>>> Domagoj,
> >>>>
> >>>>
> >>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>>>
> >>>>> Sri,
> >>>>>
> >>>>>> - Inter-tech handovers are supported in PMIPv6
> >>>>>
> >>>>> I disagree with this statement. In case of inter-tech handover, the
> >>>>> MAG in the new access needs to send a PBU with the HI set to "2:
> >>>>> Handoff between two different interfaces of the mobile
> >>>> node". How does
> >>>>> the new MAG know that the attachment should be treated as a
> >>>> handover
> >>>>> and not as a new session? In the absence of any other
> >>>> indications, the
> >>>>> MAG will treat this as a new attachment, which results in
> >>>> multihoming
> >>>>> with a different prefix and no handover.
> >>>>>
> >>>>
> >>>> Can a deployment have terminals that only do single attach.
> >>>> Can that information be tied to the mobile's policy profile.
> >>>> Is it possible such information is available to the MAG ?
> >>>>
> >>>> Can AAA or other session manager have the awareness of the
> >>>> current existing session. Can the MAG leverage such
> >>>> information and derive if its a handover or a new attach ?
> >>>>
> >>>> So, its possible for the MAG to derive that information from
> >>>> the network, in many cases, including in 3GPP, as Vijay
> >>>> pointed out for single attach.
> >>>>
> >>>> Sri
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> domagoj
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: netext-bounces at mail.mobileip.jp
> >>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> >>>>>> Gundavelli
> >>>>>> Sent: 08. travanj 2009 21:51
> >>>>>> To: Basavaraj.Patil at nokia.com
> >>>>>> Cc: netext at mail.mobileip.jp
> >>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>
> >>>>>> I agree, this discussion is going on a different track. This wont
> >>>>>> converge. Secondly, we are bundling every thing together
> >>>> and making
> >>>>>> blanket statements. There are statements,
> >>>> multi-homing/handover does
> >>>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
> >>>>>> there seems to be lot of assumptions around this, with out
> >>>> qualifying
> >>>>>> that, these statements are only creating confusion. Couple
> >>>> of points:
> >>>>>>
> >>>>>> - Multihoming is supported in PMIPv6
> >>>>>> - Inter-tech handovers are supported in PMIPv6
> >>>>>> - None of these features break or burn the host.
> >>>>>>
> >>>>>> 3GPP is not the only consumer for this work. Nothing stops
> >>>> some one
> >>>>>> from building an IPv6 enterprise mobility solution based on Proxy
> >>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
> >>>>>> that can be deployed in enterprise wireless architectures.
> >>>> No one can
> >>>>>> tell me, we cant deploy this protocol for solving micro mobility
> >>>>>> problems in an integrated wired/wireless AP environments,
> >>>> targetted
> >>>>>> for an enterprise.
> >>>>>>
> >>>>>>> From the list of proposed items, I'd really hope to identify the
> >>>>>>> work
> >>>>>> items that does not require extesive debates from the ones that
> >>>>>> requires fist-fighting.
> >>>>>>
> >>>>>> - Flow mobility has the scope from moving individual flows of
> >>>>>> interest with no relation to prefix, vs moving flows as a bundle
> >>>>>> associated to a prefix.
> >>>>>>
> >>>>>> - Host specific doc, from the point of view of leveraging
> >>>> what 5213
> >>>>>> supports, vs, for supporting the new features.
> >>>>>>
> >>>>>> - Multi-homing, binding a single prefix to multiple
> >>>> interfaces, vs,
> >>>>>> an individual prefix to each interface.
> >>>>>>
> >>>>>>
> >>>>>> We have to qualify the discussions around this, just the
> >>>> use of the
> >>>>>> key words multi-homing, inter-tech handovers, flow mobility, and
> >>>>>> saying is not for PMIP6, is not accurate, does not justify the
> >>>>>> concern and does not help the discussions. We have to state which
> >>>>>> specific item has issues and under what scenario's.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Sri
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Lets try and keep this discussion focused on technical issues.
> >>>>>>> The current tone is not very encouraging in some instances.
> >>>>>>>
> >>>>>>> The current discussion is overly focused on what 3GPP is
> >>>>>> doing w.r.t
> >>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
> >>>> protocols when
> >>>>>>> they see a good fit for their architecture and problem scope. We
> >>>>>>> cannot tell 3GPP to not develop a feature by themselves and
> >>>>>> instead rely on the IETF to deliver it.
> >>>>>>> They are free to do whatever they want.
> >>>>>>>
> >>>>>>> Within the IETF we can identify what problems or extensions
> >>>>>> to PMIP6
> >>>>>>> we want to work on and focus on these. If 3GPP finds the solution
> >>>>>>> applicable, they will use it. The IETF solution has to
> >>>> address the
> >>>>>>> generic problem and not tailored for 3GPP (which is what we
> >>>>>> seem to be doing now).
> >>>>>>> So maybe we can get down to discussing the problem and
> >>>>>> scenarios that
> >>>>>>> we would like to work on in Netext as a way of moving forward.
> >>>>>>>
> >>>>>>> In order to make progress, I would suggest that we focus on the
> >>>>>>> following 3
> >>>>>>> topics:
> >>>>>>> A. Multihoming
> >>>>>>> B. Flow mobility
> >>>>>>> C. Inter technology handovers
> >>>>>>>
> >>>>>>> If we can articulate the scenarios and associated problems
> >>>>>> with each
> >>>>>>> of the same, we can then get a better handle on what to
> >>>> take on in
> >>>>>>> Netext. And lets not start saying that we already have a
> >>>>>> solution in I-Dx or I-Dy.
> >>>>>>>
> >>>>>>> -Raj
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >>>>>> <vijay at wichorus.com> wrote:
> >>>>>>>
> >>>>>>>> Hi George,
> >>>>>>>>
> >>>>>>>> George Tsirtsis wrote:
> >>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
> >>>>>>>>> <vijay at wichorus.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi Gerardo,
> >>>>>>>>>>
> >>>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
> >>>>>>>>>>> solutions proposed on any I-D - there is a
> >>>>>> 3GPP-specific solution
> >>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>>>>>
> >>>>>>>>>> This is exactly what I would like to avoid. I would
> >>>>>> prefer using a
> >>>>>>>>>> solution developed in the IETF rather than something in 3GPP.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
> >>>> technology for
> >>>>>>>>> almost as long as the IETF. Getting the IETF to do
> >>>> something only
> >>>>>>>>> makes sense if the given protocol has general
> >>>>>> applicability and does
> >>>>>>>>> not damage the Internet, which is why we are having this
> >>>>>> discussion.
> >>>>>>>>
> >>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >>>>>> very little
> >>>>>>>> modifications. They have added some vendor specific options for
> >>>>>>>> carrying some 3GPP specific information, but they are minor
> >>>>>>>> extensions. So when 3GPP is considering flow mobility for
> >>>>>> PMIPv6, it
> >>>>>>>> doesn't make sense for them to develop a solution on their
> >>>>>> own. It should be done in the IETF.
> >>>>>>>>
> >>>>>>>> And can we please stop the hyperbole about "damaging the
> >>>>>> Internet"?
> >>>>>>>> It is irritating and doesn't contribute to the discussion.
> >>>>>>>>
> >>>>>>>>> GT> In another e-mail where you are over-viewing a
> >>>>>> possible solution
> >>>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
> >>>>>>>>> signal to indicate what flows need to go to a given
> >>>> MAG. I do not
> >>>>>>>>> see how the IETF can define a protocol that fully depends
> >>>>>> on such an
> >>>>>>>>> L2 signal. If such functionality is needed then the IETF
> >>>>>> must define
> >>>>>>>>> it at the IP layer to make sure that this works across ALL link
> >>>>>>>>> layers (which is the main reason the IETF and the
> >>>> Internet exist).
> >>>>>>>>
> >>>>>>>> Indicating the service identifier during an L2 attachment is
> >>>>>>>> supported in most accesses that PMIPv6 is being used for.
> >>>>>> So I don't
> >>>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
> >>>>>>>> carrying the service identifier. That would be an overkill.
> >>>>>>>>
> >>>>>>>> Anyway, flow mobility can still be achieved even if the MN
> >>>>>> does not
> >>>>>>>> indicate the service identifier. Please see
> >>>>>>>>
> >>>>>>
> >>>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>>>>>
> >>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
> >>>>>> hurdles to overcome:
> >>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
> >>>>>> to define
> >>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>>>>>
> >>>>>>>> That is one option, but not required.
> >>>>>>>>
> >>>>>>>> Vijay
> >>>>>>>>
> >>>>>>>>> 2) Convince people that defining such a client based
> >>>> protocol in
> >>>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
> >>>>>>>>> process, explain to people why you want to introduce FA
> >>>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
> >>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>>>>>
> >>>>>>>>> George
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Vijay
> >>>>>>>>>>
> >>>>>>>>>>> 3GPP has not decided yet to do any normative work on
> >>>> any of the
> >>>>>>>>>>> solutions.
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>>>>>> To: Giaretta, Gerardo
> >>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
> >>>> netext at mail.mobileip.jp;
> >>>>>>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>>>>>> list, sorry for that
> >>>>>>>>>>>>> :-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>>>>>> function though.
> >>>>>>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>>>>>> basis for the
> >>>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>>>>>>>> claim not backed
> >>>>>>>>>>>> by 3GPP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hesham
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Vijay
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>>>>>> (discussed at the
> >>>>>>>>>>>> last
> >>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>>>>>> WiMAX with PMIPv6
> >>>>>>>>>>>>>> working.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>>>> large scale managed networks are the main consumers of
> >>>>>>>>>>> PMIP6 so we
> >>>>>>>>>>>>>> shouldn't
> >>>>>>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>>>>>>>> note that I am
> >>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>>>>>> homogeneous from a
> >>>>>>>>>>>>>> link layer point of view.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Saying to use MIP for inter-access
> >>>>>> handovers/multihoming is
> >>>>>>>>>>>>>>>> not helping as they have
> >>>>>>>>>>> really set their mind
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>>>>>> going into the
> >>>>>>>>>>>>>> reasoning
> >>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>>>>>> defined in RFC 5213,
> >>>>>>>>>>>> has
> >>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>>>>>> better to fix those
> >>>>>>>>>>>> PMIP6
> >>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>>>>>> their own way of
> >>>>>>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> domagoj
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
> >>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
> >>>> Behalf Of ext
> >>>>>>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
> >>>> the BoF, so
> >>>>>>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
> >>>> wanted PMIP in
> >>>>>>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
> >>>>>>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >>>>>> use cases.
> >>>>>>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>>>>>> host-based mobility
> >>>>>>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >>>>>> discussion
> >>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
> >>>> don't know
> >>>>>>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>>>>>> saying:
> >>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >>>>>> and PMIP)
> >>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
> >>>> need to do
> >>>>>>>>>>>>>>>>> something new.
> >>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
> >>>>>> here is "PMIP
> >>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >>>>>> something
> >>>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
> >>>>>>>>>>>>>>>>> designed to support those cases because we already have
> >>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
> >>>>>> my reference to 4830...
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
> >>>>>> someone makes
> >>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
> >>>>>> is no such
> >>>>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
> >>>>>> MIP. I don't
> >>>>>>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>>>>>> the motivation for creating something new.
> >>>> I've detailed
> >>>>>>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>>>>>>>> management
> >>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>>>>>> seems to be a
> >>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >>>>>> talking about
> >>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> distinguish modification for mobility
> >>>> management, which
> >>>>>>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>>>>>> as the use of
> >>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>>>>>> configure
> >>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>>>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>>>>>> the BoF, our
> >>>>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>>>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>>>>>> stick with MIP.
> >>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>>>>>> this is such a
> >>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>>>>>> room was in
> >>>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => I think the question changed a few times
> >>>> :) The final
> >>>>>>>>>>>>>>>>> question
> >>>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>>>>>> mentioned here
> >>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
> >>>> for using
> >>>>>>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>>>>>> the host) and
> >>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
> >>>> section 4 of
> >>>>>>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>>>>>> anyway. However if
> >>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>>>>>> not specify how
> >>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>>>>>> in all L2s,
> >>>>>>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>>>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>>>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
> >>>> These were the
> >>>>>>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>>>>>> scope in IETF
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>>>>>> could specify
> >>>>>>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>>>>>> if that is the
> >>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
> >>>> that when a
> >>>>>>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>>>>>> is inferior in
> >>>>>>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>>>>>> mostly flow
> >>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 15:35:22 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

> What is the different between:
> - the mobile sending a L2 message named "Attach Type" which triggers the PBU and the HI included in it
> - the mobile sending a L3 message named "Registration Request" or "Binding Update"
>

Sure, there is a difference:

- The mobile making a simple attach decision, vs doing all the
   protocol work specified in MIPv6, DSMIP, IKE and IPsec specs.
   Constant signaling, tunneling over the air link.

- Building a Mobile IPv6 stack, IKEv2, IPsec, DSMIP6 stack on to
   Windows, all variants of Linux, MAC OS/X .... zillion other
   platforms and doing interop testing. Vs, building a simple
   application for L2 triggers, or modifying client stack for the
   same, the efforts are of different order.

The simple L2 message, saves me from all the above. And I
cant convince Apple to bundle MIPv6 stack or atleast allow me to
build it using their SDK.

So, there are differences. The pain points are different.

Sri

> To me the difference is just that IETF can work on (i.e. define, extend) the latter but not on the former. And that the latter works on any L2 while the former is tied to a particular technology.
>
> Gerardo
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
>> On Behalf Of Sri Gundavelli
>> Sent: Wednesday, April 08, 2009 3:12 PM
>> To: Domagoj Premec
>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] next steps for netext
>>
>> Hi Domagoj,
>>
>> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>>
>> For other scenarios of multi-attach, there can be policies
>> on the network and the terminal, or a L2 signaling as you
>> prefer, or an application signaling ..., but sure, there
>> may be a need for the coordination between the terminal and
>> the network. But, we cannot equate this requirement with
>> the client-mobility requirement, with the mobile involved
>> in signaling.
>>
>> Sri
>>
>>
>>
>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>
>>> Sri,
>>>
>>> What you're discribing is a specific type of deployment where the MN is
>>> allowed to attach only through a single access at a time. But this prevents
>>> multihoming and is not a generic solution. We need a generic solution that
>>> works with any type of deployment without artifical restrictions.
>>>
>>> domagoj
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>> Sent: 08. travanj 2009 23:47
>>>> To: Domagoj Premec
>>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>>> Subject: RE: [Netext] next steps for netext
>>>>
>>>> Domagoj,
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>>>
>>>>> Sri,
>>>>>
>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>
>>>>> I disagree with this statement. In case of inter-tech handover, the
>>>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>>>> Handoff between two different interfaces of the mobile
>>>> node". How does
>>>>> the new MAG know that the attachment should be treated as a
>>>> handover
>>>>> and not as a new session? In the absence of any other
>>>> indications, the
>>>>> MAG will treat this as a new attachment, which results in
>>>> multihoming
>>>>> with a different prefix and no handover.
>>>>>
>>>>
>>>> Can a deployment have terminals that only do single attach.
>>>> Can that information be tied to the mobile's policy profile.
>>>> Is it possible such information is available to the MAG ?
>>>>
>>>> Can AAA or other session manager have the awareness of the
>>>> current existing session. Can the MAG leverage such
>>>> information and derive if its a handover or a new attach ?
>>>>
>>>> So, its possible for the MAG to derive that information from
>>>> the network, in many cases, including in 3GPP, as Vijay
>>>> pointed out for single attach.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> domagoj
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>>>> Gundavelli
>>>>>> Sent: 08. travanj 2009 21:51
>>>>>> To: Basavaraj.Patil at nokia.com
>>>>>> Cc: netext at mail.mobileip.jp
>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>
>>>>>> I agree, this discussion is going on a different track. This wont
>>>>>> converge. Secondly, we are bundling every thing together
>>>> and making
>>>>>> blanket statements. There are statements,
>>>> multi-homing/handover does
>>>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
>>>>>> there seems to be lot of assumptions around this, with out
>>>> qualifying
>>>>>> that, these statements are only creating confusion. Couple
>>>> of points:
>>>>>>
>>>>>> - Multihoming is supported in PMIPv6
>>>>>> - Inter-tech handovers are supported in PMIPv6
>>>>>> - None of these features break or burn the host.
>>>>>>
>>>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>> some one
>>>>>> from building an IPv6 enterprise mobility solution based on Proxy
>>>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
>>>>>> that can be deployed in enterprise wireless architectures.
>>>> No one can
>>>>>> tell me, we cant deploy this protocol for solving micro mobility
>>>>>> problems in an integrated wired/wireless AP environments,
>>>> targetted
>>>>>> for an enterprise.
>>>>>>
>>>>>>> From the list of proposed items, I'd really hope to identify the
>>>>>>> work
>>>>>> items that does not require extesive debates from the ones that
>>>>>> requires fist-fighting.
>>>>>>
>>>>>> - Flow mobility has the scope from moving individual flows of
>>>>>> interest with no relation to prefix, vs moving flows as a bundle
>>>>>> associated to a prefix.
>>>>>>
>>>>>> - Host specific doc, from the point of view of leveraging
>>>> what 5213
>>>>>> supports, vs, for supporting the new features.
>>>>>>
>>>>>> - Multi-homing, binding a single prefix to multiple
>>>> interfaces, vs,
>>>>>> an individual prefix to each interface.
>>>>>>
>>>>>>
>>>>>> We have to qualify the discussions around this, just the
>>>> use of the
>>>>>> key words multi-homing, inter-tech handovers, flow mobility, and
>>>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>>>> concern and does not help the discussions. We have to state which
>>>>>> specific item has issues and under what scenario's.
>>>>>>
>>>>>> Thanks
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Lets try and keep this discussion focused on technical issues.
>>>>>>> The current tone is not very encouraging in some instances.
>>>>>>>
>>>>>>> The current discussion is overly focused on what 3GPP is
>>>>>> doing w.r.t
>>>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>>>> protocols when
>>>>>>> they see a good fit for their architecture and problem scope. We
>>>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>>>> instead rely on the IETF to deliver it.
>>>>>>> They are free to do whatever they want.
>>>>>>>
>>>>>>> Within the IETF we can identify what problems or extensions
>>>>>> to PMIP6
>>>>>>> we want to work on and focus on these. If 3GPP finds the solution
>>>>>>> applicable, they will use it. The IETF solution has to
>>>> address the
>>>>>>> generic problem and not tailored for 3GPP (which is what we
>>>>>> seem to be doing now).
>>>>>>> So maybe we can get down to discussing the problem and
>>>>>> scenarios that
>>>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>>>
>>>>>>> In order to make progress, I would suggest that we focus on the
>>>>>>> following 3
>>>>>>> topics:
>>>>>>> A. Multihoming
>>>>>>> B. Flow mobility
>>>>>>> C. Inter technology handovers
>>>>>>>
>>>>>>> If we can articulate the scenarios and associated problems
>>>>>> with each
>>>>>>> of the same, we can then get a better handle on what to
>>>> take on in
>>>>>>> Netext. And lets not start saying that we already have a
>>>>>> solution in I-Dx or I-Dy.
>>>>>>>
>>>>>>> -Raj
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>>>> <vijay at wichorus.com> wrote:
>>>>>>>
>>>>>>>> Hi George,
>>>>>>>>
>>>>>>>> George Tsirtsis wrote:
>>>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>>>> <vijay at wichorus.com>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Gerardo,
>>>>>>>>>>
>>>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>>>> solutions proposed on any I-D - there is a
>>>>>> 3GPP-specific solution
>>>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>>>
>>>>>>>>>> This is exactly what I would like to avoid. I would
>>>>>> prefer using a
>>>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>>>> technology for
>>>>>>>>> almost as long as the IETF. Getting the IETF to do
>>>> something only
>>>>>>>>> makes sense if the given protocol has general
>>>>>> applicability and does
>>>>>>>>> not damage the Internet, which is why we are having this
>>>>>> discussion.
>>>>>>>>
>>>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>>>> very little
>>>>>>>> modifications. They have added some vendor specific options for
>>>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>>>> PMIPv6, it
>>>>>>>> doesn't make sense for them to develop a solution on their
>>>>>> own. It should be done in the IETF.
>>>>>>>>
>>>>>>>> And can we please stop the hyperbole about "damaging the
>>>>>> Internet"?
>>>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>>>
>>>>>>>>> GT> In another e-mail where you are over-viewing a
>>>>>> possible solution
>>>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>>>>>> signal to indicate what flows need to go to a given
>>>> MAG. I do not
>>>>>>>>> see how the IETF can define a protocol that fully depends
>>>>>> on such an
>>>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>>>> must define
>>>>>>>>> it at the IP layer to make sure that this works across ALL link
>>>>>>>>> layers (which is the main reason the IETF and the
>>>> Internet exist).
>>>>>>>>
>>>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>>>> So I don't
>>>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>>>
>>>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>>>> does not
>>>>>>>> indicate the service identifier. Please see
>>>>>>>>
>>>>>>
>>>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>>>
>>>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>>>> hurdles to overcome:
>>>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>>>> to define
>>>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>>>
>>>>>>>> That is one option, but not required.
>>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> 2) Convince people that defining such a client based
>>>> protocol in
>>>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>>>>>> process, explain to people why you want to introduce FA
>>>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>>>
>>>>>>>>> George
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Vijay
>>>>>>>>>>
>>>>>>>>>>> 3GPP has not decided yet to do any normative work on
>>>> any of the
>>>>>>>>>>> solutions.
>>>>>>>>>>>
>>>>>>>>>>> Gerardo
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>>>> netext at mail.mobileip.jp;
>>>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>>>> list, sorry for that
>>>>>>>>>>>>> :-)
>>>>>>>>>>>>
>>>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>>>> function though.
>>>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>>>> basis for the
>>>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>>>> claim not backed
>>>>>>>>>>>> by 3GPP.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>>>> (discussed at the
>>>>>>>>>>>> last
>>>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>>>> working.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>>>> PMIP6 so we
>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>>>> note that I am
>>>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>>>> homogeneous from a
>>>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>>>> handovers/multihoming is
>>>>>>>>>>>>>>>> not helping as they have
>>>>>>>>>>> really set their mind
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>>>> going into the
>>>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>>>> defined in RFC 5213,
>>>>>>>>>>>> has
>>>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>>>> better to fix those
>>>>>>>>>>>> PMIP6
>>>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>>>> their own way of
>>>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>>>> Behalf Of ext
>>>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
>>>> the BoF, so
>>>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>>>> appropriate as a reference for why people
>>>> wanted PMIP in
>>>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>>>> use cases.
>>>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>>>> discussion
>>>>>>>>>>>>>>>>> and this discussion on the list. The reason I
>>>> don't know
>>>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>>>> and PMIP)
>>>>>>>>>>>>>>>>> and here is why they don't work, therefore we
>>>> need to do
>>>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>>>> here is "PMIP
>>>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>>>> something
>>>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>>>> my reference to 4830...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>>>> someone makes
>>>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>>>> is no such
>>>>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>>>> MIP. I don't
>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>> the motivation for creating something new.
>>>> I've detailed
>>>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>>>> management
>>>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>>>> talking about
>>>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> distinguish modification for mobility
>>>> management, which
>>>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>>>> room was in
>>>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => I think the question changed a few times
>>>> :) The final
>>>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>>>> because they were one of the very few reasons
>>>> for using
>>>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
>>>> section 4 of
>>>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>>>> These were the
>>>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>>>> could specify
>>>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
>>>> that when a
>>>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Thu, 9 Apr 2009 00:32:04 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".

I still fail to see how the inter-tech handover works if you don't assume a
constrained enviroment where only attachment through a single access at a
time is allowed. What you say above is a generic statement, but it does not
hold for the generic deployment case. 

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 09. travanj 2009 00:12
> To: Domagoj Premec
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: RE: [Netext] next steps for netext
> 
> Hi Domagoj,
> 
> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
> 
> For other scenarios of multi-attach, there can be policies on 
> the network and the terminal, or a L2 signaling as you 
> prefer, or an application signaling ..., but sure, there may 
> be a need for the coordination between the terminal and the 
> network. But, we cannot equate this requirement with the 
> client-mobility requirement, with the mobile involved in signaling.
> 
> Sri
> 
> 
> 
> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> 
> > Sri,
> >
> > What you're discribing is a specific type of deployment 
> where the MN 
> > is allowed to attach only through a single access at a 
> time. But this 
> > prevents multihoming and is not a generic solution. We need 
> a generic 
> > solution that works with any type of deployment without 
> artifical restrictions.
> >
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: 08. travanj 2009 23:47
> >> To: Domagoj Premec
> >> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >> Subject: RE: [Netext] next steps for netext
> >>
> >> Domagoj,
> >>
> >>
> >> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>
> >>> Sri,
> >>>
> >>>> - Inter-tech handovers are supported in PMIPv6
> >>>
> >>> I disagree with this statement. In case of inter-tech 
> handover, the 
> >>> MAG in the new access needs to send a PBU with the HI set to "2:
> >>> Handoff between two different interfaces of the mobile
> >> node". How does
> >>> the new MAG know that the attachment should be treated as a
> >> handover
> >>> and not as a new session? In the absence of any other
> >> indications, the
> >>> MAG will treat this as a new attachment, which results in
> >> multihoming
> >>> with a different prefix and no handover.
> >>>
> >>
> >> Can a deployment have terminals that only do single attach.
> >> Can that information be tied to the mobile's policy profile.
> >> Is it possible such information is available to the MAG ?
> >>
> >> Can AAA or other session manager have the awareness of the current 
> >> existing session. Can the MAG leverage such information 
> and derive if 
> >> its a handover or a new attach ?
> >>
> >> So, its possible for the MAG to derive that information from the 
> >> network, in many cases, including in 3GPP, as Vijay 
> pointed out for 
> >> single attach.
> >>
> >> Sri
> >>
> >>
> >>
> >>
> >>
> >>
> >>> domagoj
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: netext-bounces at mail.mobileip.jp 
> >>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
> >>>> Gundavelli
> >>>> Sent: 08. travanj 2009 21:51
> >>>> To: Basavaraj.Patil at nokia.com
> >>>> Cc: netext at mail.mobileip.jp
> >>>> Subject: Re: [Netext] next steps for netext
> >>>>
> >>>> I agree, this discussion is going on a different track. 
> This wont 
> >>>> converge. Secondly, we are bundling every thing together
> >> and making
> >>>> blanket statements. There are statements,
> >> multi-homing/handover does
> >>>> not work in PMIPv6, or that there needs to be an L2 interface ..
> >>>> there seems to be lot of assumptions around this, with out
> >> qualifying
> >>>> that, these statements are only creating confusion. Couple
> >> of points:
> >>>>
> >>>> - Multihoming is supported in PMIPv6
> >>>> - Inter-tech handovers are supported in PMIPv6
> >>>> - None of these features break or burn the host.
> >>>>
> >>>> 3GPP is not the only consumer for this work. Nothing stops
> >> some one
> >>>> from building an IPv6 enterprise mobility solution based 
> on Proxy 
> >>>> Mobile IPv6, as it is not a 3GPP specific protocol, but 
> a protocol 
> >>>> that can be deployed in enterprise wireless architectures.
> >> No one can
> >>>> tell me, we cant deploy this protocol for solving micro mobility 
> >>>> problems in an integrated wired/wireless AP environments,
> >> targetted
> >>>> for an enterprise.
> >>>>
> >>>>> From the list of proposed items, I'd really hope to 
> identify the 
> >>>>> work
> >>>> items that does not require extesive debates from the ones that 
> >>>> requires fist-fighting.
> >>>>
> >>>> - Flow mobility has the scope from moving individual flows of 
> >>>> interest with no relation to prefix, vs moving flows as a bundle 
> >>>> associated to a prefix.
> >>>>
> >>>> - Host specific doc, from the point of view of leveraging
> >> what 5213
> >>>> supports, vs, for supporting the new features.
> >>>>
> >>>> - Multi-homing, binding a single prefix to multiple
> >> interfaces, vs,
> >>>> an individual prefix to each interface.
> >>>>
> >>>>
> >>>> We have to qualify the discussions around this, just the
> >> use of the
> >>>> key words multi-homing, inter-tech handovers, flow mobility, and 
> >>>> saying is not for PMIP6, is not accurate, does not justify the 
> >>>> concern and does not help the discussions. We have to 
> state which 
> >>>> specific item has issues and under what scenario's.
> >>>>
> >>>> Thanks
> >>>> Sri
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>>>
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Lets try and keep this discussion focused on technical issues.
> >>>>> The current tone is not very encouraging in some instances.
> >>>>>
> >>>>> The current discussion is overly focused on what 3GPP is
> >>>> doing w.r.t
> >>>>> PMIP6 and future work items. 3GPP tends to use IETF
> >> protocols when
> >>>>> they see a good fit for their architecture and problem 
> scope. We 
> >>>>> cannot tell 3GPP to not develop a feature by themselves and
> >>>> instead rely on the IETF to deliver it.
> >>>>> They are free to do whatever they want.
> >>>>>
> >>>>> Within the IETF we can identify what problems or extensions
> >>>> to PMIP6
> >>>>> we want to work on and focus on these. If 3GPP finds 
> the solution 
> >>>>> applicable, they will use it. The IETF solution has to
> >> address the
> >>>>> generic problem and not tailored for 3GPP (which is what we
> >>>> seem to be doing now).
> >>>>> So maybe we can get down to discussing the problem and
> >>>> scenarios that
> >>>>> we would like to work on in Netext as a way of moving forward.
> >>>>>
> >>>>> In order to make progress, I would suggest that we focus on the 
> >>>>> following 3
> >>>>> topics:
> >>>>> A. Multihoming
> >>>>> B. Flow mobility
> >>>>> C. Inter technology handovers
> >>>>>
> >>>>> If we can articulate the scenarios and associated problems
> >>>> with each
> >>>>> of the same, we can then get a better handle on what to
> >> take on in
> >>>>> Netext. And lets not start saying that we already have a
> >>>> solution in I-Dx or I-Dy.
> >>>>>
> >>>>> -Raj
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >>>> <vijay at wichorus.com> wrote:
> >>>>>
> >>>>>> Hi George,
> >>>>>>
> >>>>>> George Tsirtsis wrote:
> >>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli 
> >>>>>>> <vijay at wichorus.com>
> >>>>>>> wrote:
> >>>>>>>> Hi Gerardo,
> >>>>>>>>
> >>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6 
> >>>>>>>>> solutions proposed on any I-D - there is a
> >>>> 3GPP-specific solution
> >>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>>>
> >>>>>>>> This is exactly what I would like to avoid. I would
> >>>> prefer using a
> >>>>>>>> solution developed in the IETF rather than something in 3GPP.
> >>>>>>>>
> >>>>>>>
> >>>>>>> GT> Why not? 3GPP and other SDOs have been creating
> >> technology for
> >>>>>>> almost as long as the IETF. Getting the IETF to do
> >> something only
> >>>>>>> makes sense if the given protocol has general
> >>>> applicability and does
> >>>>>>> not damage the Internet, which is why we are having this
> >>>> discussion.
> >>>>>>
> >>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >>>> very little
> >>>>>> modifications. They have added some vendor specific 
> options for 
> >>>>>> carrying some 3GPP specific information, but they are minor 
> >>>>>> extensions. So when 3GPP is considering flow mobility for
> >>>> PMIPv6, it
> >>>>>> doesn't make sense for them to develop a solution on their
> >>>> own. It should be done in the IETF.
> >>>>>>
> >>>>>> And can we please stop the hyperbole about "damaging the
> >>>> Internet"?
> >>>>>> It is irritating and doesn't contribute to the discussion.
> >>>>>>
> >>>>>>> GT> In another e-mail where you are over-viewing a
> >>>> possible solution
> >>>>>>> to PMIP multihoming you talk about how the MN may use 
> an L2 to 
> >>>>>>> signal to indicate what flows need to go to a given
> >> MAG. I do not
> >>>>>>> see how the IETF can define a protocol that fully depends
> >>>> on such an
> >>>>>>> L2 signal. If such functionality is needed then the IETF
> >>>> must define
> >>>>>>> it at the IP layer to make sure that this works 
> across ALL link 
> >>>>>>> layers (which is the main reason the IETF and the
> >> Internet exist).
> >>>>>>
> >>>>>> Indicating the service identifier during an L2 attachment is 
> >>>>>> supported in most accesses that PMIPv6 is being used for.
> >>>> So I don't
> >>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for 
> >>>>>> carrying the service identifier. That would be an overkill.
> >>>>>>
> >>>>>> Anyway, flow mobility can still be achieved even if the MN
> >>>> does not
> >>>>>> indicate the service identifier. Please see
> >>>>>>
> >>>>
> >> 
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>>>
> >>>>>>> GT> So, in my book you (pmip mhoming fans) have two
> >>>> hurdles to overcome:
> >>>>>>> 1) Admit to yourself that to do this in the IETF you need
> >>>> to define
> >>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>>>
> >>>>>> That is one option, but not required.
> >>>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>>> 2) Convince people that defining such a client based
> >> protocol in
> >>>>>>> addition to the existing standard (MIPv6) is 
> warranted. In the 
> >>>>>>> process, explain to people why you want to introduce FA 
> >>>>>>> functionality to MIPv6, which is what MAGs become if 
> you add an 
> >>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>>>
> >>>>>>> George
> >>>>>>>
> >>>>>>>
> >>>>>>>> Vijay
> >>>>>>>>
> >>>>>>>>> 3GPP has not decided yet to do any normative work on
> >> any of the
> >>>>>>>>> solutions.
> >>>>>>>>>
> >>>>>>>>> Gerardo
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>>>> To: Giaretta, Gerardo
> >>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
> >> netext at mail.mobileip.jp;
> >>>>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>>>> list, sorry for that
> >>>>>>>>>>> :-)
> >>>>>>>>>>
> >>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>>>> function though.
> >>>>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>>>> basis for the
> >>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>>>>>> claim not backed
> >>>>>>>>>> by 3GPP.
> >>>>>>>>>>
> >>>>>>>>>> Hesham
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Vijay
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>>>> (discussed at the
> >>>>>>>>>> last
> >>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>>>> WiMAX with PMIPv6
> >>>>>>>>>>>> working.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>> large scale managed networks are the main consumers of
> >>>>>>>>> PMIP6 so we
> >>>>>>>>>>>> shouldn't
> >>>>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>>>>>> note that I am
> >>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>>>> homogeneous from a
> >>>>>>>>>>>> link layer point of view.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Saying to use MIP for inter-access
> >>>> handovers/multihoming is
> >>>>>>>>>>>>>> not helping as they have
> >>>>>>>>> really set their mind
> >>>>>>>>>> on
> >>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>>>> going into the
> >>>>>>>>>>>> reasoning
> >>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>>>> defined in RFC 5213,
> >>>>>>>>>> has
> >>>>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>>>> better to fix those
> >>>>>>>>>> PMIP6
> >>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>>>> their own way of
> >>>>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> domagoj
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
> >> Behalf Of ext
> >>>>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => We're discussing a problem statement for
> >> the BoF, so
> >>>>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>>>> appropriate as a reference for why people
> >> wanted PMIP in
> >>>>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>>>> Yes, a problem statement about an existing 
> solution for
> >>>>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >>>> use cases.
> >>>>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>>>> host-based mobility
> >>>>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >>>> discussion
> >>>>>>>>>>>>>>> and this discussion on the list. The reason I
> >> don't know
> >>>>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>>>> saying:
> >>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >>>> and PMIP)
> >>>>>>>>>>>>>>> and here is why they don't work, therefore we
> >> need to do
> >>>>>>>>>>>>>>> something new.
> >>>>>>>>>>>>>>> That's what a PS should say. What's being said
> >>>> here is "PMIP
> >>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >>>> something
> >>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not 
> >>>>>>>>>>>>>>> designed to support those cases because we 
> already have 
> >>>>>>>>>>>>>>> something else for supporting those cases. Hence
> >>>> my reference to 4830...
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm going to retire from the discussion till
> >>>> someone makes
> >>>>>>>>>>>>>>> the argument above. Because I feel that if there
> >>>> is no such
> >>>>>>>>>>>>>>> argument then the discussion is not a good 
> use of time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Yes, additional software like the existing
> >>>> MIP. I don't
> >>>>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>>>> the motivation for creating something new.
> >> I've detailed
> >>>>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>>>>>> management
> >>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>>>> seems to be a
> >>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >>>> talking about
> >>>>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> distinguish modification for mobility
> >> management, which
> >>>>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>>>> as the use of
> >>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>>>> configure
> >>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => I think you're distinguishing between 
> modified and
> >>>>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>>>> the BoF, our
> >>>>>>>>>>>>>>>>> conclusions were that you will either end 
> up modifying
> >>>>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>>>> stick with MIP.
> >>>>>>>>>>>>>>>>> My opinion, and at least half the room's 
> was that this
> >>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>>>> this is such a
> >>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>>>> room was in
> >>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => I think the question changed a few times
> >> :) The final
> >>>>>>>>>>>>>>> question
> >>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>>>> mentioned here
> >>>>>>>>>>>>>>>>> because they were one of the very few reasons
> >> for using
> >>>>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>>>> the host) and
> >>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
> >> section 4 of
> >>>>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>>>> anyway. However if
> >>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>>>> not specify how
> >>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>>>> in all L2s,
> >>>>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why is there as much of a concern about 
> additional SW
> >>>>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>>>> After all everything (or most of it anyway) 
> that we do
> >>>>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
> >> These were the
> >>>>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>>>> scope in IETF
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>>>> could specify
> >>>>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>>>> if that is the
> >>>>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
> >> that when a
> >>>>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>>>> is inferior in
> >>>>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>>>> mostly flow
> >>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> NetExt mailing list
> >>>> NetExt at mail.mobileip.jp
> >>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>
> >>>
> >>>
> >>
> >
> >
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Wed, 8 Apr 2009 15:21:58 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

What is the different between:
- the mobile sending a L2 message named "Attach Type" which triggers the PBU and the HI included in it
- the mobile sending a L3 message named "Registration Request" or "Binding Update"

To me the difference is just that IETF can work on (i.e. define, extend) the latter but not on the former. And that the latter works on any L2 while the former is tied to a particular technology.

Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Sri Gundavelli
> Sent: Wednesday, April 08, 2009 3:12 PM
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
>
> Hi Domagoj,
>
> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".
>
> For other scenarios of multi-attach, there can be policies
> on the network and the terminal, or a L2 signaling as you
> prefer, or an application signaling ..., but sure, there
> may be a need for the coordination between the terminal and
> the network. But, we cannot equate this requirement with
> the client-mobility requirement, with the mobile involved
> in signaling.
>
> Sri
>
>
>
> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>
> > Sri,
> >
> > What you're discribing is a specific type of deployment where the MN is
> > allowed to attach only through a single access at a time. But this prevents
> > multihoming and is not a generic solution. We need a generic solution that
> > works with any type of deployment without artifical restrictions.
> >
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
> >> Sent: 08. travanj 2009 23:47
> >> To: Domagoj Premec
> >> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >> Subject: RE: [Netext] next steps for netext
> >>
> >> Domagoj,
> >>
> >>
> >> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> >>
> >>> Sri,
> >>>
> >>>> - Inter-tech handovers are supported in PMIPv6
> >>>
> >>> I disagree with this statement. In case of inter-tech handover, the
> >>> MAG in the new access needs to send a PBU with the HI set to "2:
> >>> Handoff between two different interfaces of the mobile
> >> node". How does
> >>> the new MAG know that the attachment should be treated as a
> >> handover
> >>> and not as a new session? In the absence of any other
> >> indications, the
> >>> MAG will treat this as a new attachment, which results in
> >> multihoming
> >>> with a different prefix and no handover.
> >>>
> >>
> >> Can a deployment have terminals that only do single attach.
> >> Can that information be tied to the mobile's policy profile.
> >> Is it possible such information is available to the MAG ?
> >>
> >> Can AAA or other session manager have the awareness of the
> >> current existing session. Can the MAG leverage such
> >> information and derive if its a handover or a new attach ?
> >>
> >> So, its possible for the MAG to derive that information from
> >> the network, in many cases, including in 3GPP, as Vijay
> >> pointed out for single attach.
> >>
> >> Sri
> >>
> >>
> >>
> >>
> >>
> >>
> >>> domagoj
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: netext-bounces at mail.mobileip.jp
> >>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> >>>> Gundavelli
> >>>> Sent: 08. travanj 2009 21:51
> >>>> To: Basavaraj.Patil at nokia.com
> >>>> Cc: netext at mail.mobileip.jp
> >>>> Subject: Re: [Netext] next steps for netext
> >>>>
> >>>> I agree, this discussion is going on a different track. This wont
> >>>> converge. Secondly, we are bundling every thing together
> >> and making
> >>>> blanket statements. There are statements,
> >> multi-homing/handover does
> >>>> not work in PMIPv6, or that there needs to be an L2 interface ..
> >>>> there seems to be lot of assumptions around this, with out
> >> qualifying
> >>>> that, these statements are only creating confusion. Couple
> >> of points:
> >>>>
> >>>> - Multihoming is supported in PMIPv6
> >>>> - Inter-tech handovers are supported in PMIPv6
> >>>> - None of these features break or burn the host.
> >>>>
> >>>> 3GPP is not the only consumer for this work. Nothing stops
> >> some one
> >>>> from building an IPv6 enterprise mobility solution based on Proxy
> >>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
> >>>> that can be deployed in enterprise wireless architectures.
> >> No one can
> >>>> tell me, we cant deploy this protocol for solving micro mobility
> >>>> problems in an integrated wired/wireless AP environments,
> >> targetted
> >>>> for an enterprise.
> >>>>
> >>>>> From the list of proposed items, I'd really hope to identify the
> >>>>> work
> >>>> items that does not require extesive debates from the ones that
> >>>> requires fist-fighting.
> >>>>
> >>>> - Flow mobility has the scope from moving individual flows of
> >>>> interest with no relation to prefix, vs moving flows as a bundle
> >>>> associated to a prefix.
> >>>>
> >>>> - Host specific doc, from the point of view of leveraging
> >> what 5213
> >>>> supports, vs, for supporting the new features.
> >>>>
> >>>> - Multi-homing, binding a single prefix to multiple
> >> interfaces, vs,
> >>>> an individual prefix to each interface.
> >>>>
> >>>>
> >>>> We have to qualify the discussions around this, just the
> >> use of the
> >>>> key words multi-homing, inter-tech handovers, flow mobility, and
> >>>> saying is not for PMIP6, is not accurate, does not justify the
> >>>> concern and does not help the discussions. We have to state which
> >>>> specific item has issues and under what scenario's.
> >>>>
> >>>> Thanks
> >>>> Sri
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>>>
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Lets try and keep this discussion focused on technical issues.
> >>>>> The current tone is not very encouraging in some instances.
> >>>>>
> >>>>> The current discussion is overly focused on what 3GPP is
> >>>> doing w.r.t
> >>>>> PMIP6 and future work items. 3GPP tends to use IETF
> >> protocols when
> >>>>> they see a good fit for their architecture and problem scope. We
> >>>>> cannot tell 3GPP to not develop a feature by themselves and
> >>>> instead rely on the IETF to deliver it.
> >>>>> They are free to do whatever they want.
> >>>>>
> >>>>> Within the IETF we can identify what problems or extensions
> >>>> to PMIP6
> >>>>> we want to work on and focus on these. If 3GPP finds the solution
> >>>>> applicable, they will use it. The IETF solution has to
> >> address the
> >>>>> generic problem and not tailored for 3GPP (which is what we
> >>>> seem to be doing now).
> >>>>> So maybe we can get down to discussing the problem and
> >>>> scenarios that
> >>>>> we would like to work on in Netext as a way of moving forward.
> >>>>>
> >>>>> In order to make progress, I would suggest that we focus on the
> >>>>> following 3
> >>>>> topics:
> >>>>> A. Multihoming
> >>>>> B. Flow mobility
> >>>>> C. Inter technology handovers
> >>>>>
> >>>>> If we can articulate the scenarios and associated problems
> >>>> with each
> >>>>> of the same, we can then get a better handle on what to
> >> take on in
> >>>>> Netext. And lets not start saying that we already have a
> >>>> solution in I-Dx or I-Dy.
> >>>>>
> >>>>> -Raj
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >>>> <vijay at wichorus.com> wrote:
> >>>>>
> >>>>>> Hi George,
> >>>>>>
> >>>>>> George Tsirtsis wrote:
> >>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
> >>>>>>> <vijay at wichorus.com>
> >>>>>>> wrote:
> >>>>>>>> Hi Gerardo,
> >>>>>>>>
> >>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
> >>>>>>>>> solutions proposed on any I-D - there is a
> >>>> 3GPP-specific solution
> >>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>>>
> >>>>>>>> This is exactly what I would like to avoid. I would
> >>>> prefer using a
> >>>>>>>> solution developed in the IETF rather than something in 3GPP.
> >>>>>>>>
> >>>>>>>
> >>>>>>> GT> Why not? 3GPP and other SDOs have been creating
> >> technology for
> >>>>>>> almost as long as the IETF. Getting the IETF to do
> >> something only
> >>>>>>> makes sense if the given protocol has general
> >>>> applicability and does
> >>>>>>> not damage the Internet, which is why we are having this
> >>>> discussion.
> >>>>>>
> >>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >>>> very little
> >>>>>> modifications. They have added some vendor specific options for
> >>>>>> carrying some 3GPP specific information, but they are minor
> >>>>>> extensions. So when 3GPP is considering flow mobility for
> >>>> PMIPv6, it
> >>>>>> doesn't make sense for them to develop a solution on their
> >>>> own. It should be done in the IETF.
> >>>>>>
> >>>>>> And can we please stop the hyperbole about "damaging the
> >>>> Internet"?
> >>>>>> It is irritating and doesn't contribute to the discussion.
> >>>>>>
> >>>>>>> GT> In another e-mail where you are over-viewing a
> >>>> possible solution
> >>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
> >>>>>>> signal to indicate what flows need to go to a given
> >> MAG. I do not
> >>>>>>> see how the IETF can define a protocol that fully depends
> >>>> on such an
> >>>>>>> L2 signal. If such functionality is needed then the IETF
> >>>> must define
> >>>>>>> it at the IP layer to make sure that this works across ALL link
> >>>>>>> layers (which is the main reason the IETF and the
> >> Internet exist).
> >>>>>>
> >>>>>> Indicating the service identifier during an L2 attachment is
> >>>>>> supported in most accesses that PMIPv6 is being used for.
> >>>> So I don't
> >>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
> >>>>>> carrying the service identifier. That would be an overkill.
> >>>>>>
> >>>>>> Anyway, flow mobility can still be achieved even if the MN
> >>>> does not
> >>>>>> indicate the service identifier. Please see
> >>>>>>
> >>>>
> >> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>>>
> >>>>>>> GT> So, in my book you (pmip mhoming fans) have two
> >>>> hurdles to overcome:
> >>>>>>> 1) Admit to yourself that to do this in the IETF you need
> >>>> to define
> >>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>>>
> >>>>>> That is one option, but not required.
> >>>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>>> 2) Convince people that defining such a client based
> >> protocol in
> >>>>>>> addition to the existing standard (MIPv6) is warranted. In the
> >>>>>>> process, explain to people why you want to introduce FA
> >>>>>>> functionality to MIPv6, which is what MAGs become if you add an
> >>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>>>
> >>>>>>> George
> >>>>>>>
> >>>>>>>
> >>>>>>>> Vijay
> >>>>>>>>
> >>>>>>>>> 3GPP has not decided yet to do any normative work on
> >> any of the
> >>>>>>>>> solutions.
> >>>>>>>>>
> >>>>>>>>> Gerardo
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>>>> To: Giaretta, Gerardo
> >>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
> >> netext at mail.mobileip.jp;
> >>>>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>>>> list, sorry for that
> >>>>>>>>>>> :-)
> >>>>>>>>>>
> >>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>>>> function though.
> >>>>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>>>> basis for the
> >>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>>>>>> claim not backed
> >>>>>>>>>> by 3GPP.
> >>>>>>>>>>
> >>>>>>>>>> Hesham
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Vijay
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>>>> (discussed at the
> >>>>>>>>>> last
> >>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>>>> WiMAX with PMIPv6
> >>>>>>>>>>>> working.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>> large scale managed networks are the main consumers of
> >>>>>>>>> PMIP6 so we
> >>>>>>>>>>>> shouldn't
> >>>>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>>>>>> note that I am
> >>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>>>> homogeneous from a
> >>>>>>>>>>>> link layer point of view.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Gerardo
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Saying to use MIP for inter-access
> >>>> handovers/multihoming is
> >>>>>>>>>>>>>> not helping as they have
> >>>>>>>>> really set their mind
> >>>>>>>>>> on
> >>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>>>> going into the
> >>>>>>>>>>>> reasoning
> >>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>>>> defined in RFC 5213,
> >>>>>>>>>> has
> >>>>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>>>> better to fix those
> >>>>>>>>>> PMIP6
> >>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>>>> their own way of
> >>>>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> domagoj
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
> >>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
> >> Behalf Of ext
> >>>>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => We're discussing a problem statement for
> >> the BoF, so
> >>>>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>>>> appropriate as a reference for why people
> >> wanted PMIP in
> >>>>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
> >>>>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >>>> use cases.
> >>>>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>>>> host-based mobility
> >>>>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >>>> discussion
> >>>>>>>>>>>>>>> and this discussion on the list. The reason I
> >> don't know
> >>>>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>>>> saying:
> >>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >>>> and PMIP)
> >>>>>>>>>>>>>>> and here is why they don't work, therefore we
> >> need to do
> >>>>>>>>>>>>>>> something new.
> >>>>>>>>>>>>>>> That's what a PS should say. What's being said
> >>>> here is "PMIP
> >>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >>>> something
> >>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
> >>>>>>>>>>>>>>> designed to support those cases because we already have
> >>>>>>>>>>>>>>> something else for supporting those cases. Hence
> >>>> my reference to 4830...
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm going to retire from the discussion till
> >>>> someone makes
> >>>>>>>>>>>>>>> the argument above. Because I feel that if there
> >>>> is no such
> >>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Yes, additional software like the existing
> >>>> MIP. I don't
> >>>>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>>>> the motivation for creating something new.
> >> I've detailed
> >>>>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>>>>>> management
> >>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>>>> seems to be a
> >>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >>>> talking about
> >>>>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> distinguish modification for mobility
> >> management, which
> >>>>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>>>> as the use of
> >>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>>>> configure
> >>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>>>> the BoF, our
> >>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>>>> stick with MIP.
> >>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>>>> this is such a
> >>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>>>> room was in
> >>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => I think the question changed a few times
> >> :) The final
> >>>>>>>>>>>>>>> question
> >>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>>>> mentioned here
> >>>>>>>>>>>>>>>>> because they were one of the very few reasons
> >> for using
> >>>>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>>>> the host) and
> >>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
> >> section 4 of
> >>>>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>>>> anyway. However if
> >>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>>>> not specify how
> >>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>>>> in all L2s,
> >>>>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
> >> These were the
> >>>>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>>>> scope in IETF
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>>>> could specify
> >>>>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>>>> if that is the
> >>>>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
> >> that when a
> >>>>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>>>> is inferior in
> >>>>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>>>> mostly flow
> >>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> 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

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Wed, 8 Apr 2009 18:16:24 -0400
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

That's what I thought, too.
I couldn't find any explanation at the NetEXT charter.
I am more comfortable to say this explicitly in the charter.

regards,
ryuji

On 2009/04/08, at 18:08, Vijay Devarapalli wrote:

> Hi Ryuji,
>
> On 4/8/09 2:52 PM, "Ryuji Wakikawa" <ryuji.wakikawa at gmail.com> wrote:
>
>> Hi Raj,
>>
>> Thanks for this. I agree on what you said in your mail.
>> However, I want to ask one more clarification.
>>
>> I don't want to go to MIP6 vs PMIP6 here, but some of extensions
>> (multihoming, flow mobility,
>> LMA redirection aka HAswithc?) are already covered by MIP6 in MEXT.
>> When we need the similar features to PMIP,
>> will NetEXT solution inherit MIP6 and MIP6-based-extension as RFC5213
>> did?
>> One of goal of RFC5213 was to inherit MIP6 spec as much as possible.
>
> Re-using the solutions developed for MIPv6 is very much desirable. I  
> don't
> think MIPv6 and PMIPv6 will have different mechanisms for carrying  
> the flow
> filters in the BU or the PBU.
>
> Vijay
>
>>
>> PMIP specific issues can be solved anyway, but some of common issues
>> can be
>> solved with the similar extensions to MIP6 or with another extensions
>> to MIP6 extension.
>> After PMIP6 deployment, we will have more common issues between MIP6
>> and PMIP6.
>>
>> It makes sense to take the same approach to solve the same goal at
>> MIP6 and PMIP6.
>>
>> regards,
>> ryuji
>>
>>
>>
>> On 2009/04/08, at 16:29, <Basavaraj.Patil at nokia.com>
>> <Basavaraj.Patil at nokia.com
>>> wrote:
>>
>>>
>>> Hello,
>>>
>>> There is an issue in the current debate that we should put to rest.
>>> Netext proposes to extend PMIP6 to support multihoming, flow  
>>> mobility
>>> and inter-technology handovers (in addition to others over which
>>> there is
>>> an agreement on).
>>>
>>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>>> these capabilities currently. I dont think there is any debate about
>>> that.
>>> However there is an interested group of people within the IETF
>>> community who would like to extend PMIP6 to support these features  
>>> as
>>> well.
>>> It is not uncommon in the IETF to have multiple competing protocols
>>> provide similar functionality. The industry will ultimately choose  
>>> an
>>> appropriate solution depending on the needs. So I dont think we can
>>> just quash the idea of working on these extensions simply because we
>>> already have a protocol that does it.
>>> It is also noted that one of the primary reasons for developing  
>>> PMIP6
>>> was to provide mobility without host involvement. The term
>>> "host-changes" in the context of the current discussion are still  
>>> to a
>>> large extent based on the PMIP6 intent. As long as we are not  
>>> defining
>>> a new protocol on the host, we can consider the host as being
>>> unmodified (from this disucssions PoV).
>>>
>>> In summary I would say that this is not a discussion about whether
>>> host based Mobile IP (MIP6) is the appropriate protocol for  
>>> providing
>>> multihoming, Flow mobility and, inter-tech HOs but rather about what
>>> can be done to provide similar capabilities to PMIP6 without  
>>> (grossly)
>>> changing the basic protocol principles.
>>>
>>> -Raj
>>>
>>> P.S: I recognize that some would say that inter-tech HOs and
>>> multihoming are already features supported by PMIP6. In the current
>>> context of Netext, what is being proposed is basically  
>>> enhancements to
>>> PMIP6 that address scenarios not currently in the base spec.
>>>
>>>
>>> _______________________________________________
>>> 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
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 15:11:40 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".

For other scenarios of multi-attach, there can be policies
on the network and the terminal, or a L2 signaling as you
prefer, or an application signaling ..., but sure, there
may be a need for the coordination between the terminal and
the network. But, we cannot equate this requirement with
the client-mobility requirement, with the mobile involved
in signaling.

Sri

On Wed, 8 Apr 2009, Domagoj Premec wrote:

> Sri,
>
> What you're discribing is a specific type of deployment where the MN is
> allowed to attach only through a single access at a time. But this prevents
> multihoming and is not a generic solution. We need a generic solution that
> works with any type of deployment without artifical restrictions.
>
> domagoj
>
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 08. travanj 2009 23:47
>> To: Domagoj Premec
>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>> Subject: RE: [Netext] next steps for netext
>>
>> Domagoj,
>>
>>
>> On Wed, 8 Apr 2009, Domagoj Premec wrote:
>>
>>> Sri,
>>>
>>>> - Inter-tech handovers are supported in PMIPv6
>>>
>>> I disagree with this statement. In case of inter-tech handover, the
>>> MAG in the new access needs to send a PBU with the HI set to "2:
>>> Handoff between two different interfaces of the mobile
>> node". How does
>>> the new MAG know that the attachment should be treated as a
>> handover
>>> and not as a new session? In the absence of any other
>> indications, the
>>> MAG will treat this as a new attachment, which results in
>> multihoming
>>> with a different prefix and no handover.
>>>
>>
>> Can a deployment have terminals that only do single attach.
>> Can that information be tied to the mobile's policy profile.
>> Is it possible such information is available to the MAG ?
>>
>> Can AAA or other session manager have the awareness of the
>> current existing session. Can the MAG leverage such
>> information and derive if its a handover or a new attach ?
>>
>> So, its possible for the MAG to derive that information from
>> the network, in many cases, including in 3GPP, as Vijay
>> pointed out for single attach.
>>
>> Sri
>>
>>
>>
>>
>>
>>
>>> domagoj
>>>
>>>
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp
>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>> Gundavelli
>>>> Sent: 08. travanj 2009 21:51
>>>> To: Basavaraj.Patil at nokia.com
>>>> Cc: netext at mail.mobileip.jp
>>>> Subject: Re: [Netext] next steps for netext
>>>>
>>>> I agree, this discussion is going on a different track. This wont
>>>> converge. Secondly, we are bundling every thing together
>> and making
>>>> blanket statements. There are statements,
>> multi-homing/handover does
>>>> not work in PMIPv6, or that there needs to be an L2 interface ..
>>>> there seems to be lot of assumptions around this, with out
>> qualifying
>>>> that, these statements are only creating confusion. Couple
>> of points:
>>>>
>>>> - Multihoming is supported in PMIPv6
>>>> - Inter-tech handovers are supported in PMIPv6
>>>> - None of these features break or burn the host.
>>>>
>>>> 3GPP is not the only consumer for this work. Nothing stops
>> some one
>>>> from building an IPv6 enterprise mobility solution based on Proxy
>>>> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol
>>>> that can be deployed in enterprise wireless architectures.
>> No one can
>>>> tell me, we cant deploy this protocol for solving micro mobility
>>>> problems in an integrated wired/wireless AP environments,
>> targetted
>>>> for an enterprise.
>>>>
>>>>> From the list of proposed items, I'd really hope to identify the
>>>>> work
>>>> items that does not require extesive debates from the ones that
>>>> requires fist-fighting.
>>>>
>>>> - Flow mobility has the scope from moving individual flows of
>>>> interest with no relation to prefix, vs moving flows as a bundle
>>>> associated to a prefix.
>>>>
>>>> - Host specific doc, from the point of view of leveraging
>> what 5213
>>>> supports, vs, for supporting the new features.
>>>>
>>>> - Multi-homing, binding a single prefix to multiple
>> interfaces, vs,
>>>> an individual prefix to each interface.
>>>>
>>>>
>>>> We have to qualify the discussions around this, just the
>> use of the
>>>> key words multi-homing, inter-tech handovers, flow mobility, and
>>>> saying is not for PMIP6, is not accurate, does not justify the
>>>> concern and does not help the discussions. We have to state which
>>>> specific item has issues and under what scenario's.
>>>>
>>>> Thanks
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Lets try and keep this discussion focused on technical issues.
>>>>> The current tone is not very encouraging in some instances.
>>>>>
>>>>> The current discussion is overly focused on what 3GPP is
>>>> doing w.r.t
>>>>> PMIP6 and future work items. 3GPP tends to use IETF
>> protocols when
>>>>> they see a good fit for their architecture and problem scope. We
>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>> instead rely on the IETF to deliver it.
>>>>> They are free to do whatever they want.
>>>>>
>>>>> Within the IETF we can identify what problems or extensions
>>>> to PMIP6
>>>>> we want to work on and focus on these. If 3GPP finds the solution
>>>>> applicable, they will use it. The IETF solution has to
>> address the
>>>>> generic problem and not tailored for 3GPP (which is what we
>>>> seem to be doing now).
>>>>> So maybe we can get down to discussing the problem and
>>>> scenarios that
>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>
>>>>> In order to make progress, I would suggest that we focus on the
>>>>> following 3
>>>>> topics:
>>>>> A. Multihoming
>>>>> B. Flow mobility
>>>>> C. Inter technology handovers
>>>>>
>>>>> If we can articulate the scenarios and associated problems
>>>> with each
>>>>> of the same, we can then get a better handle on what to
>> take on in
>>>>> Netext. And lets not start saying that we already have a
>>>> solution in I-Dx or I-Dy.
>>>>>
>>>>> -Raj
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>> <vijay at wichorus.com> wrote:
>>>>>
>>>>>> Hi George,
>>>>>>
>>>>>> George Tsirtsis wrote:
>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>> <vijay at wichorus.com>
>>>>>>> wrote:
>>>>>>>> Hi Gerardo,
>>>>>>>>
>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>> solutions proposed on any I-D - there is a
>>>> 3GPP-specific solution
>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>
>>>>>>>> This is exactly what I would like to avoid. I would
>>>> prefer using a
>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>
>>>>>>>
>>>>>>> GT> Why not? 3GPP and other SDOs have been creating
>> technology for
>>>>>>> almost as long as the IETF. Getting the IETF to do
>> something only
>>>>>>> makes sense if the given protocol has general
>>>> applicability and does
>>>>>>> not damage the Internet, which is why we are having this
>>>> discussion.
>>>>>>
>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>> very little
>>>>>> modifications. They have added some vendor specific options for
>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>> PMIPv6, it
>>>>>> doesn't make sense for them to develop a solution on their
>>>> own. It should be done in the IETF.
>>>>>>
>>>>>> And can we please stop the hyperbole about "damaging the
>>>> Internet"?
>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>
>>>>>>> GT> In another e-mail where you are over-viewing a
>>>> possible solution
>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>>>> signal to indicate what flows need to go to a given
>> MAG. I do not
>>>>>>> see how the IETF can define a protocol that fully depends
>>>> on such an
>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>> must define
>>>>>>> it at the IP layer to make sure that this works across ALL link
>>>>>>> layers (which is the main reason the IETF and the
>> Internet exist).
>>>>>>
>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>> So I don't
>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>
>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>> does not
>>>>>> indicate the service identifier. Please see
>>>>>>
>>>>
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>
>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>> hurdles to overcome:
>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>> to define
>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>
>>>>>> That is one option, but not required.
>>>>>>
>>>>>> Vijay
>>>>>>
>>>>>>> 2) Convince people that defining such a client based
>> protocol in
>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>>>> process, explain to people why you want to introduce FA
>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>
>>>>>>> George
>>>>>>>
>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> 3GPP has not decided yet to do any normative work on
>> any of the
>>>>>>>>> solutions.
>>>>>>>>>
>>>>>>>>> Gerardo
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch';
>> netext at mail.mobileip.jp;
>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>> list, sorry for that
>>>>>>>>>>> :-)
>>>>>>>>>>
>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>> function though.
>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>> basis for the
>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>> claim not backed
>>>>>>>>>> by 3GPP.
>>>>>>>>>>
>>>>>>>>>> Hesham
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gerardo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>> (discussed at the
>>>>>>>>>> last
>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>> working.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>> PMIP6 so we
>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>> note that I am
>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>> homogeneous from a
>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>> handovers/multihoming is
>>>>>>>>>>>>>> not helping as they have
>>>>>>>>> really set their mind
>>>>>>>>>> on
>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>> going into the
>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>> defined in RFC 5213,
>>>>>>>>>> has
>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>> better to fix those
>>>>>>>>>> PMIP6
>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>> their own way of
>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On
>> Behalf Of ext
>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => We're discussing a problem statement for
>> the BoF, so
>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>> appropriate as a reference for why people
>> wanted PMIP in
>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>> use cases.
>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>> discussion
>>>>>>>>>>>>>>> and this discussion on the list. The reason I
>> don't know
>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>> and PMIP)
>>>>>>>>>>>>>>> and here is why they don't work, therefore we
>> need to do
>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>> here is "PMIP
>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>> something
>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>> my reference to 4830...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>> someone makes
>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>> is no such
>>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>> MIP. I don't
>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>> the motivation for creating something new.
>> I've detailed
>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>> management
>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>> talking about
>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> distinguish modification for mobility
>> management, which
>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>> configure
>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>> room was in
>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => I think the question changed a few times
>> :) The final
>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>> because they were one of the very few reasons
>> for using
>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in
>> section 4 of
>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830.
>> These were the
>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>> could specify
>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do
>> that when a
>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> NetExt mailing list
>>>> NetExt at mail.mobileip.jp
>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>
>>>
>>>
>>
>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 08 Apr 2009 15:08:34 -0700
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Ryuji,

On 4/8/09 2:52 PM, "Ryuji Wakikawa" <ryuji.wakikawa at gmail.com> wrote:

> Hi Raj,
> 
> Thanks for this. I agree on what you said in your mail.
> However, I want to ask one more clarification.
> 
> I don't want to go to MIP6 vs PMIP6 here, but some of extensions
> (multihoming, flow mobility,
> LMA redirection aka HAswithc?) are already covered by MIP6 in MEXT.
> When we need the similar features to PMIP,
> will NetEXT solution inherit MIP6 and MIP6-based-extension as RFC5213
> did?
> One of goal of RFC5213 was to inherit MIP6 spec as much as possible.

Re-using the solutions developed for MIPv6 is very much desirable. I don't
think MIPv6 and PMIPv6 will have different mechanisms for carrying the flow
filters in the BU or the PBU.

Vijay

> 
> PMIP specific issues can be solved anyway, but some of common issues
> can be
> solved with the similar extensions to MIP6 or with another extensions
> to MIP6 extension.
> After PMIP6 deployment, we will have more common issues between MIP6
> and PMIP6.
> 
> It makes sense to take the same approach to solve the same goal at
> MIP6 and PMIP6.
> 
> regards,
> ryuji
> 
> 
> 
> On 2009/04/08, at 16:29, <Basavaraj.Patil at nokia.com>
> <Basavaraj.Patil at nokia.com
>> wrote:
> 
>> 
>> Hello,
>> 
>> There is an issue in the current debate that we should put to rest.
>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>> and inter-technology handovers (in addition to others over which
>> there is
>> an agreement on).
>> 
>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>> these capabilities currently. I dont think there is any debate about
>> that.
>> However there is an interested group of people within the IETF
>> community who would like to extend PMIP6 to support these features as
>> well.
>> It is not uncommon in the IETF to have multiple competing protocols
>> provide similar functionality. The industry will ultimately choose an
>> appropriate solution depending on the needs. So I dont think we can
>> just quash the idea of working on these extensions simply because we
>> already have a protocol that does it.
>> It is also noted that one of the primary reasons for developing PMIP6
>> was to provide mobility without host involvement. The term
>> "host-changes" in the context of the current discussion are still to a
>> large extent based on the PMIP6 intent. As long as we are not defining
>> a new protocol on the host, we can consider the host as being
>> unmodified (from this disucssions PoV).
>> 
>> In summary I would say that this is not a discussion about whether
>> host based Mobile IP (MIP6) is the appropriate protocol for providing
>> multihoming, Flow mobility and, inter-tech HOs but rather about what
>> can be done to provide similar capabilities to PMIP6 without (grossly)
>> changing the basic protocol principles.
>> 
>> -Raj
>> 
>> P.S: I recognize that some would say that inter-tech HOs and
>> multihoming are already features supported by PMIP6. In the current
>> context of Netext, what is being proposed is basically enhancements to
>> PMIP6 that address scenarios not currently in the base spec.
>> 
>> 
>> _______________________________________________
>> 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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 15:07:37 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 8 Apr 2009, Giaretta, Gerardo wrote:

>>
>> Can a deployment have terminals that only do single attach. Can
>> that information be tied to the mobile's policy profile. Is it
>> possible such information is available to the MAG ?
>>
>> Can AAA or other session manager have the awareness of the current
>> existing session. Can the MAG leverage such information and
>> derive if its a handover or a new attach ?
>>
>> So, its possible for the MAG to derive that information from the
>> network, in many cases, including in 3GPP, as Vijay pointed out
>> for single attach.
>>
>
> This is done by a special L2 message introduced for that - i.e. a change of the host (which is not visible to IETF as it is done at L2 and not L3, but still very real)
>

We can indeed define a L2 message, allow the network to make that
decision, or allow it to push policy templates to the terminal.

In any case, changes to host, in the form of application requirement
or connection manager requirement, or any application layer policy
push, does not break IETF standards. If some operator wants to install
such application on the terminal, I wonder why we should have a problem.
Also, IMO, we are dreaming, if we assume that any operator will qualify
any host on their network, with out zero software addition. Looking
at EV-DO deployments today, all operators ship connection manager
software.  We can solve this problem, with or without changing the
IETF host protocols.

Sri

> Gerardo
>
>
>> Sri
>>
>>
>>
>>
>>
>>
>>> domagoj
>>>
>>>
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp
>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>>>> Gundavelli
>>>> Sent: 08. travanj 2009 21:51
>>>> To: Basavaraj.Patil at nokia.com
>>>> Cc: netext at mail.mobileip.jp
>>>> Subject: Re: [Netext] next steps for netext
>>>>
>>>> I agree, this discussion is going on a different track. This
>>>> wont converge. Secondly, we are bundling every thing together
>>>> and making blanket statements. There are statements,
>>>> multi-homing/handover does not work in PMIPv6, or that there
>>>> needs to be an L2 interface ..
>>>> there seems to be lot of assumptions around this, with out
>>>> qualifying that, these statements are only creating
>>>> confusion. Couple of points:
>>>>
>>>> - Multihoming is supported in PMIPv6
>>>> - Inter-tech handovers are supported in PMIPv6
>>>> - None of these features break or burn the host.
>>>>
>>>> 3GPP is not the only consumer for this work. Nothing stops
>>>> some one from building an IPv6 enterprise mobility solution
>>>> based on Proxy Mobile IPv6, as it is not a 3GPP specific
>>>> protocol, but a protocol that can be deployed in enterprise
>>>> wireless architectures. No one can tell me, we cant deploy
>>>> this protocol for solving micro mobility problems in an
>>>> integrated wired/wireless AP environments, targetted for an
>>>> enterprise.
>>>>
>>>>> From the list of proposed items, I'd really hope to identify the work
>>>> items that does not require extesive debates from the ones
>>>> that requires fist-fighting.
>>>>
>>>> - Flow mobility has the scope from moving individual flows of
>>>> interest with no relation to prefix, vs moving flows as a
>>>> bundle associated to a prefix.
>>>>
>>>> - Host specific doc, from the point of view of leveraging
>>>> what 5213 supports, vs, for supporting the new features.
>>>>
>>>> - Multi-homing, binding a single prefix to multiple
>>>> interfaces, vs, an individual prefix to each interface.
>>>>
>>>>
>>>> We have to qualify the discussions around this, just the use
>>>> of the key words multi-homing, inter-tech handovers, flow
>>>> mobility, and saying is not for PMIP6, is not accurate, does
>>>> not justify the concern and does not help the discussions. We
>>>> have to state which specific item has issues and under what
>>>> scenario's.
>>>>
>>>> Thanks
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Lets try and keep this discussion focused on technical issues.
>>>>> The current tone is not very encouraging in some instances.
>>>>>
>>>>> The current discussion is overly focused on what 3GPP is
>>>> doing w.r.t
>>>>> PMIP6 and future work items. 3GPP tends to use IETF protocols when
>>>>> they see a good fit for their architecture and problem scope. We
>>>>> cannot tell 3GPP to not develop a feature by themselves and
>>>> instead rely on the IETF to deliver it.
>>>>> They are free to do whatever they want.
>>>>>
>>>>> Within the IETF we can identify what problems or extensions
>>>> to PMIP6
>>>>> we want to work on and focus on these. If 3GPP finds the solution
>>>>> applicable, they will use it. The IETF solution has to address the
>>>>> generic problem and not tailored for 3GPP (which is what we
>>>> seem to be doing now).
>>>>> So maybe we can get down to discussing the problem and
>>>> scenarios that
>>>>> we would like to work on in Netext as a way of moving forward.
>>>>>
>>>>> In order to make progress, I would suggest that we focus on the
>>>>> following 3
>>>>> topics:
>>>>> A. Multihoming
>>>>> B. Flow mobility
>>>>> C. Inter technology handovers
>>>>>
>>>>> If we can articulate the scenarios and associated problems
>>>> with each
>>>>> of the same, we can then get a better handle on what to take on in
>>>>> Netext. And lets not start saying that we already have a
>>>> solution in I-Dx or I-Dy.
>>>>>
>>>>> -Raj
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>>>> <vijay at wichorus.com> wrote:
>>>>>
>>>>>> Hi George,
>>>>>>
>>>>>> George Tsirtsis wrote:
>>>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>>>> <vijay at wichorus.com>
>>>>>>> wrote:
>>>>>>>> Hi Gerardo,
>>>>>>>>
>>>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>>>> solutions proposed on any I-D - there is a
>>>> 3GPP-specific solution
>>>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>>>
>>>>>>>> This is exactly what I would like to avoid. I would
>>>> prefer using a
>>>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>>>
>>>>>>>
>>>>>>> GT> Why not? 3GPP and other SDOs have been creating technology for
>>>>>>> almost as long as the IETF. Getting the IETF to do something only
>>>>>>> makes sense if the given protocol has general
>>>> applicability and does
>>>>>>> not damage the Internet, which is why we are having this
>>>> discussion.
>>>>>>
>>>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>>>> very little
>>>>>> modifications. They have added some vendor specific options for
>>>>>> carrying some 3GPP specific information, but they are minor
>>>>>> extensions. So when 3GPP is considering flow mobility for
>>>> PMIPv6, it
>>>>>> doesn't make sense for them to develop a solution on their
>>>> own. It should be done in the IETF.
>>>>>>
>>>>>> And can we please stop the hyperbole about "damaging the
>>>> Internet"?
>>>>>> It is irritating and doesn't contribute to the discussion.
>>>>>>
>>>>>>> GT> In another e-mail where you are over-viewing a
>>>> possible solution
>>>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>>>> signal to indicate what flows need to go to a given MAG. I do not
>>>>>>> see how the IETF can define a protocol that fully depends
>>>> on such an
>>>>>>> L2 signal. If such functionality is needed then the IETF
>>>> must define
>>>>>>> it at the IP layer to make sure that this works across ALL link
>>>>>>> layers (which is the main reason the IETF and the Internet exist).
>>>>>>
>>>>>> Indicating the service identifier during an L2 attachment is
>>>>>> supported in most accesses that PMIPv6 is being used for.
>>>> So I don't
>>>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>>>> carrying the service identifier. That would be an overkill.
>>>>>>
>>>>>> Anyway, flow mobility can still be achieved even if the MN
>>>> does not
>>>>>> indicate the service identifier. Please see
>>>>>>
>>>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>>>
>>>>>>> GT> So, in my book you (pmip mhoming fans) have two
>>>> hurdles to overcome:
>>>>>>> 1) Admit to yourself that to do this in the IETF you need
>>>> to define
>>>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>>>
>>>>>> That is one option, but not required.
>>>>>>
>>>>>> Vijay
>>>>>>
>>>>>>> 2) Convince people that defining such a client based protocol in
>>>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>>>> process, explain to people why you want to introduce FA
>>>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>>>
>>>>>>> George
>>>>>>>
>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> 3GPP has not decided yet to do any normative work on any of the
>>>>>>>>> solutions.
>>>>>>>>>
>>>>>>>>> Gerardo
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>>>> To: Giaretta, Gerardo
>>>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>>>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>>>> list, sorry for that
>>>>>>>>>>> :-)
>>>>>>>>>>
>>>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>>>> function though.
>>>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>>>> basis for the
>>>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>>>> claim not backed
>>>>>>>>>> by 3GPP.
>>>>>>>>>>
>>>>>>>>>> Hesham
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gerardo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>>>> (discussed at the
>>>>>>>>>> last
>>>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>>>> WiMAX with PMIPv6
>>>>>>>>>>>> working.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>>>> PMIP6 so we
>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>>>> note that I am
>>>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>>>> homogeneous from a
>>>>>>>>>>>> link layer point of view.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gerardo
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Saying to use MIP for inter-access
>>>> handovers/multihoming is
>>>>>>>>>>>>>> not helping as they have
>>>>>>>>> really set their mind
>>>>>>>>>> on
>>>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>>>> going into the
>>>>>>>>>>>> reasoning
>>>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>>>> defined in RFC 5213,
>>>>>>>>>> has
>>>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>>>> better to fix those
>>>>>>>>>> PMIP6
>>>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>>>> their own way of
>>>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> domagoj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>>>> use cases.
>>>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>>>> host-based mobility
>>>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>>>> discussion
>>>>>>>>>>>>>>> and this discussion on the list. The reason I don't know
>>>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>>>> and PMIP)
>>>>>>>>>>>>>>> and here is why they don't work, therefore we need to do
>>>>>>>>>>>>>>> something new.
>>>>>>>>>>>>>>> That's what a PS should say. What's being said
>>>> here is "PMIP
>>>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>>>> something
>>>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>>>>> something else for supporting those cases. Hence
>>>> my reference to 4830...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm going to retire from the discussion till
>>>> someone makes
>>>>>>>>>>>>>>> the argument above. Because I feel that if there
>>>> is no such
>>>>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Yes, additional software like the existing
>>>> MIP. I don't
>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>> the motivation for creating something new. I've detailed
>>>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>>>> management
>>>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>>>> seems to be a
>>>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>>>> talking about
>>>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> distinguish modification for mobility management, which
>>>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>>>> as the use of
>>>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>>>> configure
>>>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>>>> the BoF, our
>>>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>>>> stick with MIP.
>>>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>>>> this is such a
>>>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>>>> room was in
>>>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => I think the question changed a few times :) The final
>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>>>> mentioned here
>>>>>>>>>>>>>>>>> because they were one of the very few reasons for using
>>>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>>>> the host) and
>>>>>>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>>>> anyway. However if
>>>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>>>> not specify how
>>>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>>>> in all L2s,
>>>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>>>> scope in IETF
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>>>> could specify
>>>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>>>> if that is the
>>>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>>>> is inferior in
>>>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>>>> mostly flow
>>>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 08 Apr 2009 15:06:44 -0700
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Couldn't agree more. Thanks Raj.

Vijay

On 4/8/09 1:29 PM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
wrote:

> 
> Hello,
> 
> There is an issue in the current debate that we should put to rest.
> Netext proposes to extend PMIP6 to support multihoming, flow mobility
> and inter-technology handovers (in addition to others over which there is
> an agreement on).
> 
> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
> these capabilities currently. I dont think there is any debate about
> that. 
> However there is an interested group of people within the IETF
> community who would like to extend PMIP6 to support these features as
> well. 
> It is not uncommon in the IETF to have multiple competing protocols
> provide similar functionality. The industry will ultimately choose an
> appropriate solution depending on the needs. So I dont think we can
> just quash the idea of working on these extensions simply because we
> already have a protocol that does it.
> It is also noted that one of the primary reasons for developing PMIP6
> was to provide mobility without host involvement. The term
> "host-changes" in the context of the current discussion are still to a
> large extent based on the PMIP6 intent. As long as we are not defining
> a new protocol on the host, we can consider the host as being
> unmodified (from this disucssions PoV).
> 
> In summary I would say that this is not a discussion about whether
> host based Mobile IP (MIP6) is the appropriate protocol for providing
> multihoming, Flow mobility and, inter-tech HOs but rather about what
> can be done to provide similar capabilities to PMIP6 without (grossly)
> changing the basic protocol principles.
> 
> -Raj
> 
> P.S: I recognize that some would say that inter-tech HOs and
> multihoming are already features supported by PMIP6. In the current
> context of Netext, what is being proposed is basically enhancements to
> PMIP6 that address scenarios not currently in the base spec.
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Wed, 8 Apr 2009 18:04:21 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Carlos,

On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:

> Hi Behcet,
>
> I've quickly checked the document. I think it does address the same
> problem I was referring to. This draft addresses the problem of
> delegating a prefix to a router that attaches to a PMIPv6 domain, so
> it can provide connectivity to nodes attached to it. I think this was
> already discussed in a past meeting (a draft with the problem
> statement) and I mentioned that IMHO this can basically be achieved by
> just using plain NEMO support on the router. The only difference in
> this draft is that it doesn't impose the router to be a NEMO RFC3963
> MR, although still it needs to do some additional things that a normal
> router (not mobile) doesn't. Anyway, I'm not against this type of
> support if there are scenarios in which it's useful.

In the doc, we just specify how to get mobile network prefix from DHCP- 
DR.
DHCP-PD is that normal router does, right?

> However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> bit beyond that, since what I want to enable is node to be able to
> benefit from network based localised mobility support not only when
> roaming between fixed points of attachment (this is what RFC5213 does
> today) but also when roaming between fixed and mobile points of
> attachment. What people do think about this scenario?

I don't know what is fixed and mobile points of attachment. You can  
clarify these.

ryuji

>
>
> Thanks,
>
> Carlos
>
> 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>> Hi Carlos,
>>   Check this out:
>> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo- 
>> support-00
>>
>> Regards,
>>
>> Behcet
>>
>> ________________________________
>> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>> To: Jari Arkko <jari.arkko at piuha.net>
>> Cc: netext at mail.mobileip.jp
>> Sent: Tuesday, April 7, 2009 6:15:42 AM
>> Subject: Re: [Netext] next steps for netext
>>
>> Hi Jari, all,
>>
>> Regarding the NEMO topic, I don't know what Sri has in mind, but my
>> personal view on that is that it'd be nice to extend PMIPv6 to  
>> support
>> mobile networks. What I mean here is that it'd be nice to enable MAGs
>> to also move (like MRs, but without even supporting RFC3963), so an  
>> MR
>> would be able to move between fixed and mobile MAGs without changing
>> its IP address (same support RFC5213 gives now). There are some
>> interesting scenarios that could benefit from this.
>>
>> What do others think? It is interesting to work on this?
>>
>> Thanks,
>>
>> Carlos
>>
>> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>>> Sri,
>>>
>>> Thanks for your input. Inline:
>>>
>>>> I've a concern with the planned charter. The list is too random and
>>>> cherry picked and I dont believe proper input from all the folks  
>>>> went
>>>> into
>>>> this. There are many other items that are required for a reasonable
>>>> deployment of Proxy Mobile IPv6. Many items were proposed over  
>>>> the last 2
>>>> years, some of them that were left out in the base spec, some  
>>>> that we
>>>> realized as gaps when compared to other SDO protocols and some as
>>>> optimizations that we realized while implementing PMIP6, these  
>>>> items
>>>> should be in the initial scope.
>>>>
>>>> I understand the charter needs to be limited in scope, but just 3  
>>>> or 4
>>>> random items, I'm not sure if this helps in short term PMIP6
>>>> requirements.
>>>> I've no issue with the currently listed items, but there are  
>>>> other items
>>>> that should get equal or higher priority.
>>>
>>> I have no problem with adding more. Even the charter says new  
>>> things can
>>> be
>>> added.
>>>
>>> However, from a process perspective what I did was to take the  
>>> proposal on
>>> the table, i.e., the full BOF scope and see what parts of that we  
>>> already
>>> have an agreement on. I didn't include other things that were not
>>> discussed
>>> in the BOF. Maybe that would have been useful, but they were not  
>>> on the
>>> table.
>>>
>>> We could add more items now, if there's general agreement that those
>>> things
>>> are useful. However, I do not want to declare an open season on  
>>> doing
>>> everything. We pick a reasonable subset of all proposed work,  
>>> based on
>>> priorities, community agreement that they are the right things to  
>>> do,
>>> management reasons to ensure that we are not doing too much, etc.
>>>
>>>> For example, item #6, is absolutely required, from the  
>>>> perspective of
>>>> having a complete specification of 5213. There we allowed a  
>>>> mobile node
>>>> to
>>>> perform handoff betweek two interfaces. We defined all the hooks  
>>>> on the
>>>> network side, but we did not provide how a terminal vendor can  
>>>> support
>>>> that. A simple informational draft on how some one move prefixes  
>>>> between
>>>> interfaces will greatly help. Some guidance on how to create a  
>>>> virtual
>>>> interface and also some related notes for each platform (Linux,  
>>>> BSD,
>>>> Android ..etc). This should not fall in the controversial  
>>>> discussion
>>>> scope
>>>> of same address on two interfaces etc, thats a different problem,  
>>>> or
>>>> about
>>>> the issue of enhancing mobile node's capabilities. This is just
>>>> informational work, required to leverage what 5213 already  
>>>> supports.
>>>
>>> I suspect this is about the scoping of the handoff work. Lets try to
>>> figure
>>> out what makes sense (I personally believe the above item makes  
>>> sense, for
>>> instance) and what doesn't.
>>>
>>> The fact that these parts were not in the charter was not a  
>>> declaration
>>> that
>>> we're dismissing them. Its just that we didn't finish the  
>>> discussion, but
>>> I
>>> still wanted to let the other things move forward.
>>>
>>>> Item #2, is required. The multimob BOF raised some issues, we  
>>>> need to
>>>> show how multicast services can be enabled in PMIP network. May  
>>>> be this
>>>> wont require extensions, a simple draft covering those aspects  
>>>> will help.
>>>
>>> As you may recall, in the Multimob BOF we did not have an  
>>> agreement on
>>> what
>>> exactly is needed, if anything. My own conclusion is that we  
>>> probably need
>>> at least an informational document that explains how to use RFC  
>>> 5213 for
>>> multicast. I think we discussed the possibility of doing this as  
>>> some kind
>>> of AD sponsored document or in one of the relevant WGs, as a joint  
>>> work
>>> between PMIP and multicast experts.
>>>
>>> I'm on the fence about adding this work to the charter right now,  
>>> mainly
>>> because the BOF back then was very inconclusive. I'd be happier if  
>>> I saw
>>> an
>>> actual well written draft from say you and some of the multicast  
>>> experts.
>>> There's no problem moving good documents forward, even if they are  
>>> not in
>>> the charter of some WG. Then again, I wouldn't necessarily mind a
>>> maintenance like item for this in one of the WG charters either.
>>>
>>>> I think, the charter should be bit more relaxed and more  
>>>> extensive. As I
>>>> see it, atleast the folks are interested in doing the work. We  
>>>> should add
>>>> atleast 4 or 5 more items to this list.
>>>
>>> Generally speaking IETF WG charters give specific work items that  
>>> the WG
>>> should work on. I had hoped that the charter text:
>>>
>>> "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."
>>>
>>> gives an indication that we intend to do more! I am also  
>>> personally very
>>> happy to add more items to the group's charter. All in all, I do  
>>> know that
>>> the current charter is a bit on the thin side -- mostly because the
>>> multihoming/interaccess issue is under discussion.
>>>
>>> There's also the question of general maintenance items. Some IETF  
>>> WGs have
>>> a
>>> general work item to fix problems and issue updates to existing
>>> specifications. I think we need to do that for Proxy Mobile IPv6  
>>> as well.
>>> But we have not decided whether that item should go to NETLMM or  
>>> NETEXT WG
>>> yet. Please rest assured that the work will be possible regardless  
>>> of
>>> this.
>>>
>>>> 1. Dynamic LMA Assignment
>>>>
>>>> In blade architecture systems or in a load balancer  
>>>> configuration, the
>>>> PDNGW
>>>> should have the ability to dynamically assign a LMA on the fly,  
>>>> along the
>>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>>>> [RFC-4433].
>>>> Currently, GTP provides such semantics and this is a important
>>>> requirement
>>>> for deployment. Here the goal is to
>>>>
>>>> a.) Expose a single IP address to the SGW
>>>> b.) The exposed IP address should not be in path once the  
>>>> assignment is
>>>> done.
>>>>
>>>>
>>>>
>>>> [LMA1]---
>>>> | |
>>>> [LMA2]--[LMA]==========[MAG]
>>>> | |
>>>> [LMA3]---
>>>>
>>>>
>>>> Along the lines of:
>>>>
>>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>>>
>>> This is in the proposed NETEXT charter already.
>>>
>>>> 2. Multicast Support in Proxy Mobile IPv6
>>>>
>>>> We need an informational specification on how multicast support  
>>>> can be
>>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>>>> analysis
>>>> on
>>>> this. This is required and critical for enabling any multicast  
>>>> services.
>>>> However,
>>>> Behcet may disagree with the scope of the work.
>>>
>>> See above.
>>>
>>>> 3. Bulk Registration Support
>>>>
>>>> This is a simple extension which helps in signaling optimization,  
>>>> along
>>>> the
>>>> lines of:
>>>>
>>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>>>
>>> This is in the charter as well.
>>>
>>>> 4. Partial Failover Support
>>>>
>>>> We need a mechanism to notify the peer on revoke a partial set of
>>>> bindings.
>>>>
>>>>
>>>>
>>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00 
>>>> .
>>>> txt
>>>
>>> Hmm. Ok. This needs more discussion.
>>>
>>>> 5. Group Identifier Support for Proxy Mobile IPv6
>>>>
>>>> This provides a simple and a generic semantic for assigning a group
>>>> identifier
>>>> to a mobile node's binding. GTP has very similar semantics,  
>>>> Connexion Set
>>>> Id.
>>>> Both #3 and #4 can leverage this. Additionally, in load balancer  
>>>> systems
>>>> where
>>>> the load balancer is in path for all signaling messages, it can  
>>>> use this
>>>> as
>>>> a
>>>> tag for redirecting the message.
>>>>
>>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>>>
>>> Since the bulk registration work is in the charter, can't you do the
>>> sensible design (whatever it is) under that? There is no  
>>> requirement that
>>> one charter item equals one document.
>>>
>>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>>>> handoffs:
>>>>
>>>>
>>>> RFC-5213 supports handoff between two interfaces. The ability to  
>>>> move
>>>> prefixes between interfaces. In other words address continuity is  
>>>> assured
>>>> with any IPv6 host on the planet and with absolutely no changes.  
>>>> This
>>>> meets
>>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,  
>>>> what is
>>>> not assured is the aspect of session continuity. Which requires a  
>>>> virtual
>>>> interface implementation on the host, by binding the address/ 
>>>> prefix to a
>>>> virtual interface and by not exposing the physical interface or  
>>>> by hiding
>>>> the handoff events from the layer-3 stack.
>>>>
>>>> In essence, we need an informational specification which provides  
>>>> some
>>>> general guidance to how to leverage the feature support provided in
>>>> RFC-5213,
>>>> along the lines of:
>>>>
>>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>>>
>>> This is part of the discussion that we need to finish. But I plan  
>>> to let
>>> the
>>> rest of the stuff move forward even before we have done that.
>>>
>>>
>>>> 7. Route Optimization for Proxy Mobile IPv6
>>>>
>>>> There were atleast 4 drafts in this area on Route Optimization.  
>>>> Marco
>>>> Liebsch
>>>> analyzed this exensively:
>>>>
>>>>
>>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>>>>
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00 
>>>> .
>>>> txt
>>>
>>> This is in the charter.
>>>
>>>> 8. Prefix Management in Proxy Mobile IPv6 support
>>>>
>>>> Proxy Mobile IPv6 allows the assignment of multiple home network  
>>>> prefixes
>>>> to a given mobile node's interface. It might be useful to specify  
>>>> how the
>>>> LMA manages this aspects. It can potentially use DHCP PD, Local  
>>>> Pools or
>>>> AAA to manage this aspect. Behcet has one draft on this.
>>>
>>> I'm not personally sold on this particular work. But again, this  
>>> could be
>>> something to consider.
>>>
>>>> 9. Partial Handoff Support
>>>>
>>>> We are missing some semantics in 5213 for moving a subset of the  
>>>> prefixes
>>>> between interfaces as part of the inter-tech handoff. This is about
>>>> defining
>>>> a new handoff value. This allows partial flow management, but  
>>>> moving the
>>>> flows associated to a prefix, as a whole group.
>>>>
>>>>
>>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>>>
>>> A part of the topic we still need to discuss...
>>>
>>>> 10. CMIPv4/PMIP Interworking
>>>>
>>>> This is probably required to specify how an IPv4-only can move  
>>>> between
>>>> CMIP and PMIP environments.
>>>>
>>>>
>>>>
>>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>>>> meghana-netlmm-pmipv6-mipv4-00.txt
>>>
>>> Client MIPv6 and Proxy MIPv6 interoperability is already in the  
>>> NETLMM
>>> charter, but this work is presumably about interaction with MIPv4.  
>>> Might
>>> be
>>> useful work, I wouldn't mind if this was done in NETEXT at some  
>>> point. Is
>>> this crucial to be in the first revision of the WG's charter?
>>>
>>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>>>
>>> Can you expand on this?
>>>
>>> Jari
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Thu, 09 Apr 2009 09:03:06 +1100
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj, 

On 9/04/09 7:29 AM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
wrote:

> 
> Hello,
> 
> There is an issue in the current debate that we should put to rest.
> Netext proposes to extend PMIP6 to support multihoming, flow mobility
> and inter-technology handovers (in addition to others over which there is
> an agreement on).
> 
> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
> these capabilities currently. I dont think there is any debate about
> that. 
> However there is an interested group of people within the IETF
> community who would like to extend PMIP6 to support these features as
> well. 

=> Ok but without a PS, without justification, nothing? I mean if that's the
case why have a BoF? Everyone keeps talking about the market needs. If this
is the only reason for having these functions then we may as well send a
business plan to Jari instead of having a BoF :). Market needs usually tell
us the problem that needs to be solved, not *how* to solve it.

> It is not uncommon in the IETF to have multiple competing protocols
> provide similar functionality. The industry will ultimately choose an
> appropriate solution depending on the needs. So I dont think we can
> just quash the idea of working on these extensions simply because we
> already have a protocol that does it.
> It is also noted that one of the primary reasons for developing PMIP6
> was to provide mobility without host involvement.

=> Yes but least for netlmm there was a PS and *some* technical arguments.
Mostly bogus IMO but at least they took place. Here everyone is singing in
concert about how to solve things and completely refusing to say why.
Actually some people explicitly said that on the list.

It's sad that this level of discussion is taking place to justify a WG.
Remember the discussions you had to manage for PANA or other WGs you
chaired? Very different. I think it's good that you're encouraging people to
discuss the technical problems, and it's good that they're agreeing, but
unfortunately it's not happening. That should tell us something...

Hesham

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Wed, 8 Apr 2009 18:01:15 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Carlos,

On 2009/04/07, at 7:15, Carlos Jes?s Bernardos Cano wrote:

> Hi Jari, all,
>
> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> personal view on that is that it'd be nice to extend PMIPv6 to support
> mobile networks. What I mean here is that it'd be nice to enable MAGs
> to also move (like MRs, but without even supporting RFC3963), so an MR
> would be able to move between fixed and mobile MAGs without changing
> its IP address (same support RFC5213 gives now). There are some
> interesting scenarios that could benefit from this.

It sounds interesting, but what is the benefit of this?
For supporting NEMO, which prefix will you assign to hosts under the  
MR (MAG)?
The prefix is not assigned to MAG, but to a mobile host in RFC5213.

ryuji

>
>
> What do others think? It is interesting to work on this?
>
> Thanks,
>
> Carlos
>
> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>> Sri,
>>
>> Thanks for your input. Inline:
>>
>>> I've a concern with the planned charter. The list is too random and
>>> cherry picked and I dont believe proper input from all the folks  
>>> went into
>>> this. There are many other items that are required for a reasonable
>>> deployment of Proxy Mobile IPv6. Many items were proposed over the  
>>> last 2
>>> years, some of them that were left out in the base spec, some that  
>>> we
>>> realized as gaps when compared to other SDO protocols and some as
>>> optimizations that we realized while implementing PMIP6, these items
>>> should be in the initial scope.
>>>
>>> I understand the charter needs to be limited in scope, but just 3  
>>> or 4
>>> random items, I'm not sure if this helps in short term PMIP6  
>>> requirements.
>>> I've no issue with the currently listed items, but there are other  
>>> items
>>> that should get equal or higher priority.
>>
>> I have no problem with adding more. Even the charter says new  
>> things can be
>> added.
>>
>> However, from a process perspective what I did was to take the  
>> proposal on
>> the table, i.e., the full BOF scope and see what parts of that we  
>> already
>> have an agreement on. I didn't include other things that were not  
>> discussed
>> in the BOF. Maybe that would have been useful, but they were not on  
>> the
>> table.
>>
>> We could add more items now, if there's general agreement that  
>> those things
>> are useful. However, I do not want to declare an open season on doing
>> everything. We pick a reasonable subset of all proposed work, based  
>> on
>> priorities, community agreement that they are the right things to do,
>> management reasons to ensure that we are not doing too much, etc.
>>
>>> For example, item #6, is absolutely required, from the perspective  
>>> of
>>> having a complete specification of 5213. There we allowed a mobile  
>>> node to
>>> perform handoff betweek two interfaces. We defined all the hooks  
>>> on the
>>> network side, but we did not provide how a terminal vendor can  
>>> support
>>> that. A simple informational draft on how some one move prefixes  
>>> between
>>> interfaces will greatly help. Some guidance on how to create a  
>>> virtual
>>> interface and also some related notes for each platform (Linux, BSD,
>>> Android ..etc). This should not fall in the controversial  
>>> discussion scope
>>> of same address on two interfaces etc, thats a different problem,  
>>> or about
>>> the issue of enhancing mobile node's capabilities. This is just
>>> informational work, required to leverage what 5213 already supports.
>>
>> I suspect this is about the scoping of the handoff work. Lets try  
>> to figure
>> out what makes sense (I personally believe the above item makes  
>> sense, for
>> instance) and what doesn't.
>>
>> The fact that these parts were not in the charter was not a  
>> declaration that
>> we're dismissing them. Its just that we didn't finish the  
>> discussion, but I
>> still wanted to let the other things move forward.
>>
>>> Item #2, is required. The multimob BOF raised some issues, we need  
>>> to
>>> show how multicast services can be enabled in PMIP network. May be  
>>> this
>>> wont require extensions, a simple draft covering those aspects  
>>> will help.
>>
>> As you may recall, in the Multimob BOF we did not have an agreement  
>> on what
>> exactly is needed, if anything. My own conclusion is that we  
>> probably need
>> at least an informational document that explains how to use RFC  
>> 5213 for
>> multicast. I think we discussed the possibility of doing this as  
>> some kind
>> of AD sponsored document or in one of the relevant WGs, as a joint  
>> work
>> between PMIP and multicast experts.
>>
>> I'm on the fence about adding this work to the charter right now,  
>> mainly
>> because the BOF back then was very inconclusive. I'd be happier if  
>> I saw an
>> actual well written draft from say you and some of the multicast  
>> experts.
>> There's no problem moving good documents forward, even if they are  
>> not in
>> the charter of some WG. Then again, I wouldn't necessarily mind a
>> maintenance like item for this in one of the WG charters either.
>>
>>> I think, the charter should be bit more relaxed and more  
>>> extensive. As I
>>> see it, atleast the folks are interested in doing the work. We  
>>> should add
>>> atleast 4 or 5 more items to this list.
>>
>> Generally speaking IETF WG charters give specific work items that  
>> the WG
>> should work on. I had hoped that the charter text:
>>
>> "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."
>>
>> gives an indication that we intend to do more! I am also personally  
>> very
>> happy to add more items to the group's charter. All in all, I do  
>> know that
>> the current charter is a bit on the thin side -- mostly because the
>> multihoming/interaccess issue is under discussion.
>>
>> There's also the question of general maintenance items. Some IETF  
>> WGs have a
>> general work item to fix problems and issue updates to existing
>> specifications. I think we need to do that for Proxy Mobile IPv6 as  
>> well.
>> But we have not decided whether that item should go to NETLMM or  
>> NETEXT WG
>> yet. Please rest assured that the work will be possible regardless  
>> of this.
>>
>>> 1. Dynamic LMA Assignment
>>>
>>> In blade architecture systems or in a load balancer configuration,  
>>> the
>>> PDNGW
>>> should have the ability to dynamically assign a LMA on the fly,  
>>> along the
>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>>> [RFC-4433].
>>> Currently, GTP provides such semantics and this is a important  
>>> requirement
>>> for deployment. Here the goal is to
>>>
>>> a.) Expose a single IP address to the SGW
>>> b.) The exposed IP address should not be in path once the  
>>> assignment is
>>> done.
>>>
>>>
>>>
>>> [LMA1]---
>>> | |
>>> [LMA2]--[LMA]==========[MAG]
>>> | |
>>> [LMA3]---
>>>
>>>
>>> Along the lines of:
>>>
>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>>
>> This is in the proposed NETEXT charter already.
>>
>>> 2. Multicast Support in Proxy Mobile IPv6
>>>
>>> We need an informational specification on how multicast support  
>>> can be
>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>>> analysis
>>> on
>>> this. This is required and critical for enabling any multicast  
>>> services.
>>> However,
>>> Behcet may disagree with the scope of the work.
>>
>> See above.
>>
>>> 3. Bulk Registration Support
>>>
>>> This is a simple extension which helps in signaling optimization,  
>>> along
>>> the
>>> lines of:
>>>
>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>>
>> This is in the charter as well.
>>
>>> 4. Partial Failover Support
>>>
>>> We need a mechanism to notify the peer on revoke a partial set of
>>> bindings.
>>>
>>>
>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00 
>>> .
>>> txt
>>
>> Hmm. Ok. This needs more discussion.
>>
>>> 5. Group Identifier Support for Proxy Mobile IPv6
>>>
>>> This provides a simple and a generic semantic for assigning a group
>>> identifier
>>> to a mobile node's binding. GTP has very similar semantics,  
>>> Connexion Set
>>> Id.
>>> Both #3 and #4 can leverage this. Additionally, in load balancer  
>>> systems
>>> where
>>> the load balancer is in path for all signaling messages, it can  
>>> use this
>>> as
>>> a
>>> tag for redirecting the message.
>>>
>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>>
>> Since the bulk registration work is in the charter, can't you do the
>> sensible design (whatever it is) under that? There is no  
>> requirement that
>> one charter item equals one document.
>>
>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>>> handoffs:
>>>
>>>
>>> RFC-5213 supports handoff between two interfaces. The ability to  
>>> move
>>> prefixes between interfaces. In other words address continuity is  
>>> assured
>>> with any IPv6 host on the planet and with absolutely no changes.  
>>> This
>>> meets
>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,  
>>> what is
>>> not assured is the aspect of session continuity. Which requires a  
>>> virtual
>>> interface implementation on the host, by binding the address/ 
>>> prefix to a
>>> virtual interface and by not exposing the physical interface or by  
>>> hiding
>>> the handoff events from the layer-3 stack.
>>>
>>> In essence, we need an informational specification which provides  
>>> some
>>> general guidance to how to leverage the feature support provided in
>>> RFC-5213,
>>> along the lines of:
>>>
>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>>
>> This is part of the discussion that we need to finish. But I plan  
>> to let the
>> rest of the stuff move forward even before we have done that.
>>
>>
>>> 7. Route Optimization for Proxy Mobile IPv6
>>>
>>> There were atleast 4 drafts in this area on Route Optimization.  
>>> Marco
>>> Liebsch
>>> analyzed this exensively:
>>>
>>>
>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>>>
>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00 
>>> .
>>> txt
>>
>> This is in the charter.
>>
>>> 8. Prefix Management in Proxy Mobile IPv6 support
>>>
>>> Proxy Mobile IPv6 allows the assignment of multiple home network  
>>> prefixes
>>> to a given mobile node's interface. It might be useful to specify  
>>> how the
>>> LMA manages this aspects. It can potentially use DHCP PD, Local  
>>> Pools or
>>> AAA to manage this aspect. Behcet has one draft on this.
>>
>> I'm not personally sold on this particular work. But again, this  
>> could be
>> something to consider.
>>
>>> 9. Partial Handoff Support
>>>
>>> We are missing some semantics in 5213 for moving a subset of the  
>>> prefixes
>>> between interfaces as part of the inter-tech handoff. This is about
>>> defining
>>> a new handoff value. This allows partial flow management, but  
>>> moving the
>>> flows associated to a prefix, as a whole group.
>>>
>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>>
>> A part of the topic we still need to discuss...
>>
>>> 10. CMIPv4/PMIP Interworking
>>>
>>> This is probably required to specify how an IPv4-only can move  
>>> between
>>> CMIP and PMIP environments.
>>>
>>>
>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>>> meghana-netlmm-pmipv6-mipv4-00.txt
>>
>> Client MIPv6 and Proxy MIPv6 interoperability is already in the  
>> NETLMM
>> charter, but this work is presumably about interaction with MIPv4.  
>> Might be
>> useful work, I wouldn't mind if this was done in NETEXT at some  
>> point. Is
>> this crucial to be in the first revision of the WG's charter?
>>
>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>>
>> Can you expand on this?
>>
>> Jari
>>
>> _______________________________________________
>> 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

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Wed, 8 Apr 2009 14:58:29 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >> - Inter-tech handovers are supported in PMIPv6
> >
> > I disagree with this statement. In case of inter-tech handover, the MAG in
> > the new access needs to send a PBU with the HI set to "2: Handoff between
> > two different interfaces of the mobile node". How does the new MAG know that
> > the attachment should be treated as a handover and not as a new session? In
> > the absence of any other indications, the MAG will treat this as a new
> > attachment, which results in multihoming with a different prefix and no
> > handover.
> >
>
> Can a deployment have terminals that only do single attach. Can
> that information be tied to the mobile's policy profile. Is it
> possible such information is available to the MAG ?
>
> Can AAA or other session manager have the awareness of the current
> existing session. Can the MAG leverage such information and
> derive if its a handover or a new attach ?
>
> So, its possible for the MAG to derive that information from the
> network, in many cases, including in 3GPP, as Vijay pointed out
> for single attach.
>

This is done by a special L2 message introduced for that - i.e. a change of the host (which is not visible to IETF as it is done at L2 and not L3, but still very real)

Gerardo

> Sri
>
>
>
>
>
>
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp
> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> >> Gundavelli
> >> Sent: 08. travanj 2009 21:51
> >> To: Basavaraj.Patil at nokia.com
> >> Cc: netext at mail.mobileip.jp
> >> Subject: Re: [Netext] next steps for netext
> >>
> >> I agree, this discussion is going on a different track. This
> >> wont converge. Secondly, we are bundling every thing together
> >> and making blanket statements. There are statements,
> >> multi-homing/handover does not work in PMIPv6, or that there
> >> needs to be an L2 interface ..
> >> there seems to be lot of assumptions around this, with out
> >> qualifying that, these statements are only creating
> >> confusion. Couple of points:
> >>
> >> - Multihoming is supported in PMIPv6
> >> - Inter-tech handovers are supported in PMIPv6
> >> - None of these features break or burn the host.
> >>
> >> 3GPP is not the only consumer for this work. Nothing stops
> >> some one from building an IPv6 enterprise mobility solution
> >> based on Proxy Mobile IPv6, as it is not a 3GPP specific
> >> protocol, but a protocol that can be deployed in enterprise
> >> wireless architectures. No one can tell me, we cant deploy
> >> this protocol for solving micro mobility problems in an
> >> integrated wired/wireless AP environments, targetted for an
> >> enterprise.
> >>
> >>> From the list of proposed items, I'd really hope to identify the work
> >> items that does not require extesive debates from the ones
> >> that requires fist-fighting.
> >>
> >> - Flow mobility has the scope from moving individual flows of
> >> interest with no relation to prefix, vs moving flows as a
> >> bundle associated to a prefix.
> >>
> >> - Host specific doc, from the point of view of leveraging
> >> what 5213 supports, vs, for supporting the new features.
> >>
> >> - Multi-homing, binding a single prefix to multiple
> >> interfaces, vs, an individual prefix to each interface.
> >>
> >>
> >> We have to qualify the discussions around this, just the use
> >> of the key words multi-homing, inter-tech handovers, flow
> >> mobility, and saying is not for PMIP6, is not accurate, does
> >> not justify the concern and does not help the discussions. We
> >> have to state which specific item has issues and under what
> >> scenario's.
> >>
> >> Thanks
> >> Sri
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>
> >>>
> >>> Hello,
> >>>
> >>> Lets try and keep this discussion focused on technical issues.
> >>> The current tone is not very encouraging in some instances.
> >>>
> >>> The current discussion is overly focused on what 3GPP is
> >> doing w.r.t
> >>> PMIP6 and future work items. 3GPP tends to use IETF protocols when
> >>> they see a good fit for their architecture and problem scope. We
> >>> cannot tell 3GPP to not develop a feature by themselves and
> >> instead rely on the IETF to deliver it.
> >>> They are free to do whatever they want.
> >>>
> >>> Within the IETF we can identify what problems or extensions
> >> to PMIP6
> >>> we want to work on and focus on these. If 3GPP finds the solution
> >>> applicable, they will use it. The IETF solution has to address the
> >>> generic problem and not tailored for 3GPP (which is what we
> >> seem to be doing now).
> >>> So maybe we can get down to discussing the problem and
> >> scenarios that
> >>> we would like to work on in Netext as a way of moving forward.
> >>>
> >>> In order to make progress, I would suggest that we focus on the
> >>> following 3
> >>> topics:
> >>> A. Multihoming
> >>> B. Flow mobility
> >>> C. Inter technology handovers
> >>>
> >>> If we can articulate the scenarios and associated problems
> >> with each
> >>> of the same, we can then get a better handle on what to take on in
> >>> Netext. And lets not start saying that we already have a
> >> solution in I-Dx or I-Dy.
> >>>
> >>> -Raj
> >>>
> >>>
> >>>
> >>>
> >>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >> <vijay at wichorus.com> wrote:
> >>>
> >>>> Hi George,
> >>>>
> >>>> George Tsirtsis wrote:
> >>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
> >>>>> <vijay at wichorus.com>
> >>>>> wrote:
> >>>>>> Hi Gerardo,
> >>>>>>
> >>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
> >>>>>>> solutions proposed on any I-D - there is a
> >> 3GPP-specific solution
> >>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>
> >>>>>> This is exactly what I would like to avoid. I would
> >> prefer using a
> >>>>>> solution developed in the IETF rather than something in 3GPP.
> >>>>>>
> >>>>>
> >>>>> GT> Why not? 3GPP and other SDOs have been creating technology for
> >>>>> almost as long as the IETF. Getting the IETF to do something only
> >>>>> makes sense if the given protocol has general
> >> applicability and does
> >>>>> not damage the Internet, which is why we are having this
> >> discussion.
> >>>>
> >>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >> very little
> >>>> modifications. They have added some vendor specific options for
> >>>> carrying some 3GPP specific information, but they are minor
> >>>> extensions. So when 3GPP is considering flow mobility for
> >> PMIPv6, it
> >>>> doesn't make sense for them to develop a solution on their
> >> own. It should be done in the IETF.
> >>>>
> >>>> And can we please stop the hyperbole about "damaging the
> >> Internet"?
> >>>> It is irritating and doesn't contribute to the discussion.
> >>>>
> >>>>> GT> In another e-mail where you are over-viewing a
> >> possible solution
> >>>>> to PMIP multihoming you talk about how the MN may use an L2 to
> >>>>> signal to indicate what flows need to go to a given MAG. I do not
> >>>>> see how the IETF can define a protocol that fully depends
> >> on such an
> >>>>> L2 signal. If such functionality is needed then the IETF
> >> must define
> >>>>> it at the IP layer to make sure that this works across ALL link
> >>>>> layers (which is the main reason the IETF and the Internet exist).
> >>>>
> >>>> Indicating the service identifier during an L2 attachment is
> >>>> supported in most accesses that PMIPv6 is being used for.
> >> So I don't
> >>>> see it as a big issue. You don't need a MN-MAG IP protocol for
> >>>> carrying the service identifier. That would be an overkill.
> >>>>
> >>>> Anyway, flow mobility can still be achieved even if the MN
> >> does not
> >>>> indicate the service identifier. Please see
> >>>>
> >> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>
> >>>>> GT> So, in my book you (pmip mhoming fans) have two
> >> hurdles to overcome:
> >>>>> 1) Admit to yourself that to do this in the IETF you need
> >> to define
> >>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>
> >>>> That is one option, but not required.
> >>>>
> >>>> Vijay
> >>>>
> >>>>> 2) Convince people that defining such a client based protocol in
> >>>>> addition to the existing standard (MIPv6) is warranted. In the
> >>>>> process, explain to people why you want to introduce FA
> >>>>> functionality to MIPv6, which is what MAGs become if you add an
> >>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>
> >>>>> George
> >>>>>
> >>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>>> 3GPP has not decided yet to do any normative work on any of the
> >>>>>>> solutions.
> >>>>>>>
> >>>>>>> Gerardo
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>> To: Giaretta, Gerardo
> >>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
> >>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>> list, sorry for that
> >>>>>>>>> :-)
> >>>>>>>>
> >>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>> function though.
> >>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>> basis for the
> >>>>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>>>> claim not backed
> >>>>>>>> by 3GPP.
> >>>>>>>>
> >>>>>>>> Hesham
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Gerardo
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Vijay
> >>>>>>>>>>
> >>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>> (discussed at the
> >>>>>>>> last
> >>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>> WiMAX with PMIPv6
> >>>>>>>>>> working.
> >>>>>>>>>>>
> >>>>>>>>>>>> Such
> >>>>>>>>>>>> large scale managed networks are the main consumers of
> >>>>>>> PMIP6 so we
> >>>>>>>>>> shouldn't
> >>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>
> >>>>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>>>> note that I am
> >>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>> homogeneous from a
> >>>>>>>>>> link layer point of view.
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>> Saying to use MIP for inter-access
> >> handovers/multihoming is
> >>>>>>>>>>>> not helping as they have
> >>>>>>> really set their mind
> >>>>>>>> on
> >>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>> going into the
> >>>>>>>>>> reasoning
> >>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>> defined in RFC 5213,
> >>>>>>>> has
> >>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>> better to fix those
> >>>>>>>> PMIP6
> >>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>> their own way of
> >>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> domagoj
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
> >>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> >>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
> >>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
> >>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
> >>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >> use cases.
> >>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>> host-based mobility
> >>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >> discussion
> >>>>>>>>>>>>> and this discussion on the list. The reason I don't know
> >>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>> saying:
> >>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >> and PMIP)
> >>>>>>>>>>>>> and here is why they don't work, therefore we need to do
> >>>>>>>>>>>>> something new.
> >>>>>>>>>>>>> That's what a PS should say. What's being said
> >> here is "PMIP
> >>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >> something
> >>>>>>>>>>>>> new", which is completely bogus because PMIP was not
> >>>>>>>>>>>>> designed to support those cases because we already have
> >>>>>>>>>>>>> something else for supporting those cases. Hence
> >> my reference to 4830...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm going to retire from the discussion till
> >> someone makes
> >>>>>>>>>>>>> the argument above. Because I feel that if there
> >> is no such
> >>>>>>>>>>>>> argument then the discussion is not a good use of time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Yes, additional software like the existing
> >> MIP. I don't
> >>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>> the motivation for creating something new. I've detailed
> >>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>>>> management
> >>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>> seems to be a
> >>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >> talking about
> >>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> distinguish modification for mobility management, which
> >>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>> as the use of
> >>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>> configure
> >>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>> the BoF, our
> >>>>>>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>> stick with MIP.
> >>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>> this is such a
> >>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>> room was in
> >>>>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => I think the question changed a few times :) The final
> >>>>>>>>>>>>> question
> >>>>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>> mentioned here
> >>>>>>>>>>>>>>> because they were one of the very few reasons for using
> >>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>> the host) and
> >>>>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
> >>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>> anyway. However if
> >>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>> not specify how
> >>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>> in all L2s,
> >>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
> >>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>> scope in IETF
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>> could specify
> >>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>> if that is the
> >>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => We can, but I don't know why we should do that when a
> >>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>> is inferior in
> >>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>> mostly flow
> >>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>
> >> _______________________________________________
> >> 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

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Wed, 8 Apr 2009 23:54:59 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

What you're discribing is a specific type of deployment where the MN is
allowed to attach only through a single access at a time. But this prevents
multihoming and is not a generic solution. We need a generic solution that
works with any type of deployment without artifical restrictions.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 08. travanj 2009 23:47
> To: Domagoj Premec
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: RE: [Netext] next steps for netext
> 
> Domagoj,
> 
> 
> On Wed, 8 Apr 2009, Domagoj Premec wrote:
> 
> > Sri,
> >
> >> - Inter-tech handovers are supported in PMIPv6
> >
> > I disagree with this statement. In case of inter-tech handover, the 
> > MAG in the new access needs to send a PBU with the HI set to "2: 
> > Handoff between two different interfaces of the mobile 
> node". How does 
> > the new MAG know that the attachment should be treated as a 
> handover 
> > and not as a new session? In the absence of any other 
> indications, the 
> > MAG will treat this as a new attachment, which results in 
> multihoming 
> > with a different prefix and no handover.
> >
> 
> Can a deployment have terminals that only do single attach. 
> Can that information be tied to the mobile's policy profile. 
> Is it possible such information is available to the MAG ?
> 
> Can AAA or other session manager have the awareness of the 
> current existing session. Can the MAG leverage such 
> information and derive if its a handover or a new attach ?
> 
> So, its possible for the MAG to derive that information from 
> the network, in many cases, including in 3GPP, as Vijay 
> pointed out for single attach.
> 
> Sri
> 
> 
> 
> 
> 
> 
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp 
> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
> >> Gundavelli
> >> Sent: 08. travanj 2009 21:51
> >> To: Basavaraj.Patil at nokia.com
> >> Cc: netext at mail.mobileip.jp
> >> Subject: Re: [Netext] next steps for netext
> >>
> >> I agree, this discussion is going on a different track. This wont 
> >> converge. Secondly, we are bundling every thing together 
> and making 
> >> blanket statements. There are statements, 
> multi-homing/handover does 
> >> not work in PMIPv6, or that there needs to be an L2 interface ..
> >> there seems to be lot of assumptions around this, with out 
> qualifying 
> >> that, these statements are only creating confusion. Couple 
> of points:
> >>
> >> - Multihoming is supported in PMIPv6
> >> - Inter-tech handovers are supported in PMIPv6
> >> - None of these features break or burn the host.
> >>
> >> 3GPP is not the only consumer for this work. Nothing stops 
> some one 
> >> from building an IPv6 enterprise mobility solution based on Proxy 
> >> Mobile IPv6, as it is not a 3GPP specific protocol, but a protocol 
> >> that can be deployed in enterprise wireless architectures. 
> No one can 
> >> tell me, we cant deploy this protocol for solving micro mobility 
> >> problems in an integrated wired/wireless AP environments, 
> targetted 
> >> for an enterprise.
> >>
> >>> From the list of proposed items, I'd really hope to identify the 
> >>> work
> >> items that does not require extesive debates from the ones that 
> >> requires fist-fighting.
> >>
> >> - Flow mobility has the scope from moving individual flows of 
> >> interest with no relation to prefix, vs moving flows as a bundle 
> >> associated to a prefix.
> >>
> >> - Host specific doc, from the point of view of leveraging 
> what 5213 
> >> supports, vs, for supporting the new features.
> >>
> >> - Multi-homing, binding a single prefix to multiple 
> interfaces, vs, 
> >> an individual prefix to each interface.
> >>
> >>
> >> We have to qualify the discussions around this, just the 
> use of the 
> >> key words multi-homing, inter-tech handovers, flow mobility, and 
> >> saying is not for PMIP6, is not accurate, does not justify the 
> >> concern and does not help the discussions. We have to state which 
> >> specific item has issues and under what scenario's.
> >>
> >> Thanks
> >> Sri
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> >>
> >>>
> >>> Hello,
> >>>
> >>> Lets try and keep this discussion focused on technical issues.
> >>> The current tone is not very encouraging in some instances.
> >>>
> >>> The current discussion is overly focused on what 3GPP is
> >> doing w.r.t
> >>> PMIP6 and future work items. 3GPP tends to use IETF 
> protocols when 
> >>> they see a good fit for their architecture and problem scope. We 
> >>> cannot tell 3GPP to not develop a feature by themselves and
> >> instead rely on the IETF to deliver it.
> >>> They are free to do whatever they want.
> >>>
> >>> Within the IETF we can identify what problems or extensions
> >> to PMIP6
> >>> we want to work on and focus on these. If 3GPP finds the solution 
> >>> applicable, they will use it. The IETF solution has to 
> address the 
> >>> generic problem and not tailored for 3GPP (which is what we
> >> seem to be doing now).
> >>> So maybe we can get down to discussing the problem and
> >> scenarios that
> >>> we would like to work on in Netext as a way of moving forward.
> >>>
> >>> In order to make progress, I would suggest that we focus on the 
> >>> following 3
> >>> topics:
> >>> A. Multihoming
> >>> B. Flow mobility
> >>> C. Inter technology handovers
> >>>
> >>> If we can articulate the scenarios and associated problems
> >> with each
> >>> of the same, we can then get a better handle on what to 
> take on in 
> >>> Netext. And lets not start saying that we already have a
> >> solution in I-Dx or I-Dy.
> >>>
> >>> -Raj
> >>>
> >>>
> >>>
> >>>
> >>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
> >> <vijay at wichorus.com> wrote:
> >>>
> >>>> Hi George,
> >>>>
> >>>> George Tsirtsis wrote:
> >>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli 
> >>>>> <vijay at wichorus.com>
> >>>>> wrote:
> >>>>>> Hi Gerardo,
> >>>>>>
> >>>>>>> 3GPP has a study item on this feature. There was no PMIPv6 
> >>>>>>> solutions proposed on any I-D - there is a
> >> 3GPP-specific solution
> >>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>>>
> >>>>>> This is exactly what I would like to avoid. I would
> >> prefer using a
> >>>>>> solution developed in the IETF rather than something in 3GPP.
> >>>>>>
> >>>>>
> >>>>> GT> Why not? 3GPP and other SDOs have been creating 
> technology for
> >>>>> almost as long as the IETF. Getting the IETF to do 
> something only 
> >>>>> makes sense if the given protocol has general
> >> applicability and does
> >>>>> not damage the Internet, which is why we are having this
> >> discussion.
> >>>>
> >>>> So far 3GPP has been mostly been using PMIPv6 with no or
> >> very little
> >>>> modifications. They have added some vendor specific options for 
> >>>> carrying some 3GPP specific information, but they are minor 
> >>>> extensions. So when 3GPP is considering flow mobility for
> >> PMIPv6, it
> >>>> doesn't make sense for them to develop a solution on their
> >> own. It should be done in the IETF.
> >>>>
> >>>> And can we please stop the hyperbole about "damaging the
> >> Internet"?
> >>>> It is irritating and doesn't contribute to the discussion.
> >>>>
> >>>>> GT> In another e-mail where you are over-viewing a
> >> possible solution
> >>>>> to PMIP multihoming you talk about how the MN may use an L2 to 
> >>>>> signal to indicate what flows need to go to a given 
> MAG. I do not 
> >>>>> see how the IETF can define a protocol that fully depends
> >> on such an
> >>>>> L2 signal. If such functionality is needed then the IETF
> >> must define
> >>>>> it at the IP layer to make sure that this works across ALL link 
> >>>>> layers (which is the main reason the IETF and the 
> Internet exist).
> >>>>
> >>>> Indicating the service identifier during an L2 attachment is 
> >>>> supported in most accesses that PMIPv6 is being used for.
> >> So I don't
> >>>> see it as a big issue. You don't need a MN-MAG IP protocol for 
> >>>> carrying the service identifier. That would be an overkill.
> >>>>
> >>>> Anyway, flow mobility can still be achieved even if the MN
> >> does not
> >>>> indicate the service identifier. Please see
> >>>>
> >> 
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>>>
> >>>>> GT> So, in my book you (pmip mhoming fans) have two
> >> hurdles to overcome:
> >>>>> 1) Admit to yourself that to do this in the IETF you need
> >> to define
> >>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>>>
> >>>> That is one option, but not required.
> >>>>
> >>>> Vijay
> >>>>
> >>>>> 2) Convince people that defining such a client based 
> protocol in 
> >>>>> addition to the existing standard (MIPv6) is warranted. In the 
> >>>>> process, explain to people why you want to introduce FA 
> >>>>> functionality to MIPv6, which is what MAGs become if you add an 
> >>>>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>>>
> >>>>> George
> >>>>>
> >>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>>> 3GPP has not decided yet to do any normative work on 
> any of the 
> >>>>>>> solutions.
> >>>>>>>
> >>>>>>> Gerardo
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>>>> To: Giaretta, Gerardo
> >>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; 
> netext at mail.mobileip.jp; 
> >>>>>>>> Basavaraj.Patil at nokia.com
> >>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>>>> list, sorry for that
> >>>>>>>>> :-)
> >>>>>>>>
> >>>>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>>>> function though.
> >>>>>>>> Based on your last email, I don't understand what is the
> >>>>>>> basis for the
> >>>>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>>>> claim not backed
> >>>>>>>> by 3GPP.
> >>>>>>>>
> >>>>>>>> Hesham
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Gerardo
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Vijay
> >>>>>>>>>>
> >>>>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>>>> (discussed at the
> >>>>>>>> last
> >>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>>>> WiMAX with PMIPv6
> >>>>>>>>>> working.
> >>>>>>>>>>>
> >>>>>>>>>>>> Such
> >>>>>>>>>>>> large scale managed networks are the main consumers of
> >>>>>>> PMIP6 so we
> >>>>>>>>>> shouldn't
> >>>>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>>>
> >>>>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>>>> note that I am
> >>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>>>> homogeneous from a
> >>>>>>>>>> link layer point of view.
> >>>>>>>>>>>
> >>>>>>>>>>> Gerardo
> >>>>>>>>>>>
> >>>>>>>>>>>> Saying to use MIP for inter-access
> >> handovers/multihoming is
> >>>>>>>>>>>> not helping as they have
> >>>>>>> really set their mind
> >>>>>>>> on
> >>>>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>>>> going into the
> >>>>>>>>>> reasoning
> >>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>>>> defined in RFC 5213,
> >>>>>>>> has
> >>>>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>>>> better to fix those
> >>>>>>>> PMIP6
> >>>>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>>>> their own way of
> >>>>>>>>>>>> dealing with this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> domagoj
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On 
> Behalf Of ext 
> >>>>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => We're discussing a problem statement for 
> the BoF, so
> >>>>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>>>> appropriate as a reference for why people 
> wanted PMIP in
> >>>>>>>>>>>>> the first place.
> >>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
> >>>>>>>>>>>>> network-based
> >>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
> >> use cases.
> >>>>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>>>> RFC4830 does. I don't
> >>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>>>> host-based mobility
> >>>>>>>>>>>>>> protocol again.
> >>>>>>>>>>>>> => I don't know what the goal is based on the BoF
> >> discussion
> >>>>>>>>>>>>> and this discussion on the list. The reason I 
> don't know 
> >>>>>>>>>>>>> that is that no one is
> >>>>>>>>>>>>> saying:
> >>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
> >> and PMIP)
> >>>>>>>>>>>>> and here is why they don't work, therefore we 
> need to do 
> >>>>>>>>>>>>> something new.
> >>>>>>>>>>>>> That's what a PS should say. What's being said
> >> here is "PMIP
> >>>>>>>>>>>>> doesn't support advanced cases therefore we need
> >> something
> >>>>>>>>>>>>> new", which is completely bogus because PMIP was not 
> >>>>>>>>>>>>> designed to support those cases because we already have 
> >>>>>>>>>>>>> something else for supporting those cases. Hence
> >> my reference to 4830...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm going to retire from the discussion till
> >> someone makes
> >>>>>>>>>>>>> the argument above. Because I feel that if there
> >> is no such
> >>>>>>>>>>>>> argument then the discussion is not a good use of time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Yes, additional software like the existing
> >> MIP. I don't
> >>>>>>>>>>>>> understand
> >>>>>>>>>>>>>>> the motivation for creating something new. 
> I've detailed
> >>>>>>>>>>>>> this in my
> >>>>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>>>> management
> >>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>>>> seems to be a
> >>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>>>> => You're missing the point. Why isn't anybody
> >> talking about
> >>>>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> distinguish modification for mobility 
> management, which
> >>>>>>>>>>>>> is not what
> >>>>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>>>> as the use of
> >>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>>>> configure
> >>>>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> marco
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>>>>>>>>>> unmodified
> >>>>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>>>> the BoF, our
> >>>>>>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>>>>>>>>>> the host
> >>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>>>> stick with MIP.
> >>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>>>> this is such a
> >>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>>>> room was in
> >>>>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>>>> raised for the
> >>>>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>>>> and intertech
> >>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => I think the question changed a few times 
> :) The final
> >>>>>>>>>>>>> question
> >>>>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>>>> with this or
> >>>>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>>>> mentioned here
> >>>>>>>>>>>>>>> because they were one of the very few reasons 
> for using
> >>>>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>>>> the host) and
> >>>>>>>>>>>>>>> signalling from the MN. You can see them in 
> section 4 of
> >>>>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>>>> relying on a
> >>>>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>>>> anyway. However if
> >>>>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>>>> not specify how
> >>>>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Because we already have a solution that works
> >>>>>>> in all L2s,
> >>>>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>>>> confusing host
> >>>>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>>>> is not done
> >>>>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>>>>>>>>>> or config?
> >>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>>>>>>>>>> in the IETF
> >>>>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>>>> changes to SW etc.
> >>>>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. 
> These were the
> >>>>>>>>>>>>> reasons for
> >>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>>>> ways, or can
> >>>>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>>>> scope in IETF
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>>>> could specify
> >>>>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>>>> if that is the
> >>>>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> => We can, but I don't know why we should do 
> that when a
> >>>>>>>>>>>>> solution
> >>>>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>>>> is inferior in
> >>>>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>>>> comments.
> >>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>>>> basic handoff
> >>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>>>> mostly flow
> >>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >
> >
> 

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Wed, 8 Apr 2009 17:52:44 -0400
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj,

Thanks for this. I agree on what you said in your mail.
However, I want to ask one more clarification.

I don't want to go to MIP6 vs PMIP6 here, but some of extensions  
(multihoming, flow mobility,
LMA redirection aka HAswithc?) are already covered by MIP6 in MEXT.
When we need the similar features to PMIP,
will NetEXT solution inherit MIP6 and MIP6-based-extension as RFC5213  
did?
One of goal of RFC5213 was to inherit MIP6 spec as much as possible.

PMIP specific issues can be solved anyway, but some of common issues  
can be
solved with the similar extensions to MIP6 or with another extensions  
to MIP6 extension.
After PMIP6 deployment, we will have more common issues between MIP6  
and PMIP6.

It makes sense to take the same approach to solve the same goal at  
MIP6 and PMIP6.

regards,
ryuji

On 2009/04/08, at 16:29, <Basavaraj.Patil at nokia.com> <Basavaraj.Patil at nokia.com 
 > wrote:

>
> Hello,
>
> There is an issue in the current debate that we should put to rest.
> Netext proposes to extend PMIP6 to support multihoming, flow mobility
> and inter-technology handovers (in addition to others over which  
> there is
> an agreement on).
>
> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
> these capabilities currently. I dont think there is any debate about
> that.
> However there is an interested group of people within the IETF
> community who would like to extend PMIP6 to support these features as
> well.
> It is not uncommon in the IETF to have multiple competing protocols
> provide similar functionality. The industry will ultimately choose an
> appropriate solution depending on the needs. So I dont think we can
> just quash the idea of working on these extensions simply because we
> already have a protocol that does it.
> It is also noted that one of the primary reasons for developing PMIP6
> was to provide mobility without host involvement. The term
> "host-changes" in the context of the current discussion are still to a
> large extent based on the PMIP6 intent. As long as we are not defining
> a new protocol on the host, we can consider the host as being
> unmodified (from this disucssions PoV).
>
> In summary I would say that this is not a discussion about whether
> host based Mobile IP (MIP6) is the appropriate protocol for providing
> multihoming, Flow mobility and, inter-tech HOs but rather about what
> can be done to provide similar capabilities to PMIP6 without (grossly)
> changing the basic protocol principles.
>
> -Raj
>
> P.S: I recognize that some would say that inter-tech HOs and
> multihoming are already features supported by PMIP6. In the current
> context of Netext, what is being proposed is basically enhancements to
> PMIP6 that address scenarios not currently in the base spec.
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 14:46:33 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Domagoj,

On Wed, 8 Apr 2009, Domagoj Premec wrote:

> Sri,
>
>> - Inter-tech handovers are supported in PMIPv6
>
> I disagree with this statement. In case of inter-tech handover, the MAG in
> the new access needs to send a PBU with the HI set to "2: Handoff between
> two different interfaces of the mobile node". How does the new MAG know that
> the attachment should be treated as a handover and not as a new session? In
> the absence of any other indications, the MAG will treat this as a new
> attachment, which results in multihoming with a different prefix and no
> handover.
>

Can a deployment have terminals that only do single attach. Can
that information be tied to the mobile's policy profile. Is it
possible such information is available to the MAG ?

Can AAA or other session manager have the awareness of the current
existing session. Can the MAG leverage such information and
derive if its a handover or a new attach ?

So, its possible for the MAG to derive that information from the
network, in many cases, including in 3GPP, as Vijay pointed out
for single attach.

Sri

> domagoj
>
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>> Gundavelli
>> Sent: 08. travanj 2009 21:51
>> To: Basavaraj.Patil at nokia.com
>> Cc: netext at mail.mobileip.jp
>> Subject: Re: [Netext] next steps for netext
>>
>> I agree, this discussion is going on a different track. This
>> wont converge. Secondly, we are bundling every thing together
>> and making blanket statements. There are statements,
>> multi-homing/handover does not work in PMIPv6, or that there
>> needs to be an L2 interface ..
>> there seems to be lot of assumptions around this, with out
>> qualifying that, these statements are only creating
>> confusion. Couple of points:
>>
>> - Multihoming is supported in PMIPv6
>> - Inter-tech handovers are supported in PMIPv6
>> - None of these features break or burn the host.
>>
>> 3GPP is not the only consumer for this work. Nothing stops
>> some one from building an IPv6 enterprise mobility solution
>> based on Proxy Mobile IPv6, as it is not a 3GPP specific
>> protocol, but a protocol that can be deployed in enterprise
>> wireless architectures. No one can tell me, we cant deploy
>> this protocol for solving micro mobility problems in an
>> integrated wired/wireless AP environments, targetted for an
>> enterprise.
>>
>>> From the list of proposed items, I'd really hope to identify the work
>> items that does not require extesive debates from the ones
>> that requires fist-fighting.
>>
>> - Flow mobility has the scope from moving individual flows of
>> interest with no relation to prefix, vs moving flows as a
>> bundle associated to a prefix.
>>
>> - Host specific doc, from the point of view of leveraging
>> what 5213 supports, vs, for supporting the new features.
>>
>> - Multi-homing, binding a single prefix to multiple
>> interfaces, vs, an individual prefix to each interface.
>>
>>
>> We have to qualify the discussions around this, just the use
>> of the key words multi-homing, inter-tech handovers, flow
>> mobility, and saying is not for PMIP6, is not accurate, does
>> not justify the concern and does not help the discussions. We
>> have to state which specific item has issues and under what
>> scenario's.
>>
>> Thanks
>> Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>
>>>
>>> Hello,
>>>
>>> Lets try and keep this discussion focused on technical issues.
>>> The current tone is not very encouraging in some instances.
>>>
>>> The current discussion is overly focused on what 3GPP is
>> doing w.r.t
>>> PMIP6 and future work items. 3GPP tends to use IETF protocols when
>>> they see a good fit for their architecture and problem scope. We
>>> cannot tell 3GPP to not develop a feature by themselves and
>> instead rely on the IETF to deliver it.
>>> They are free to do whatever they want.
>>>
>>> Within the IETF we can identify what problems or extensions
>> to PMIP6
>>> we want to work on and focus on these. If 3GPP finds the solution
>>> applicable, they will use it. The IETF solution has to address the
>>> generic problem and not tailored for 3GPP (which is what we
>> seem to be doing now).
>>> So maybe we can get down to discussing the problem and
>> scenarios that
>>> we would like to work on in Netext as a way of moving forward.
>>>
>>> In order to make progress, I would suggest that we focus on the
>>> following 3
>>> topics:
>>> A. Multihoming
>>> B. Flow mobility
>>> C. Inter technology handovers
>>>
>>> If we can articulate the scenarios and associated problems
>> with each
>>> of the same, we can then get a better handle on what to take on in
>>> Netext. And lets not start saying that we already have a
>> solution in I-Dx or I-Dy.
>>>
>>> -Raj
>>>
>>>
>>>
>>>
>>> On 4/8/09 12:33 PM, "ext Vijay Devarapalli"
>> <vijay at wichorus.com> wrote:
>>>
>>>> Hi George,
>>>>
>>>> George Tsirtsis wrote:
>>>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli
>>>>> <vijay at wichorus.com>
>>>>> wrote:
>>>>>> Hi Gerardo,
>>>>>>
>>>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>>>> solutions proposed on any I-D - there is a
>> 3GPP-specific solution
>>>>>>> proposed for PMIPv6 (based on the policy infrastructure).
>>>>>>
>>>>>> This is exactly what I would like to avoid. I would
>> prefer using a
>>>>>> solution developed in the IETF rather than something in 3GPP.
>>>>>>
>>>>>
>>>>> GT> Why not? 3GPP and other SDOs have been creating technology for
>>>>> almost as long as the IETF. Getting the IETF to do something only
>>>>> makes sense if the given protocol has general
>> applicability and does
>>>>> not damage the Internet, which is why we are having this
>> discussion.
>>>>
>>>> So far 3GPP has been mostly been using PMIPv6 with no or
>> very little
>>>> modifications. They have added some vendor specific options for
>>>> carrying some 3GPP specific information, but they are minor
>>>> extensions. So when 3GPP is considering flow mobility for
>> PMIPv6, it
>>>> doesn't make sense for them to develop a solution on their
>> own. It should be done in the IETF.
>>>>
>>>> And can we please stop the hyperbole about "damaging the
>> Internet"?
>>>> It is irritating and doesn't contribute to the discussion.
>>>>
>>>>> GT> In another e-mail where you are over-viewing a
>> possible solution
>>>>> to PMIP multihoming you talk about how the MN may use an L2 to
>>>>> signal to indicate what flows need to go to a given MAG. I do not
>>>>> see how the IETF can define a protocol that fully depends
>> on such an
>>>>> L2 signal. If such functionality is needed then the IETF
>> must define
>>>>> it at the IP layer to make sure that this works across ALL link
>>>>> layers (which is the main reason the IETF and the Internet exist).
>>>>
>>>> Indicating the service identifier during an L2 attachment is
>>>> supported in most accesses that PMIPv6 is being used for.
>> So I don't
>>>> see it as a big issue. You don't need a MN-MAG IP protocol for
>>>> carrying the service identifier. That would be an overkill.
>>>>
>>>> Anyway, flow mobility can still be achieved even if the MN
>> does not
>>>> indicate the service identifier. Please see
>>>>
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>>>
>>>>> GT> So, in my book you (pmip mhoming fans) have two
>> hurdles to overcome:
>>>>> 1) Admit to yourself that to do this in the IETF you need
>> to define
>>>>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>>>
>>>> That is one option, but not required.
>>>>
>>>> Vijay
>>>>
>>>>> 2) Convince people that defining such a client based protocol in
>>>>> addition to the existing standard (MIPv6) is warranted. In the
>>>>> process, explain to people why you want to introduce FA
>>>>> functionality to MIPv6, which is what MAGs become if you add an
>>>>> MN-MAG leg to PMIP's MAG-HA leg.
>>>>>
>>>>> George
>>>>>
>>>>>
>>>>>> Vijay
>>>>>>
>>>>>>> 3GPP has not decided yet to do any normative work on any of the
>>>>>>> solutions.
>>>>>>>
>>>>>>> Gerardo
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>>>> To: Giaretta, Gerardo
>>>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>>>>>>>> Basavaraj.Patil at nokia.com
>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>>>> list, sorry for that
>>>>>>>>> :-)
>>>>>>>>
>>>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>>>> function though.
>>>>>>>> Based on your last email, I don't understand what is the
>>>>>>> basis for the
>>>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>>>> claim not backed
>>>>>>>> by 3GPP.
>>>>>>>>
>>>>>>>> Hesham
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gerardo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Vijay
>>>>>>>>>>
>>>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>>>> (discussed at the
>>>>>>>> last
>>>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>>>> WiMAX with PMIPv6
>>>>>>>>>> working.
>>>>>>>>>>>
>>>>>>>>>>>> Such
>>>>>>>>>>>> large scale managed networks are the main consumers of
>>>>>>> PMIP6 so we
>>>>>>>>>> shouldn't
>>>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>>>
>>>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>>>> note that I am
>>>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>>>> homogeneous from a
>>>>>>>>>> link layer point of view.
>>>>>>>>>>>
>>>>>>>>>>> Gerardo
>>>>>>>>>>>
>>>>>>>>>>>> Saying to use MIP for inter-access
>> handovers/multihoming is
>>>>>>>>>>>> not helping as they have
>>>>>>> really set their mind
>>>>>>>> on
>>>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>>>> going into the
>>>>>>>>>> reasoning
>>>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>>>> defined in RFC 5213,
>>>>>>>> has
>>>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>>>> better to fix those
>>>>>>>> PMIP6
>>>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>>>> their own way of
>>>>>>>>>>>> dealing with this.
>>>>>>>>>>>>
>>>>>>>>>>>> domagoj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>>>>>>>>> the first place.
>>>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>>>> network-based
>>>>>>>>>>>>>> mobility management (PMIPv6) to support advanced
>> use cases.
>>>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>>>> RFC4830 does. I don't
>>>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>>>> host-based mobility
>>>>>>>>>>>>>> protocol again.
>>>>>>>>>>>>> => I don't know what the goal is based on the BoF
>> discussion
>>>>>>>>>>>>> and this discussion on the list. The reason I don't know
>>>>>>>>>>>>> that is that no one is
>>>>>>>>>>>>> saying:
>>>>>>>>>>>>> Here is the state of the art (including BOTH MIP
>> and PMIP)
>>>>>>>>>>>>> and here is why they don't work, therefore we need to do
>>>>>>>>>>>>> something new.
>>>>>>>>>>>>> That's what a PS should say. What's being said
>> here is "PMIP
>>>>>>>>>>>>> doesn't support advanced cases therefore we need
>> something
>>>>>>>>>>>>> new", which is completely bogus because PMIP was not
>>>>>>>>>>>>> designed to support those cases because we already have
>>>>>>>>>>>>> something else for supporting those cases. Hence
>> my reference to 4830...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm going to retire from the discussion till
>> someone makes
>>>>>>>>>>>>> the argument above. Because I feel that if there
>> is no such
>>>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => Yes, additional software like the existing
>> MIP. I don't
>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>> the motivation for creating something new. I've detailed
>>>>>>>>>>>>> this in my
>>>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>>>> management
>>>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>>>> seems to be a
>>>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>>>> => You're missing the point. Why isn't anybody
>> talking about
>>>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> distinguish modification for mobility management, which
>>>>>>>>>>>>> is not what
>>>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>>>> as the use of
>>>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>>>> configure
>>>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> marco
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>>>> unmodified
>>>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>>>> the BoF, our
>>>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>>>> the host
>>>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>>>> stick with MIP.
>>>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>>>> this is such a
>>>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>>>> room was in
>>>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>>>> raised for the
>>>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>>>> and intertech
>>>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => I think the question changed a few times :) The final
>>>>>>>>>>>>> question
>>>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>>>> with this or
>>>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>>>> mentioned here
>>>>>>>>>>>>>>> because they were one of the very few reasons for using
>>>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>>>> the host) and
>>>>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>>>> relying on a
>>>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>>>> anyway. However if
>>>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>>>> not specify how
>>>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => Because we already have a solution that works
>>>>>>> in all L2s,
>>>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>>>> confusing host
>>>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>>>> is not done
>>>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>>>> or config?
>>>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>>>> in the IETF
>>>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>>>> changes to SW etc.
>>>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>>>>>>> reasons for
>>>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>>>> ways, or can
>>>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>>>> scope in IETF
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>>>> could specify
>>>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>>>> if that is the
>>>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>>>> is inferior in
>>>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>>>> basic handoff
>>>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>>>> mostly flow
>>>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Wed, 8 Apr 2009 23:39:29 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

> - Inter-tech handovers are supported in PMIPv6

I disagree with this statement. In case of inter-tech handover, the MAG in
the new access needs to send a PBU with the HI set to "2: Handoff between
two different interfaces of the mobile node". How does the new MAG know that
the attachment should be treated as a handover and not as a new session? In
the absence of any other indications, the MAG will treat this as a new
attachment, which results in multihoming with a different prefix and no
handover.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
> Gundavelli
> Sent: 08. travanj 2009 21:51
> To: Basavaraj.Patil at nokia.com
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
> I agree, this discussion is going on a different track. This 
> wont converge. Secondly, we are bundling every thing together 
> and making blanket statements. There are statements, 
> multi-homing/handover does not work in PMIPv6, or that there 
> needs to be an L2 interface ..
> there seems to be lot of assumptions around this, with out 
> qualifying that, these statements are only creating 
> confusion. Couple of points:
> 
> - Multihoming is supported in PMIPv6
> - Inter-tech handovers are supported in PMIPv6
> - None of these features break or burn the host.
> 
> 3GPP is not the only consumer for this work. Nothing stops 
> some one from building an IPv6 enterprise mobility solution 
> based on Proxy Mobile IPv6, as it is not a 3GPP specific 
> protocol, but a protocol that can be deployed in enterprise 
> wireless architectures. No one can tell me, we cant deploy 
> this protocol for solving micro mobility problems in an 
> integrated wired/wireless AP environments, targetted for an 
> enterprise.
> 
> >From the list of proposed items, I'd really hope to identify the work
> items that does not require extesive debates from the ones 
> that requires fist-fighting.
> 
> - Flow mobility has the scope from moving individual flows of 
> interest with no relation to prefix, vs moving flows as a 
> bundle associated to a prefix.
> 
> - Host specific doc, from the point of view of leveraging 
> what 5213 supports, vs, for supporting the new features.
> 
> - Multi-homing, binding a single prefix to multiple 
> interfaces, vs, an individual prefix to each interface.
> 
> 
> We have to qualify the discussions around this, just the use 
> of the key words multi-homing, inter-tech handovers, flow 
> mobility, and saying is not for PMIP6, is not accurate, does 
> not justify the concern and does not help the discussions. We 
> have to state which specific item has issues and under what 
> scenario's.
> 
> Thanks
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> 
> >
> > Hello,
> >
> > Lets try and keep this discussion focused on technical issues.
> > The current tone is not very encouraging in some instances.
> >
> > The current discussion is overly focused on what 3GPP is 
> doing w.r.t 
> > PMIP6 and future work items. 3GPP tends to use IETF protocols when 
> > they see a good fit for their architecture and problem scope. We 
> > cannot tell 3GPP to not develop a feature by themselves and 
> instead rely on the IETF to deliver it.
> > They are free to do whatever they want.
> >
> > Within the IETF we can identify what problems or extensions 
> to PMIP6 
> > we want to work on and focus on these. If 3GPP finds the solution 
> > applicable, they will use it. The IETF solution has to address the 
> > generic problem and not tailored for 3GPP (which is what we 
> seem to be doing now).
> > So maybe we can get down to discussing the problem and 
> scenarios that 
> > we would like to work on in Netext as a way of moving forward.
> >
> > In order to make progress, I would suggest that we focus on the 
> > following 3
> > topics:
> > A. Multihoming
> > B. Flow mobility
> > C. Inter technology handovers
> >
> > If we can articulate the scenarios and associated problems 
> with each 
> > of the same, we can then get a better handle on what to take on in 
> > Netext. And lets not start saying that we already have a 
> solution in I-Dx or I-Dy.
> >
> > -Raj
> >
> >
> >
> >
> > On 4/8/09 12:33 PM, "ext Vijay Devarapalli" 
> <vijay at wichorus.com> wrote:
> >
> >> Hi George,
> >>
> >> George Tsirtsis wrote:
> >>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli 
> >>> <vijay at wichorus.com>
> >>> wrote:
> >>>> Hi Gerardo,
> >>>>
> >>>>> 3GPP has a study item on this feature. There was no PMIPv6 
> >>>>> solutions proposed on any I-D - there is a 
> 3GPP-specific solution 
> >>>>> proposed for PMIPv6 (based on the policy infrastructure).
> >>>>
> >>>> This is exactly what I would like to avoid. I would 
> prefer using a 
> >>>> solution developed in the IETF rather than something in 3GPP.
> >>>>
> >>>
> >>> GT> Why not? 3GPP and other SDOs have been creating technology for
> >>> almost as long as the IETF. Getting the IETF to do something only 
> >>> makes sense if the given protocol has general 
> applicability and does 
> >>> not damage the Internet, which is why we are having this 
> discussion.
> >>
> >> So far 3GPP has been mostly been using PMIPv6 with no or 
> very little 
> >> modifications. They have added some vendor specific options for 
> >> carrying some 3GPP specific information, but they are minor 
> >> extensions. So when 3GPP is considering flow mobility for 
> PMIPv6, it 
> >> doesn't make sense for them to develop a solution on their 
> own. It should be done in the IETF.
> >>
> >> And can we please stop the hyperbole about "damaging the 
> Internet"? 
> >> It is irritating and doesn't contribute to the discussion.
> >>
> >>> GT> In another e-mail where you are over-viewing a 
> possible solution
> >>> to PMIP multihoming you talk about how the MN may use an L2 to 
> >>> signal to indicate what flows need to go to a given MAG. I do not 
> >>> see how the IETF can define a protocol that fully depends 
> on such an 
> >>> L2 signal. If such functionality is needed then the IETF 
> must define 
> >>> it at the IP layer to make sure that this works across ALL link 
> >>> layers (which is the main reason the IETF and the Internet exist).
> >>
> >> Indicating the service identifier during an L2 attachment is 
> >> supported in most accesses that PMIPv6 is being used for. 
> So I don't 
> >> see it as a big issue. You don't need a MN-MAG IP protocol for 
> >> carrying the service identifier. That would be an overkill.
> >>
> >> Anyway, flow mobility can still be achieved even if the MN 
> does not 
> >> indicate the service identifier. Please see 
> >> 
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
> >>
> >>> GT> So, in my book you (pmip mhoming fans) have two 
> hurdles to overcome:
> >>> 1) Admit to yourself that to do this in the IETF you need 
> to define 
> >>> an MN-MAG protocol at the IP layer (e.g., see Conny's draft)
> >>
> >> That is one option, but not required.
> >>
> >> Vijay
> >>
> >>> 2) Convince people that defining such a client based protocol in 
> >>> addition to the existing standard (MIPv6) is warranted. In the 
> >>> process, explain to people why you want to introduce FA 
> >>> functionality to MIPv6, which is what MAGs become if you add an 
> >>> MN-MAG leg to PMIP's MAG-HA leg.
> >>>
> >>> George
> >>>
> >>>
> >>>> Vijay
> >>>>
> >>>>> 3GPP has not decided yet to do any normative work on any of the 
> >>>>> solutions.
> >>>>>
> >>>>> Gerardo
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
> >>>>>> To: Giaretta, Gerardo
> >>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp; 
> >>>>>> Basavaraj.Patil at nokia.com
> >>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I will now stop discussing 3GPP specific issues in this
> >>>>> list, sorry for that
> >>>>>>> :-)
> >>>>>>
> >>>>>> => Please continue to tell us whether 3GPP needs certain
> >>>>> function though.
> >>>>>> Based on your last email, I don't understand what is the
> >>>>> basis for the
> >>>>>> claims of 3GPP needing this function. Seems like a baseless
> >>>>> claim not backed
> >>>>>> by 3GPP.
> >>>>>>
> >>>>>> Hesham
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Gerardo
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Vijay
> >>>>>>>>
> >>>>>>>>> On the WiMAX side, I know there are still open issues
> >>>>> (discussed at the
> >>>>>> last
> >>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
> >>>>> WiMAX with PMIPv6
> >>>>>>>> working.
> >>>>>>>>>
> >>>>>>>>>> Such
> >>>>>>>>>> large scale managed networks are the main consumers of
> >>>>> PMIP6 so we
> >>>>>>>> shouldn't
> >>>>>>>>>> be ignoring what they're doing.
> >>>>>>>>>
> >>>>>>>>> This is mainly true for intra-technology mobility - and
> >>>>> note that I am
> >>>>>>>> considering LTE-eHRPD intra-technology here as they are
> >>>>> homogeneous from a
> >>>>>>>> link layer point of view.
> >>>>>>>>>
> >>>>>>>>> Gerardo
> >>>>>>>>>
> >>>>>>>>>> Saying to use MIP for inter-access 
> handovers/multihoming is 
> >>>>>>>>>> not helping as they have
> >>>>> really set their mind
> >>>>>> on
> >>>>>>>>>> using PMIP6 and they're already doing this. Without
> >>>>> going into the
> >>>>>>>> reasoning
> >>>>>>>>>> behind such a decision, the fact is that PMIP6, as
> >>>>> defined in RFC 5213,
> >>>>>> has
> >>>>>>>>>> issues with inter-access handovers. I think it is
> >>>>> better to fix those
> >>>>>> PMIP6
> >>>>>>>>>> issues in the IETF then to let each SDO come up with
> >>>>> their own way of
> >>>>>>>>>> dealing with this.
> >>>>>>>>>>
> >>>>>>>>>> domagoj
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: netext-bounces at mail.mobileip.jp 
> >>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> >>>>>>>>>>> Hesham Soliman
> >>>>>>>>>>> Sent: 07. travanj 2009 11:14
> >>>>>>>>>>> To: Marco Liebsch
> >>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>>>>>>>> Subject: Re: [Netext] next steps for netext
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
> >>>>>>>>>>> 4830 is quite
> >>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
> >>>>>>>>>>> the first place.
> >>>>>>>>>>>> Yes, a problem statement about an existing solution for
> >>>>>>>>>>> network-based
> >>>>>>>>>>>> mobility management (PMIPv6) to support advanced 
> use cases.
> >>>>>>>>>>> => Where is that PS?
> >>>>>>>>>>>
> >>>>>>>>>>>   Not the problem of
> >>>>>>>>>>>> existing solutions for localized mobility, as
> >>>>> RFC4830 does. I don't
> >>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
> >>>>> host-based mobility
> >>>>>>>>>>>> protocol again.
> >>>>>>>>>>> => I don't know what the goal is based on the BoF 
> discussion 
> >>>>>>>>>>> and this discussion on the list. The reason I don't know 
> >>>>>>>>>>> that is that no one is
> >>>>>>>>>>> saying:
> >>>>>>>>>>> Here is the state of the art (including BOTH MIP 
> and PMIP) 
> >>>>>>>>>>> and here is why they don't work, therefore we need to do 
> >>>>>>>>>>> something new.
> >>>>>>>>>>> That's what a PS should say. What's being said 
> here is "PMIP 
> >>>>>>>>>>> doesn't support advanced cases therefore we need 
> something 
> >>>>>>>>>>> new", which is completely bogus because PMIP was not 
> >>>>>>>>>>> designed to support those cases because we already have 
> >>>>>>>>>>> something else for supporting those cases. Hence 
> my reference to 4830...
> >>>>>>>>>>>
> >>>>>>>>>>> I'm going to retire from the discussion till 
> someone makes 
> >>>>>>>>>>> the argument above. Because I feel that if there 
> is no such 
> >>>>>>>>>>> argument then the discussion is not a good use of time.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> => Yes, additional software like the existing 
> MIP. I don't
> >>>>>>>>>>> understand
> >>>>>>>>>>>>> the motivation for creating something new. I've detailed
> >>>>>>>>>>> this in my
> >>>>>>>>>>>>> previous emails and the points remain unanswered.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Nobody talks about adding a piece of client mobility
> >>>>> management
> >>>>>>>>>>>> software, such as a MIP client, to the mobile. That
> >>>>> seems to be a
> >>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
> >>>>>>>>>>> => You're missing the point. Why isn't anybody 
> talking about 
> >>>>>>>>>>> MIP??? That's what a PS should say.
> >>>>>>>>>>>
> >>>>>>>>>>> Hesham
> >>>>>>>>>>>
> >>>>>>>>>>>> marco
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> distinguish modification for mobility management, which
> >>>>>>>>>>> is not what
> >>>>>>>>>>>>> we want to do, and enabling local functions, such
> >>>>> as the use of
> >>>>>>>>>>>>> multiple interfaces, where you have to add routes,
> >>>>> configure
> >>>>>>>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> marco
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>>>>>>>> unmodified
> >>>>>>>>>>>>> based on whether the modification affects IETF
> >>>>>>>>>>> protocols or not.
> >>>>>>>>>>>>> That's fine, but for those that did not attend
> >>>>> the BoF, our
> >>>>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>>>>>>>> the host
> >>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
> >>>>> stick with MIP.
> >>>>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>>>>>>>> is not a
> >>>>>>>>>>>>> good way to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We can discuss what implies host changes and why
> >>>>> this is such a
> >>>>>>>>>>>>> big deal anyway. But I don't think that half the
> >>>>> room was in
> >>>>>>>>>>>>> agreement as such. At least from the count of hands
> >>>>>>>>>>> raised for the
> >>>>>>>>>>>>> question about whether we should work on multihoming
> >>>>>>>>>>> and intertech
> >>>>>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> => I think the question changed a few times :) The final
> >>>>>>>>>>> question
> >>>>>>>>>>>>> (which was specific to whether people wanted to work
> >>>>>>>>>>> with this or
> >>>>>>>>>>>>> not) showed a split room.
> >>>>>>>>>>>>> The host changes are not a big deal but they are
> >>>>> mentioned here
> >>>>>>>>>>>>> because they were one of the very few reasons for using
> >>>>>>>>>>> NETLMM in
> >>>>>>>>>>>>> the first place: Host changes (adding new SW to
> >>>>> the host) and
> >>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
> >>>>>>>>>>> RFC 4830.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>>>>>>>> relying on a
> >>>>>>>>>>>>> solution that will:
> >>>>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We have no ability to specify changes to L2
> >>>>> anyway. However if
> >>>>>>>>>>>>> some L2s do have such capability, why would we
> >>>>> not specify how
> >>>>>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> => Because we already have a solution that works
> >>>>> in all L2s,
> >>>>>>>>>>>>> doesn't require
> >>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>>>>>>>> confusing host
> >>>>>>>>>>>>> config solutions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Require additional SW and config on the host which
> >>>>>>>>>>> is not done
> >>>>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>>>>>>>> or config?
> >>>>>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>>>>>>>> in the IETF
> >>>>>>>>>>>>> requires configurations, protocol changes,
> >>>>> changes to SW etc.
> >>>>>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
> >>>>>>>>>>> reasons for
> >>>>>>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>>>>>>>> ways, or can
> >>>>>>>>>>>>> we? :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Require L2 signalling which is out of our
> >>>>> scope in IETF
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
> >>>>> could specify
> >>>>>>>>>>>>> (informatively)
> >>>>>>>>>>>>> what L2 capabilities would enable these features
> >>>>> if that is the
> >>>>>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> => We can, but I don't know why we should do that when a
> >>>>>>>>>>> solution
> >>>>>>>>>>>>> already exists. Especially when the alternative
> >>>>> is inferior in
> >>>>>>>>>>>>> terms of its applicability.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Raj
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is why I think we should stick with the charter
> >>>>>>>>>>> that Jari sent.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hesham
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I share the same view with respect to all your other
> >>>>>>>>>>> comments.
> >>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>>>>>>>> basic handoff
> >>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
> >>>>> mostly flow
> >>>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>>>>>>>> today in 5213.
> >>>>>>>>>>>>> Sri
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Wed, 8 Apr 2009 16:49:48 -0400
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I might also add that the intent is not to bring feature parity between
MIP6 and PMIP6, but to consider work on features which are of interest
to PMIP6. Again, it is recognized that certain features are supported by
MIP6 already, but scenarios where PMIP6 is the candidate may need those
features on PMIP6.

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Basavaraj.Patil at nokia.com
> Sent: Wednesday, April 08, 2009 1:30 PM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Scope of proposed work
> 
> 
> Hello,
> 
> There is an issue in the current debate that we should put to rest.
> Netext proposes to extend PMIP6 to support multihoming, flow 
> mobility and inter-technology handovers (in addition to 
> others over which there is an agreement on). 
> 
> It is recognized that host based Mobile IP (RFC3775) and 
> DSMIP6 has these capabilities currently. I dont think there 
> is any debate about that. 
> However there is an interested group of people within the 
> IETF community who would like to extend PMIP6 to support 
> these features as well. 
> It is not uncommon in the IETF to have multiple competing 
> protocols provide similar functionality. The industry will 
> ultimately choose an appropriate solution depending on the 
> needs. So I dont think we can just quash the idea of working 
> on these extensions simply because we already have a protocol 
> that does it.
> It is also noted that one of the primary reasons for 
> developing PMIP6 was to provide mobility without host 
> involvement. The term "host-changes" in the context of the 
> current discussion are still to a large extent based on the 
> PMIP6 intent. As long as we are not defining a new protocol 
> on the host, we can consider the host as being unmodified 
> (from this disucssions PoV).
> 
> In summary I would say that this is not a discussion about 
> whether host based Mobile IP (MIP6) is the appropriate 
> protocol for providing multihoming, Flow mobility and, 
> inter-tech HOs but rather about what can be done to provide 
> similar capabilities to PMIP6 without (grossly) changing the 
> basic protocol principles.
> 
> -Raj
> 
> P.S: I recognize that some would say that inter-tech HOs and 
> multihoming are already features supported by PMIP6. In the 
> current context of Netext, what is being proposed is 
> basically enhancements to
> PMIP6 that address scenarios not currently in the base spec.
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: amuhanna at nortel.com (Ahmad Muhanna)
Date: Wed, 8 Apr 2009 15:41:24 -0500
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thanks Raj for this precise and to the point objective of NetExt.

I think if we all agree on this objective, then hopefully, it will be
much easier to fill in the missing charter work items.

Regards,
Ahmad

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Basavaraj.Patil at nokia.com
> Sent: Wednesday, April 08, 2009 3:30 PM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Scope of proposed work
> 
> 
> Hello,
> 
> There is an issue in the current debate that we should put to rest.
> Netext proposes to extend PMIP6 to support multihoming, flow 
> mobility and inter-technology handovers (in addition to 
> others over which there is an agreement on). 
> 
> It is recognized that host based Mobile IP (RFC3775) and 
> DSMIP6 has these capabilities currently. I dont think there 
> is any debate about that. 
> However there is an interested group of people within the 
> IETF community who would like to extend PMIP6 to support 
> these features as well. 
> It is not uncommon in the IETF to have multiple competing 
> protocols provide similar functionality. The industry will 
> ultimately choose an appropriate solution depending on the 
> needs. So I dont think we can just quash the idea of working 
> on these extensions simply because we already have a protocol 
> that does it.
> It is also noted that one of the primary reasons for 
> developing PMIP6 was to provide mobility without host 
> involvement. The term "host-changes" in the context of the 
> current discussion are still to a large extent based on the 
> PMIP6 intent. As long as we are not defining a new protocol 
> on the host, we can consider the host as being unmodified 
> (from this disucssions PoV).
> 
> In summary I would say that this is not a discussion about 
> whether host based Mobile IP (MIP6) is the appropriate 
> protocol for providing multihoming, Flow mobility and, 
> inter-tech HOs but rather about what can be done to provide 
> similar capabilities to PMIP6 without (grossly) changing the 
> basic protocol principles.
> 
> -Raj
> 
> P.S: I recognize that some would say that inter-tech HOs and 
> multihoming are already features supported by PMIP6. In the 
> current context of Netext, what is being proposed is 
> basically enhancements to
> PMIP6 that address scenarios not currently in the base spec.
> 
> 
> _______________________________________________
> 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: Wed, 8 Apr 2009 22:29:59 +0200
Subject: [Netext] Scope of proposed work
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

There is an issue in the current debate that we should put to rest.
Netext proposes to extend PMIP6 to support multihoming, flow mobility
and inter-technology handovers (in addition to others over which there is
an agreement on). 

It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
these capabilities currently. I dont think there is any debate about
that. 
However there is an interested group of people within the IETF
community who would like to extend PMIP6 to support these features as
well. 
It is not uncommon in the IETF to have multiple competing protocols
provide similar functionality. The industry will ultimately choose an
appropriate solution depending on the needs. So I dont think we can
just quash the idea of working on these extensions simply because we
already have a protocol that does it.
It is also noted that one of the primary reasons for developing PMIP6
was to provide mobility without host involvement. The term
"host-changes" in the context of the current discussion are still to a
large extent based on the PMIP6 intent. As long as we are not defining
a new protocol on the host, we can consider the host as being
unmodified (from this disucssions PoV).

In summary I would say that this is not a discussion about whether
host based Mobile IP (MIP6) is the appropriate protocol for providing
multihoming, Flow mobility and, inter-tech HOs but rather about what
can be done to provide similar capabilities to PMIP6 without (grossly)
changing the basic protocol principles.

-Raj

P.S: I recognize that some would say that inter-tech HOs and
multihoming are already features supported by PMIP6. In the current
context of Netext, what is being proposed is basically enhancements to
PMIP6 that address scenarios not currently in the base spec.

From: sgundave at cisco.com (Sri Gundavelli)
Date: Wed, 8 Apr 2009 12:50:55 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I agree, this discussion is going on a different track. This wont
converge. Secondly, we are bundling every thing together and making
blanket statements. There are statements, multi-homing/handover
does not work in PMIPv6, or that there needs to be an L2 interface ..
there seems to be lot of assumptions around this, with out qualifying
that, these statements are only creating confusion. Couple of points:

- Multihoming is supported in PMIPv6
- Inter-tech handovers are supported in PMIPv6
- None of these features break or burn the host.

3GPP is not the only consumer for this work. Nothing stops some one from
building an IPv6 enterprise mobility solution based on Proxy Mobile IPv6,
as it is not a 3GPP specific protocol, but a protocol that can be deployed
in enterprise wireless architectures. No one can tell me, we cant deploy
this protocol for solving micro mobility problems in an integrated
wired/wireless AP environments, targetted for an enterprise.

>From the list of proposed items, I'd really hope to identify the work
items that does not require extesive debates from the ones that requires
fist-fighting.

- Flow mobility has the scope from moving individual flows of interest
with no relation to prefix, vs moving flows as a bundle associated to a
prefix.

- Host specific doc, from the point of view of leveraging what 5213
supports, vs, for supporting the new features.

- Multi-homing, binding a single prefix to multiple interfaces, vs, an
individual prefix to each interface.

We have to qualify the discussions around this, just the use of the
key words multi-homing, inter-tech handovers, flow mobility, and
saying is not for PMIP6, is not accurate, does not justify the
concern and does not help the discussions. We have to state which
specific item has issues and under what scenario's.

Thanks
Sri

On Wed, 8 Apr 2009, Basavaraj.Patil at nokia.com wrote:

>
> Hello,
>
> Lets try and keep this discussion focused on technical issues.
> The current tone is not very encouraging in some instances.
>
> The current discussion is overly focused on what 3GPP is doing w.r.t PMIP6
> and future work items. 3GPP tends to use IETF protocols when they see a good
> fit for their architecture and problem scope. We cannot tell 3GPP to not
> develop a feature by themselves and instead rely on the IETF to deliver it.
> They are free to do whatever they want.
>
> Within the IETF we can identify what problems or extensions to PMIP6 we want
> to work on and focus on these. If 3GPP finds the solution applicable, they
> will use it. The IETF solution has to address the generic problem and not
> tailored for 3GPP (which is what we seem to be doing now).
> So maybe we can get down to discussing the problem and scenarios that we
> would like to work on in Netext as a way of moving forward.
>
> In order to make progress, I would suggest that we focus on the following 3
> topics:
> A. Multihoming
> B. Flow mobility
> C. Inter technology handovers
>
> If we can articulate the scenarios and associated problems with each of the
> same, we can then get a better handle on what to take on in Netext. And lets
> not start saying that we already have a solution in I-Dx or I-Dy.
>
> -Raj
>
>
>
>
> On 4/8/09 12:33 PM, "ext Vijay Devarapalli" <vijay at wichorus.com> wrote:
>
>> Hi George,
>>
>> George Tsirtsis wrote:
>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli <vijay at wichorus.com>
>>> wrote:
>>>> Hi Gerardo,
>>>>
>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>> solutions proposed on any I-D - there is a 3GPP-specific
>>>>> solution proposed for PMIPv6 (based on the policy infrastructure).
>>>>
>>>> This is exactly what I would like to avoid. I would prefer using a
>>>> solution developed in the IETF rather than something in 3GPP.
>>>>
>>>
>>> GT> Why not? 3GPP and other SDOs have been creating technology for
>>> almost as long as the IETF. Getting the IETF to do something only
>>> makes sense if the given protocol has general applicability and does
>>> not damage the Internet, which is why we are having this discussion.
>>
>> So far 3GPP has been mostly been using PMIPv6 with no or very little
>> modifications. They have added some vendor specific options for carrying
>> some 3GPP specific information, but they are minor extensions. So when
>> 3GPP is considering flow mobility for PMIPv6, it doesn't make sense for
>> them to develop a solution on their own. It should be done in the IETF.
>>
>> And can we please stop the hyperbole about "damaging the Internet"? It
>> is irritating and doesn't contribute to the discussion.
>>
>>> GT> In another e-mail where you are over-viewing a possible solution
>>> to PMIP multihoming you talk about how the MN may use an L2 to signal
>>> to indicate what flows need to go to a given MAG. I do not see how the
>>> IETF can define a protocol that fully depends on such an L2 signal. If
>>> such functionality is needed then the IETF must define it at the IP
>>> layer to make sure that this works across ALL link layers (which is
>>> the main reason the IETF and the Internet exist).
>>
>> Indicating the service identifier during an L2 attachment is supported
>> in most accesses that PMIPv6 is being used for. So I don't see it as a
>> big issue. You don't need a MN-MAG IP protocol for carrying the service
>> identifier. That would be an overkill.
>>
>> Anyway, flow mobility can still be achieved even if the MN does not
>> indicate the service identifier. Please see
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>
>>> GT> So, in my book you (pmip mhoming fans) have two hurdles to overcome:
>>> 1) Admit to yourself that to do this in the IETF you need to define an
>>> MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>
>> That is one option, but not required.
>>
>> Vijay
>>
>>> 2) Convince people that defining such a client based protocol in
>>> addition to the existing standard (MIPv6) is warranted. In the
>>> process, explain to people why you want to introduce FA functionality
>>> to MIPv6, which is what MAGs become if you add an MN-MAG leg to PMIP's
>>> MAG-HA leg.
>>>
>>> George
>>>
>>>
>>>> Vijay
>>>>
>>>>> 3GPP has not decided yet to do any normative work on any of
>>>>> the solutions.
>>>>>
>>>>> Gerardo
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>> To: Giaretta, Gerardo
>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>>>>>> Basavaraj.Patil at nokia.com
>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>> list, sorry for that
>>>>>>> :-)
>>>>>>
>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>> function though.
>>>>>> Based on your last email, I don't understand what is the
>>>>> basis for the
>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>> claim not backed
>>>>>> by 3GPP.
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Gerardo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>> (discussed at the
>>>>>> last
>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>> WiMAX with PMIPv6
>>>>>>>> working.
>>>>>>>>>
>>>>>>>>>> Such
>>>>>>>>>> large scale managed networks are the main consumers of
>>>>> PMIP6 so we
>>>>>>>> shouldn't
>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>
>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>> note that I am
>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>> homogeneous from a
>>>>>>>> link layer point of view.
>>>>>>>>>
>>>>>>>>> Gerardo
>>>>>>>>>
>>>>>>>>>> Saying to use MIP for inter-access
>>>>>>>>>> handovers/multihoming is not helping as they have
>>>>> really set their mind
>>>>>> on
>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>> going into the
>>>>>>>> reasoning
>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>> defined in RFC 5213,
>>>>>> has
>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>> better to fix those
>>>>>> PMIP6
>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>> their own way of
>>>>>>>>>> dealing with this.
>>>>>>>>>>
>>>>>>>>>> domagoj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>>>>>>> the first place.
>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>> network-based
>>>>>>>>>>>> mobility management (PMIPv6) to support advanced use cases.
>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>
>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>> RFC4830 does. I don't
>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>> host-based mobility
>>>>>>>>>>>> protocol again.
>>>>>>>>>>> => I don't know what the goal is based on the BoF discussion
>>>>>>>>>>> and this discussion on the list. The reason I don't know that
>>>>>>>>>>> is that no one is
>>>>>>>>>>> saying:
>>>>>>>>>>> Here is the state of the art (including BOTH MIP and PMIP)
>>>>>>>>>>> and here is why they don't work, therefore we need to do
>>>>>>>>>>> something new.
>>>>>>>>>>> That's what a PS should say. What's being said here is "PMIP
>>>>>>>>>>> doesn't support advanced cases therefore we need something
>>>>>>>>>>> new", which is completely bogus because PMIP was not designed
>>>>>>>>>>> to support those cases because we already have something else
>>>>>>>>>>> for supporting those cases. Hence my reference to 4830...
>>>>>>>>>>>
>>>>>>>>>>> I'm going to retire from the discussion till someone makes
>>>>>>>>>>> the argument above. Because I feel that if there is no such
>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> => Yes, additional software like the existing MIP. I don't
>>>>>>>>>>> understand
>>>>>>>>>>>>> the motivation for creating something new. I've detailed
>>>>>>>>>>> this in my
>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>
>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>> management
>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>> seems to be a
>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>> => You're missing the point. Why isn't anybody talking about
>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>
>>>>>>>>>>> Hesham
>>>>>>>>>>>
>>>>>>>>>>>> marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>
>>>>>>>>>>>>> distinguish modification for mobility management, which
>>>>>>>>>>> is not what
>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>> as the use of
>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>> configure
>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> marco
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>> unmodified
>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>> the BoF, our
>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>> the host
>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>> stick with MIP.
>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>> is not a
>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>> this is such a
>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>> room was in
>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>> raised for the
>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>> and intertech
>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => I think the question changed a few times :) The final
>>>>>>>>>>> question
>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>> with this or
>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>> mentioned here
>>>>>>>>>>>>> because they were one of the very few reasons for using
>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>> the host) and
>>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>> relying on a
>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>> anyway. However if
>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>> not specify how
>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => Because we already have a solution that works
>>>>> in all L2s,
>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>> confusing host
>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>> is not done
>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>> or config?
>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>> in the IETF
>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>> changes to SW etc.
>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>>>>> reasons for
>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>> ways, or can
>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>> scope in IETF
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>> could specify
>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>> if that is the
>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>>>>> solution
>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>> is inferior in
>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>> comments.
>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>> basic handoff
>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>> mostly flow
>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>

From: xiayangsong at huawei.com (Frank Xia)
Date: Wed, 08 Apr 2009 14:12:13 -0500
Subject: [Netext] next steps for netext
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj

I agree with you.  Basing on IETF and focusing
on technical issues is what we should do here.

I volunteer to draft a PS on flow mobility if people
think it is worthwhile.

BR
Frank

----- Original Message ----- 
From: <Basavaraj.Patil at nokia.com>
To: <vijay at wichorus.com>; <tsirtsis at googlemail.com>
Cc: <gerardog at qualcomm.com>; <netext at mail.mobileip.jp>
Sent: Wednesday, April 08, 2009 12:56 PM
Subject: Re: [Netext] next steps for netext

>
> Hello,
>
> Lets try and keep this discussion focused on technical issues.
> The current tone is not very encouraging in some instances.
>
> The current discussion is overly focused on what 3GPP is doing w.r.t PMIP6
> and future work items. 3GPP tends to use IETF protocols when they see a 
> good
> fit for their architecture and problem scope. We cannot tell 3GPP to not
> develop a feature by themselves and instead rely on the IETF to deliver 
> it.
> They are free to do whatever they want.
>
> Within the IETF we can identify what problems or extensions to PMIP6 we 
> want
> to work on and focus on these. If 3GPP finds the solution applicable, they
> will use it. The IETF solution has to address the generic problem and not
> tailored for 3GPP (which is what we seem to be doing now).
> So maybe we can get down to discussing the problem and scenarios that we
> would like to work on in Netext as a way of moving forward.
>
> In order to make progress, I would suggest that we focus on the following 
> 3
> topics:
> A. Multihoming
> B. Flow mobility
> C. Inter technology handovers
>
> If we can articulate the scenarios and associated problems with each of 
> the
> same, we can then get a better handle on what to take on in Netext. And 
> lets
> not start saying that we already have a solution in I-Dx or I-Dy.
>
> -Raj
>
>
>
>
> On 4/8/09 12:33 PM, "ext Vijay Devarapalli" <vijay at wichorus.com> wrote:
>
>> Hi George,
>>
>> George Tsirtsis wrote:
>>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli <vijay at wichorus.com>
>>> wrote:
>>>> Hi Gerardo,
>>>>
>>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>>> solutions proposed on any I-D - there is a 3GPP-specific
>>>>> solution proposed for PMIPv6 (based on the policy infrastructure).
>>>>
>>>> This is exactly what I would like to avoid. I would prefer using a
>>>> solution developed in the IETF rather than something in 3GPP.
>>>>
>>>
>>> GT> Why not? 3GPP and other SDOs have been creating technology for
>>> almost as long as the IETF. Getting the IETF to do something only
>>> makes sense if the given protocol has general applicability and does
>>> not damage the Internet, which is why we are having this discussion.
>>
>> So far 3GPP has been mostly been using PMIPv6 with no or very little
>> modifications. They have added some vendor specific options for carrying
>> some 3GPP specific information, but they are minor extensions. So when
>> 3GPP is considering flow mobility for PMIPv6, it doesn't make sense for
>> them to develop a solution on their own. It should be done in the IETF.
>>
>> And can we please stop the hyperbole about "damaging the Internet"? It
>> is irritating and doesn't contribute to the discussion.
>>
>>> GT> In another e-mail where you are over-viewing a possible solution
>>> to PMIP multihoming you talk about how the MN may use an L2 to signal
>>> to indicate what flows need to go to a given MAG. I do not see how the
>>> IETF can define a protocol that fully depends on such an L2 signal. If
>>> such functionality is needed then the IETF must define it at the IP
>>> layer to make sure that this works across ALL link layers (which is
>>> the main reason the IETF and the Internet exist).
>>
>> Indicating the service identifier during an L2 attachment is supported
>> in most accesses that PMIPv6 is being used for. So I don't see it as a
>> big issue. You don't need a MN-MAG IP protocol for carrying the service
>> identifier. That would be an overkill.
>>
>> Anyway, flow mobility can still be achieved even if the MN does not
>> indicate the service identifier. Please see
>> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>>
>>> GT> So, in my book you (pmip mhoming fans) have two hurdles to overcome:
>>> 1) Admit to yourself that to do this in the IETF you need to define an
>>> MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>>
>> That is one option, but not required.
>>
>> Vijay
>>
>>> 2) Convince people that defining such a client based protocol in
>>> addition to the existing standard (MIPv6) is warranted. In the
>>> process, explain to people why you want to introduce FA functionality
>>> to MIPv6, which is what MAGs become if you add an MN-MAG leg to PMIP's
>>> MAG-HA leg.
>>>
>>> George
>>>
>>>
>>>> Vijay
>>>>
>>>>> 3GPP has not decided yet to do any normative work on any of
>>>>> the solutions.
>>>>>
>>>>> Gerardo
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>>> To: Giaretta, Gerardo
>>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>>>>>> Basavaraj.Patil at nokia.com
>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I will now stop discussing 3GPP specific issues in this
>>>>> list, sorry for that
>>>>>>> :-)
>>>>>>
>>>>>> => Please continue to tell us whether 3GPP needs certain
>>>>> function though.
>>>>>> Based on your last email, I don't understand what is the
>>>>> basis for the
>>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>>> claim not backed
>>>>>> by 3GPP.
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Gerardo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Vijay
>>>>>>>>
>>>>>>>>> On the WiMAX side, I know there are still open issues
>>>>> (discussed at the
>>>>>> last
>>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>>> WiMAX with PMIPv6
>>>>>>>> working.
>>>>>>>>>
>>>>>>>>>> Such
>>>>>>>>>> large scale managed networks are the main consumers of
>>>>> PMIP6 so we
>>>>>>>> shouldn't
>>>>>>>>>> be ignoring what they're doing.
>>>>>>>>>
>>>>>>>>> This is mainly true for intra-technology mobility - and
>>>>> note that I am
>>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>>> homogeneous from a
>>>>>>>> link layer point of view.
>>>>>>>>>
>>>>>>>>> Gerardo
>>>>>>>>>
>>>>>>>>>> Saying to use MIP for inter-access
>>>>>>>>>> handovers/multihoming is not helping as they have
>>>>> really set their mind
>>>>>> on
>>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>>> going into the
>>>>>>>> reasoning
>>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>>> defined in RFC 5213,
>>>>>> has
>>>>>>>>>> issues with inter-access handovers. I think it is
>>>>> better to fix those
>>>>>> PMIP6
>>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>>> their own way of
>>>>>>>>>> dealing with this.
>>>>>>>>>>
>>>>>>>>>> domagoj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>>>>>>>> Hesham Soliman
>>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>>>>>>>> 4830 is quite
>>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>>>>>>> the first place.
>>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>>> network-based
>>>>>>>>>>>> mobility management (PMIPv6) to support advanced use cases.
>>>>>>>>>>> => Where is that PS?
>>>>>>>>>>>
>>>>>>>>>>>   Not the problem of
>>>>>>>>>>>> existing solutions for localized mobility, as
>>>>> RFC4830 does. I don't
>>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>>> host-based mobility
>>>>>>>>>>>> protocol again.
>>>>>>>>>>> => I don't know what the goal is based on the BoF discussion
>>>>>>>>>>> and this discussion on the list. The reason I don't know that
>>>>>>>>>>> is that no one is
>>>>>>>>>>> saying:
>>>>>>>>>>> Here is the state of the art (including BOTH MIP and PMIP)
>>>>>>>>>>> and here is why they don't work, therefore we need to do
>>>>>>>>>>> something new.
>>>>>>>>>>> That's what a PS should say. What's being said here is "PMIP
>>>>>>>>>>> doesn't support advanced cases therefore we need something
>>>>>>>>>>> new", which is completely bogus because PMIP was not designed
>>>>>>>>>>> to support those cases because we already have something else
>>>>>>>>>>> for supporting those cases. Hence my reference to 4830...
>>>>>>>>>>>
>>>>>>>>>>> I'm going to retire from the discussion till someone makes
>>>>>>>>>>> the argument above. Because I feel that if there is no such
>>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> => Yes, additional software like the existing MIP. I don't
>>>>>>>>>>> understand
>>>>>>>>>>>>> the motivation for creating something new. I've detailed
>>>>>>>>>>> this in my
>>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>>
>>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>>> management
>>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>>> seems to be a
>>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>>> => You're missing the point. Why isn't anybody talking about
>>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>>
>>>>>>>>>>> Hesham
>>>>>>>>>>>
>>>>>>>>>>>> marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>>
>>>>>>>>>>>>> distinguish modification for mobility management, which
>>>>>>>>>>> is not what
>>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>>> as the use of
>>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>>> configure
>>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> marco
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>>> unmodified
>>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>>> protocols or not.
>>>>>>>>>>>>> That's fine, but for those that did not attend
>>>>> the BoF, our
>>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>>> the host
>>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>>> stick with MIP.
>>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>>> is not a
>>>>>>>>>>>>> good way to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can discuss what implies host changes and why
>>>>> this is such a
>>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>>> room was in
>>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>>> raised for the
>>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>>> and intertech
>>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => I think the question changed a few times :) The final
>>>>>>>>>>> question
>>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>>> with this or
>>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>>> The host changes are not a big deal but they are
>>>>> mentioned here
>>>>>>>>>>>>> because they were one of the very few reasons for using
>>>>>>>>>>> NETLMM in
>>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>>> the host) and
>>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>>> relying on a
>>>>>>>>>>>>> solution that will:
>>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have no ability to specify changes to L2
>>>>> anyway. However if
>>>>>>>>>>>>> some L2s do have such capability, why would we
>>>>> not specify how
>>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => Because we already have a solution that works
>>>>> in all L2s,
>>>>>>>>>>>>> doesn't require
>>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>>> confusing host
>>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>>> is not done
>>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>>> or config?
>>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>>> in the IETF
>>>>>>>>>>>>> requires configurations, protocol changes,
>>>>> changes to SW etc.
>>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>>>>> reasons for
>>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>>> ways, or can
>>>>>>>>>>>>> we? :)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>>> scope in IETF
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>>> could specify
>>>>>>>>>>>>> (informatively)
>>>>>>>>>>>>> what L2 capabilities would enable these features
>>>>> if that is the
>>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>>>>> solution
>>>>>>>>>>>>> already exists. Especially when the alternative
>>>>> is inferior in
>>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hesham
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>> comments.
>>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>> basic handoff
>>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>>> mostly flow
>>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>> today in 5213.
>>>>>>>>>>>>> Sri
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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 

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Wed, 8 Apr 2009 19:56:45 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

Lets try and keep this discussion focused on technical issues.
The current tone is not very encouraging in some instances.

The current discussion is overly focused on what 3GPP is doing w.r.t PMIP6
and future work items. 3GPP tends to use IETF protocols when they see a good
fit for their architecture and problem scope. We cannot tell 3GPP to not
develop a feature by themselves and instead rely on the IETF to deliver it.
They are free to do whatever they want.

Within the IETF we can identify what problems or extensions to PMIP6 we want
to work on and focus on these. If 3GPP finds the solution applicable, they
will use it. The IETF solution has to address the generic problem and not
tailored for 3GPP (which is what we seem to be doing now).
So maybe we can get down to discussing the problem and scenarios that we
would like to work on in Netext as a way of moving forward.

In order to make progress, I would suggest that we focus on the following 3
topics:
A. Multihoming
B. Flow mobility
C. Inter technology handovers

If we can articulate the scenarios and associated problems with each of the
same, we can then get a better handle on what to take on in Netext. And lets
not start saying that we already have a solution in I-Dx or I-Dy.

-Raj

On 4/8/09 12:33 PM, "ext Vijay Devarapalli" <vijay at wichorus.com> wrote:

> Hi George,
>
> George Tsirtsis wrote:
>> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli <vijay at wichorus.com>
>> wrote:
>>> Hi Gerardo,
>>>
>>>> 3GPP has a study item on this feature. There was no PMIPv6
>>>> solutions proposed on any I-D - there is a 3GPP-specific
>>>> solution proposed for PMIPv6 (based on the policy infrastructure).
>>>
>>> This is exactly what I would like to avoid. I would prefer using a
>>> solution developed in the IETF rather than something in 3GPP.
>>>
>>
>> GT> Why not? 3GPP and other SDOs have been creating technology for
>> almost as long as the IETF. Getting the IETF to do something only
>> makes sense if the given protocol has general applicability and does
>> not damage the Internet, which is why we are having this discussion.
>
> So far 3GPP has been mostly been using PMIPv6 with no or very little
> modifications. They have added some vendor specific options for carrying
> some 3GPP specific information, but they are minor extensions. So when
> 3GPP is considering flow mobility for PMIPv6, it doesn't make sense for
> them to develop a solution on their own. It should be done in the IETF.
>
> And can we please stop the hyperbole about "damaging the Internet"? It
> is irritating and doesn't contribute to the discussion.
>
>> GT> In another e-mail where you are over-viewing a possible solution
>> to PMIP multihoming you talk about how the MN may use an L2 to signal
>> to indicate what flows need to go to a given MAG. I do not see how the
>> IETF can define a protocol that fully depends on such an L2 signal. If
>> such functionality is needed then the IETF must define it at the IP
>> layer to make sure that this works across ALL link layers (which is
>> the main reason the IETF and the Internet exist).
>
> Indicating the service identifier during an L2 attachment is supported
> in most accesses that PMIPv6 is being used for. So I don't see it as a
> big issue. You don't need a MN-MAG IP protocol for carrying the service
> identifier. That would be an overkill.
>
> Anyway, flow mobility can still be achieved even if the MN does not
> indicate the service identifier. Please see
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt
>
>> GT> So, in my book you (pmip mhoming fans) have two hurdles to overcome:
>> 1) Admit to yourself that to do this in the IETF you need to define an
>> MN-MAG protocol at the IP layer (e.g., see Conny's draft)
>
> That is one option, but not required.
>
> Vijay
>
>> 2) Convince people that defining such a client based protocol in
>> addition to the existing standard (MIPv6) is warranted. In the
>> process, explain to people why you want to introduce FA functionality
>> to MIPv6, which is what MAGs become if you add an MN-MAG leg to PMIP's
>> MAG-HA leg.
>>
>> George
>>
>>
>>> Vijay
>>>
>>>> 3GPP has not decided yet to do any normative work on any of
>>>> the solutions.
>>>>
>>>> Gerardo
>>>>
>>>>> -----Original Message-----
>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>> Sent: Tuesday, April 07, 2009 2:52 PM
>>>>> To: Giaretta, Gerardo
>>>>> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>>>>> Basavaraj.Patil at nokia.com
>>>>> Subject: Re: [Netext] next steps for netext
>>>>>
>>>>>
>>>>>>
>>>>>> I will now stop discussing 3GPP specific issues in this
>>>> list, sorry for that
>>>>>> :-)
>>>>>
>>>>> => Please continue to tell us whether 3GPP needs certain
>>>> function though.
>>>>> Based on your last email, I don't understand what is the
>>>> basis for the
>>>>> claims of 3GPP needing this function. Seems like a baseless
>>>> claim not backed
>>>>> by 3GPP.
>>>>>
>>>>> Hesham
>>>>>
>>>>>
>>>>>>
>>>>>> Gerardo
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Vijay
>>>>>>>
>>>>>>>> On the WiMAX side, I know there are still open issues
>>>> (discussed at the
>>>>> last
>>>>>>> 3GPP SA2 meeting) to make a handover between 3GPP and
>>>> WiMAX with PMIPv6
>>>>>>> working.
>>>>>>>>
>>>>>>>>> Such
>>>>>>>>> large scale managed networks are the main consumers of
>>>> PMIP6 so we
>>>>>>> shouldn't
>>>>>>>>> be ignoring what they're doing.
>>>>>>>>
>>>>>>>> This is mainly true for intra-technology mobility - and
>>>> note that I am
>>>>>>> considering LTE-eHRPD intra-technology here as they are
>>>> homogeneous from a
>>>>>>> link layer point of view.
>>>>>>>>
>>>>>>>> Gerardo
>>>>>>>>
>>>>>>>>> Saying to use MIP for inter-access
>>>>>>>>> handovers/multihoming is not helping as they have
>>>> really set their mind
>>>>> on
>>>>>>>>> using PMIP6 and they're already doing this. Without
>>>> going into the
>>>>>>> reasoning
>>>>>>>>> behind such a decision, the fact is that PMIP6, as
>>>> defined in RFC 5213,
>>>>> has
>>>>>>>>> issues with inter-access handovers. I think it is
>>>> better to fix those
>>>>> PMIP6
>>>>>>>>> issues in the IETF then to let each SDO come up with
>>>> their own way of
>>>>>>>>> dealing with this.
>>>>>>>>>
>>>>>>>>> domagoj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: netext-bounces at mail.mobileip.jp
>>>>>>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>>>>>>> Hesham Soliman
>>>>>>>>>> Sent: 07. travanj 2009 11:14
>>>>>>>>>> To: Marco Liebsch
>>>>>>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>>>>>>> Subject: Re: [Netext] next steps for netext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>>>>>>> 4830 is quite
>>>>>>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>>>>>> the first place.
>>>>>>>>>>> Yes, a problem statement about an existing solution for
>>>>>>>>>> network-based
>>>>>>>>>>> mobility management (PMIPv6) to support advanced use cases.
>>>>>>>>>> => Where is that PS?
>>>>>>>>>>
>>>>>>>>>>   Not the problem of
>>>>>>>>>>> existing solutions for localized mobility, as
>>>> RFC4830 does. I don't
>>>>>>>>>>> think NetExt aims at turning PMIPv6 into a
>>>> host-based mobility
>>>>>>>>>>> protocol again.
>>>>>>>>>> => I don't know what the goal is based on the BoF discussion
>>>>>>>>>> and this discussion on the list. The reason I don't know that
>>>>>>>>>> is that no one is
>>>>>>>>>> saying:
>>>>>>>>>> Here is the state of the art (including BOTH MIP and PMIP)
>>>>>>>>>> and here is why they don't work, therefore we need to do
>>>>>>>>>> something new.
>>>>>>>>>> That's what a PS should say. What's being said here is "PMIP
>>>>>>>>>> doesn't support advanced cases therefore we need something
>>>>>>>>>> new", which is completely bogus because PMIP was not designed
>>>>>>>>>> to support those cases because we already have something else
>>>>>>>>>> for supporting those cases. Hence my reference to 4830...
>>>>>>>>>>
>>>>>>>>>> I'm going to retire from the discussion till someone makes
>>>>>>>>>> the argument above. Because I feel that if there is no such
>>>>>>>>>> argument then the discussion is not a good use of time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> => Yes, additional software like the existing MIP. I don't
>>>>>>>>>> understand
>>>>>>>>>>>> the motivation for creating something new. I've detailed
>>>>>>>>>> this in my
>>>>>>>>>>>> previous emails and the points remain unanswered.
>>>>>>>>>>>>
>>>>>>>>>>> Nobody talks about adding a piece of client mobility
>>>> management
>>>>>>>>>>> software, such as a MIP client, to the mobile. That
>>>> seems to be a
>>>>>>>>>>> wrong interpretation of what NetExt wants to do.
>>>>>>>>>> => You're missing the point. Why isn't anybody talking about
>>>>>>>>>> MIP??? That's what a PS should say.
>>>>>>>>>>
>>>>>>>>>> Hesham
>>>>>>>>>>
>>>>>>>>>>> marco
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> and obviously also according to RFC4831. We should
>>>>>>>>>>>>
>>>>>>>>>>>> distinguish modification for mobility management, which
>>>>>>>>>> is not what
>>>>>>>>>>>> we want to do, and enabling local functions, such
>>>> as the use of
>>>>>>>>>>>> multiple interfaces, where you have to add routes,
>>>> configure
>>>>>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>>>>>>
>>>>>>>>>>>> marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham Soliman schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>> unmodified
>>>>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>> protocols or not.
>>>>>>>>>>>> That's fine, but for those that did not attend
>>>> the BoF, our
>>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>> the host
>>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>>> L2 to handle the multihoming cases, or you can
>>>> stick with MIP.
>>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>> is not a
>>>>>>>>>>>> good way to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We can discuss what implies host changes and why
>>>> this is such a
>>>>>>>>>>>> big deal anyway. But I don't think that half the
>>>> room was in
>>>>>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>>> raised for the
>>>>>>>>>>>> question about whether we should work on multihoming
>>>>>>>>>> and intertech
>>>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => I think the question changed a few times :) The final
>>>>>>>>>> question
>>>>>>>>>>>> (which was specific to whether people wanted to work
>>>>>>>>>> with this or
>>>>>>>>>>>> not) showed a split room.
>>>>>>>>>>>> The host changes are not a big deal but they are
>>>> mentioned here
>>>>>>>>>>>> because they were one of the very few reasons for using
>>>>>>>>>> NETLMM in
>>>>>>>>>>>> the first place: Host changes (adding new SW to
>>>> the host) and
>>>>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>>>> RFC 4830.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>> relying on a
>>>>>>>>>>>> solution that will:
>>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We have no ability to specify changes to L2
>>>> anyway. However if
>>>>>>>>>>>> some L2s do have such capability, why would we
>>>> not specify how
>>>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => Because we already have a solution that works
>>>> in all L2s,
>>>>>>>>>>>> doesn't require
>>>>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>>>> confusing host
>>>>>>>>>>>> config solutions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>> is not done
>>>>>>>>>>>> anywhere today, and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>>> or config?
>>>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>>> in the IETF
>>>>>>>>>>>> requires configurations, protocol changes,
>>>> changes to SW etc.
>>>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>>>> reasons for
>>>>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>>>> ways, or can
>>>>>>>>>>>> we? :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - Require L2 signalling which is out of our
>>>> scope in IETF
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Agree. We cannot do anything about L2s. But we
>>>> could specify
>>>>>>>>>>>> (informatively)
>>>>>>>>>>>> what L2 capabilities would enable these features
>>>> if that is the
>>>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>>>> solution
>>>>>>>>>>>> already exists. Especially when the alternative
>>>> is inferior in
>>>>>>>>>>>> terms of its applicability.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -Raj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>> that Jari sent.
>>>>>>>>>>>>
>>>>>>>>>>>> Hesham
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>> comments.
>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>> basic handoff
>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>>>> mostly flow
>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>> today in 5213.
>>>>>>>>>>>> Sri
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>
>>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Wed, 08 Apr 2009 10:33:03 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi George,

George Tsirtsis wrote:
> On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli <vijay at wichorus.com> 
> wrote:
>  > Hi Gerardo,
>  >
>  >> 3GPP has a study item on this feature. There was no PMIPv6
>  >> solutions proposed on any I-D - there is a 3GPP-specific
>  >> solution proposed for PMIPv6 (based on the policy infrastructure).
>  >
>  > This is exactly what I would like to avoid. I would prefer using a
>  > solution developed in the IETF rather than something in 3GPP.
>  >
> 
> GT> Why not? 3GPP and other SDOs have been creating technology for
> almost as long as the IETF. Getting the IETF to do something only
> makes sense if the given protocol has general applicability and does
> not damage the Internet, which is why we are having this discussion.

So far 3GPP has been mostly been using PMIPv6 with no or very little 
modifications. They have added some vendor specific options for carrying 
some 3GPP specific information, but they are minor extensions. So when 
3GPP is considering flow mobility for PMIPv6, it doesn't make sense for 
them to develop a solution on their own. It should be done in the IETF.

And can we please stop the hyperbole about "damaging the Internet"? It 
is irritating and doesn't contribute to the discussion.

> GT> In another e-mail where you are over-viewing a possible solution
> to PMIP multihoming you talk about how the MN may use an L2 to signal
> to indicate what flows need to go to a given MAG. I do not see how the
> IETF can define a protocol that fully depends on such an L2 signal. If
> such functionality is needed then the IETF must define it at the IP
> layer to make sure that this works across ALL link layers (which is
> the main reason the IETF and the Internet exist).

Indicating the service identifier during an L2 attachment is supported 
in most accesses that PMIPv6 is being used for. So I don't see it as a 
big issue. You don't need a MN-MAG IP protocol for carrying the service 
identifier. That would be an overkill.

Anyway, flow mobility can still be achieved even if the MN does not 
indicate the service identifier. Please see 
http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt

> GT> So, in my book you (pmip mhoming fans) have two hurdles to overcome:
> 1) Admit to yourself that to do this in the IETF you need to define an
> MN-MAG protocol at the IP layer (e.g., see Conny's draft)

That is one option, but not required.

Vijay

> 2) Convince people that defining such a client based protocol in
> addition to the existing standard (MIPv6) is warranted. In the
> process, explain to people why you want to introduce FA functionality
> to MIPv6, which is what MAGs become if you add an MN-MAG leg to PMIP's
> MAG-HA leg.
> 
> George
> 
> 
>  > Vijay
>  >
>  >> 3GPP has not decided yet to do any normative work on any of
>  >> the solutions.
>  >>
>  >> Gerardo
>  >>
>  >> > -----Original Message-----
>  >> > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>  >> > Sent: Tuesday, April 07, 2009 2:52 PM
>  >> > To: Giaretta, Gerardo
>  >> > Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>  >> > Basavaraj.Patil at nokia.com
>  >> > Subject: Re: [Netext] next steps for netext
>  >> >
>  >> >
>  >> > >
>  >> > > I will now stop discussing 3GPP specific issues in this
>  >> list, sorry for that
>  >> > > :-)
>  >> >
>  >> > => Please continue to tell us whether 3GPP needs certain
>  >> function though.
>  >> > Based on your last email, I don't understand what is the
>  >> basis for the
>  >> > claims of 3GPP needing this function. Seems like a baseless
>  >> claim not backed
>  >> > by 3GPP.
>  >> >
>  >> > Hesham
>  >> >
>  >> >
>  >> > >
>  >> > > Gerardo
>  >> > >
>  >> > >
>  >> > >
>  >> > >> Vijay
>  >> > >>
>  >> > >>> On the WiMAX side, I know there are still open issues
>  >> (discussed at the
>  >> > last
>  >> > >> 3GPP SA2 meeting) to make a handover between 3GPP and
>  >> WiMAX with PMIPv6
>  >> > >> working.
>  >> > >>>
>  >> > >>>> Such
>  >> > >>>> large scale managed networks are the main consumers of
>  >> PMIP6 so we
>  >> > >> shouldn't
>  >> > >>>> be ignoring what they're doing.
>  >> > >>>
>  >> > >>> This is mainly true for intra-technology mobility - and
>  >> note that I am
>  >> > >> considering LTE-eHRPD intra-technology here as they are
>  >> homogeneous from a
>  >> > >> link layer point of view.
>  >> > >>>
>  >> > >>> Gerardo
>  >> > >>>
>  >> > >>>> Saying to use MIP for inter-access
>  >> > >>>> handovers/multihoming is not helping as they have
>  >> really set their mind
>  >> > on
>  >> > >>>> using PMIP6 and they're already doing this. Without
>  >> going into the
>  >> > >> reasoning
>  >> > >>>> behind such a decision, the fact is that PMIP6, as
>  >> defined in RFC 5213,
>  >> > has
>  >> > >>>> issues with inter-access handovers. I think it is
>  >> better to fix those
>  >> > PMIP6
>  >> > >>>> issues in the IETF then to let each SDO come up with
>  >> their own way of
>  >> > >>>> dealing with this.
>  >> > >>>>
>  >> > >>>> domagoj
>  >> > >>>>
>  >> > >>>>
>  >> > >>>>> -----Original Message-----
>  >> > >>>>> From: netext-bounces at mail.mobileip.jp
>  >> > >>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>  >> > >>>>> Hesham Soliman
>  >> > >>>>> Sent: 07. travanj 2009 11:14
>  >> > >>>>> To: Marco Liebsch
>  >> > >>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>  >> > >>>>> Subject: Re: [Netext] next steps for netext
>  >> > >>>>>
>  >> > >>>>>
>  >> > >>>>>>> => We're discussing a problem statement for the BoF, so
>  >> > >>>>> 4830 is quite
>  >> > >>>>>>> appropriate as a reference for why people wanted PMIP in
>  >> > >>>>> the first place.
>  >> > >>>>>> Yes, a problem statement about an existing solution for
>  >> > >>>>> network-based
>  >> > >>>>>> mobility management (PMIPv6) to support advanced use cases.
>  >> > >>>>> => Where is that PS?
>  >> > >>>>>
>  >> > >>>>>   Not the problem of
>  >> > >>>>>> existing solutions for localized mobility, as
>  >> RFC4830 does. I don't
>  >> > >>>>>> think NetExt aims at turning PMIPv6 into a
>  >> host-based mobility
>  >> > >>>>>> protocol again.
>  >> > >>>>> => I don't know what the goal is based on the BoF discussion
>  >> > >>>>> and this discussion on the list. The reason I don't know that
>  >> > >>>>> is that no one is
>  >> > >>>>> saying:
>  >> > >>>>> Here is the state of the art (including BOTH MIP and PMIP)
>  >> > >>>>> and here is why they don't work, therefore we need to do
>  >> > >>>>> something new.
>  >> > >>>>> That's what a PS should say. What's being said here is "PMIP
>  >> > >>>>> doesn't support advanced cases therefore we need something
>  >> > >>>>> new", which is completely bogus because PMIP was not designed
>  >> > >>>>> to support those cases because we already have something else
>  >> > >>>>> for supporting those cases. Hence my reference to 4830...
>  >> > >>>>>
>  >> > >>>>> I'm going to retire from the discussion till someone makes
>  >> > >>>>> the argument above. Because I feel that if there is no such
>  >> > >>>>> argument then the discussion is not a good use of time.
>  >> > >>>>>
>  >> > >>>>>
>  >> > >>>>>>> => Yes, additional software like the existing MIP. I don't
>  >> > >>>>> understand
>  >> > >>>>>>> the motivation for creating something new. I've detailed
>  >> > >>>>> this in my
>  >> > >>>>>>> previous emails and the points remain unanswered.
>  >> > >>>>>>>
>  >> > >>>>>> Nobody talks about adding a piece of client mobility
>  >> management
>  >> > >>>>>> software, such as a MIP client, to the mobile. That
>  >> seems to be a
>  >> > >>>>>> wrong interpretation of what NetExt wants to do.
>  >> > >>>>> => You're missing the point. Why isn't anybody talking about
>  >> > >>>>> MIP??? That's what a PS should say.
>  >> > >>>>>
>  >> > >>>>> Hesham
>  >> > >>>>>
>  >> > >>>>>> marco
>  >> > >>>>>>
>  >> > >>>>>>
>  >> > >>>>>>> Hesham
>  >> > >>>>>>>
>  >> > >>>>>>>
>  >> > >>>>>>> and obviously also according to RFC4831. We should
>  >> > >>>>>>>
>  >> > >>>>>>>> distinguish modification for mobility management, which
>  >> > >>>>> is not what
>  >> > >>>>>>>> we want to do, and enabling local functions, such
>  >> as the use of
>  >> > >>>>>>>> multiple interfaces, where you have to add routes,
>  >> configure
>  >> > >>>>>>>> interfaces etc. to enable the use case.
>  >> > >>>>>>>>
>  >> > >>>>>>>> marco
>  >> > >>>>>>>>
>  >> > >>>>>>>>
>  >> > >>>>>>>> Hesham Soliman schrieb:
>  >> > >>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>>> => I think you're distinguishing between modified and
>  >> > >>>>> unmodified
>  >> > >>>>>>>>>>> based on whether the modification affects IETF
>  >> > >>>>> protocols or not.
>  >> > >>>>>>>>>>> That's fine, but for those that did not attend
>  >> the BoF, our
>  >> > >>>>>>>>>>> conclusions were that you will either end up modifying
>  >> > >>>>> the host
>  >> > >>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>  >> > >>>>>>>>>>> L2 to handle the multihoming cases, or you can
>  >> stick with MIP.
>  >> > >>>>>>>>>>> My opinion, and at least half the room's was that this
>  >> > >>>>> is not a
>  >> > >>>>>>>>>>> good way to
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>> We can discuss what implies host changes and why
>  >> this is such a
>  >> > >>>>>>>>>> big deal anyway. But I don't think that half the
>  >> room was in
>  >> > >>>>>>>>>> agreement as such. At least from the count of hands
>  >> > >>>>> raised for the
>  >> > >>>>>>>>>> question about whether we should work on multihoming
>  >> > >>>>> and intertech
>  >> > >>>>>>>>>> handovers it was about 18-9 (in favor).
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>> => I think the question changed a few times :) The final
>  >> > >>>>> question
>  >> > >>>>>>>>> (which was specific to whether people wanted to work
>  >> > >>>>> with this or
>  >> > >>>>>>>>> not) showed a split room.
>  >> > >>>>>>>>> The host changes are not a big deal but they are
>  >> mentioned here
>  >> > >>>>>>>>> because they were one of the very few reasons for using
>  >> > >>>>> NETLMM in
>  >> > >>>>>>>>> the first place: Host changes (adding new SW to
>  >> the host) and
>  >> > >>>>>>>>> signalling from the MN. You can see them in section 4 of
>  >> > >>>>> RFC 4830.
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>>> go and that it's better to stick with MIP instead of
>  >> > >>>>> relying on a
>  >> > >>>>>>>>>>> solution that will:
>  >> > >>>>>>>>>>> - work on some L2s and not others,
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>> We have no ability to specify changes to L2
>  >> anyway. However if
>  >> > >>>>>>>>>> some L2s do have such capability, why would we
>  >> not specify how
>  >> > >>>>>>>>>> multihoming would work in such scenarios.
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>> => Because we already have a solution that works
>  >> in all L2s,
>  >> > >>>>>>>>> doesn't require
>  >> > >>>>>>>>> L2 changes that we don't control and doesn't cause
>  >> > >>>>> confusing host
>  >> > >>>>>>>>> config solutions.
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>>> - Require additional SW and config on the host which
>  >> > >>>>> is not done
>  >> > >>>>>>>>>>> anywhere today, and
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>> Why is there as much of a concern about additional SW
>  >> > >>>>> or config?
>  >> > >>>>>>>>>> After all everything (or most of it anyway) that we do
>  >> > >>>>> in the IETF
>  >> > >>>>>>>>>> requires configurations, protocol changes,
>  >> changes to SW etc.
>  >> > >>>>>>>>>> There is nothing unique about this.
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>  >> > >>>>> reasons for
>  >> > >>>>>>>>> using PMIP in the first place. We can't have it both
>  >> > >>>>> ways, or can
>  >> > >>>>>>>>> we? :)
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>>> - Require L2 signalling which is out of our
>  >> scope in IETF
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>> Agree. We cannot do anything about L2s. But we
>  >> could specify
>  >> > >>>>>>>>>> (informatively)
>  >> > >>>>>>>>>> what L2 capabilities would enable these features
>  >> if that is the
>  >> > >>>>>>>>>> conclusion that we arrive at.
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>> => We can, but I don't know why we should do that when a
>  >> > >>>>> solution
>  >> > >>>>>>>>> already exists. Especially when the alternative
>  >> is inferior in
>  >> > >>>>>>>>> terms of its applicability.
>  >> > >>>>>>>>>
>  >> > >>>>>>>>> Hesham
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>> -Raj
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>
>  >> > >>>>>>>>>>> This is why I think we should stick with the charter
>  >> > >>>>> that Jari sent.
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>> Hesham
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>
>  >> > >>>>>>>>>>>> I share the same view with respect to all your other
>  >> > >>>>> comments.
>  >> > >>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>  >> > >>>>> basic handoff
>  >> > >>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>  >> mostly flow
>  >> > >>>>>>>>>>>> mobility and not the basic handoff cases supported
>  >> > >>>>> today in 5213.
>  >> > >>>>>>>>>>>> Sri
>  >> > >>>>>>>>>>>>
>  >> > >>>>>>>>>>>>
>  >> > >>>>>>>>>>>> _______________________________________________
>  >> > >>>>>>>>>>>> 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
>  >> > >>>>>>>>>
>  >> > >>>>>>>>>
>  >> > >>>>>>>
>  >> > >>>>>>>
>  >> > >>>>>>
>  >> > >>>>>
>  >> > >>>>> _______________________________________________
>  >> > >>>>> 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
>  >> > >>>
>  >> > >>> _______________________________________________
>  >> > >>> 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
>  >>
>  >
>  > _______________________________________________
>  > NetExt mailing list
>  > NetExt at mail.mobileip.jp
>  > http://www.mobileip.jp/mailman/listinfo/netext
>  >
> 

From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Thu, 9 Apr 2009 00:54:20 +0900
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Carlos.

Good to see your posts in this mailing. Anyway, the following document has
been expired would provide some scenarios for NEMO within PMIPv6 networks.

http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01

Have a good day!

2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>

> Hi Behcet,
>
> I've quickly checked the document. I think it does address the same
> problem I was referring to. This draft addresses the problem of
> delegating a prefix to a router that attaches to a PMIPv6 domain, so
> it can provide connectivity to nodes attached to it. I think this was
> already discussed in a past meeting (a draft with the problem
> statement) and I mentioned that IMHO this can basically be achieved by
> just using plain NEMO support on the router. The only difference in
> this draft is that it doesn't impose the router to be a NEMO RFC3963
> MR, although still it needs to do some additional things that a normal
> router (not mobile) doesn't. Anyway, I'm not against this type of
> support if there are scenarios in which it's useful.
>
> However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> bit beyond that, since what I want to enable is node to be able to
> benefit from network based localised mobility support not only when
> roaming between fixed points of attachment (this is what RFC5213 does
> today) but also when roaming between fixed and mobile points of
> attachment. What people do think about this scenario?
>
> Thanks,
>
> Carlos
>
> 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
>  > Hi Carlos,
> >   Check this out:
> > http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
> >
> > Regards,
> >
> > Behcet
> >
> > ________________________________
> > From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> > To: Jari Arkko <jari.arkko at piuha.net>
> > Cc: netext at mail.mobileip.jp
> > Sent: Tuesday, April 7, 2009 6:15:42 AM
> > Subject: Re: [Netext] next steps for netext
> >
> > Hi Jari, all,
> >
> > Regarding the NEMO topic, I don't know what Sri has in mind, but my
> > personal view on that is that it'd be nice to extend PMIPv6 to support
> > mobile networks. What I mean here is that it'd be nice to enable MAGs
> > to also move (like MRs, but without even supporting RFC3963), so an MR
> > would be able to move between fixed and mobile MAGs without changing
> > its IP address (same support RFC5213 gives now). There are some
> > interesting scenarios that could benefit from this.
> >
> > What do others think? It is interesting to work on this?
> >
> > Thanks,
> >
> > Carlos
> >
> > 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> Sri,
> >>
> >> Thanks for your input. Inline:
> >>
> >>> I've a concern with the planned charter. The list is too random and
> >>> cherry picked and I dont believe proper input from all the folks went
> >>> into
> >>> this. There are many other items that are required for a reasonable
> >>> deployment of Proxy Mobile IPv6. Many items were proposed over the last
> 2
> >>> years, some of them that were left out in the base spec, some that we
> >>> realized as gaps when compared to other SDO protocols and some as
> >>> optimizations that we realized while implementing PMIP6, these items
> >>> should be in the initial scope.
> >>>
> >>> I understand the charter needs to be limited in scope, but just 3 or 4
> >>> random items, I'm not sure if this helps in short term PMIP6
> >>> requirements.
> >>> I've no issue with the currently listed items, but there are other
> items
> >>> that should get equal or higher priority.
> >>
> >> I have no problem with adding more. Even the charter says new things can
> >> be
> >> added.
> >>
> >> However, from a process perspective what I did was to take the proposal
> on
> >> the table, i.e., the full BOF scope and see what parts of that we
> already
> >> have an agreement on. I didn't include other things that were not
> >> discussed
> >> in the BOF. Maybe that would have been useful, but they were not on the
> >> table.
> >>
> >> We could add more items now, if there's general agreement that those
> >> things
> >> are useful. However, I do not want to declare an open season on doing
> >> everything. We pick a reasonable subset of all proposed work, based on
> >> priorities, community agreement that they are the right things to do,
> >> management reasons to ensure that we are not doing too much, etc.
> >>
> >>> For example, item #6, is absolutely required, from the perspective of
> >>> having a complete specification of 5213. There we allowed a mobile node
> >>> to
> >>> perform handoff betweek two interfaces. We defined all the hooks on the
> >>> network side, but we did not provide how a terminal vendor can support
> >>> that. A simple informational draft on how some one move prefixes
> between
> >>> interfaces will greatly help. Some guidance on how to create a virtual
> >>> interface and also some related notes for each platform (Linux, BSD,
> >>> Android ..etc). This should not fall in the controversial discussion
> >>> scope
> >>> of same address on two interfaces etc, thats a different problem, or
> >>> about
> >>> the issue of enhancing mobile node's capabilities. This is just
> >>> informational work, required to leverage what 5213 already supports.
> >>
> >> I suspect this is about the scoping of the handoff work. Lets try to
> >> figure
> >> out what makes sense (I personally believe the above item makes sense,
> for
> >> instance) and what doesn't.
> >>
> >> The fact that these parts were not in the charter was not a declaration
> >> that
> >> we're dismissing them. Its just that we didn't finish the discussion,
> but
> >> I
> >> still wanted to let the other things move forward.
> >>
> >>> Item #2, is required. The multimob BOF raised some issues, we need to
> >>> show how multicast services can be enabled in PMIP network. May be this
> >>> wont require extensions, a simple draft covering those aspects will
> help.
> >>
> >> As you may recall, in the Multimob BOF we did not have an agreement on
> >> what
> >> exactly is needed, if anything. My own conclusion is that we probably
> need
> >> at least an informational document that explains how to use RFC 5213 for
> >> multicast. I think we discussed the possibility of doing this as some
> kind
> >> of AD sponsored document or in one of the relevant WGs, as a joint work
> >> between PMIP and multicast experts.
> >>
> >> I'm on the fence about adding this work to the charter right now, mainly
> >> because the BOF back then was very inconclusive. I'd be happier if I saw
> >> an
> >> actual well written draft from say you and some of the multicast
> experts.
> >> There's no problem moving good documents forward, even if they are not
> in
> >> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> maintenance like item for this in one of the WG charters either.
> >>
> >>> I think, the charter should be bit more relaxed and more extensive. As
> I
> >>> see it, atleast the folks are interested in doing the work. We should
> add
> >>> atleast 4 or 5 more items to this list.
> >>
> >> Generally speaking IETF WG charters give specific work items that the WG
> >> should work on. I had hoped that the charter text:
> >>
> >> "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."
> >>
> >> gives an indication that we intend to do more! I am also personally very
> >> happy to add more items to the group's charter. All in all, I do know
> that
> >> the current charter is a bit on the thin side -- mostly because the
> >> multihoming/interaccess issue is under discussion.
> >>
> >> There's also the question of general maintenance items. Some IETF WGs
> have
> >> a
> >> general work item to fix problems and issue updates to existing
> >> specifications. I think we need to do that for Proxy Mobile IPv6 as
> well.
> >> But we have not decided whether that item should go to NETLMM or NETEXT
> WG
> >> yet. Please rest assured that the work will be possible regardless of
> >> this.
> >>
> >>> 1. Dynamic LMA Assignment
> >>>
> >>> In blade architecture systems or in a load balancer configuration, the
> >>> PDNGW
> >>> should have the ability to dynamically assign a LMA on the fly, along
> the
> >>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >>> [RFC-4433].
> >>> Currently, GTP provides such semantics and this is a important
> >>> requirement
> >>> for deployment. Here the goal is to
> >>>
> >>> a.) Expose a single IP address to the SGW
> >>> b.) The exposed IP address should not be in path once the assignment is
> >>> done.
> >>>
> >>>
> >>>
> >>> [LMA1]---
> >>> | |
> >>> [LMA2]--[LMA]==========[MAG]
> >>> | |
> >>> [LMA3]---
> >>>
> >>>
> >>> Along the lines of:
> >>>
> >>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >>
> >> This is in the proposed NETEXT charter already.
> >>
> >>> 2. Multicast Support in Proxy Mobile IPv6
> >>>
> >>> We need an informational specification on how multicast support can be
> >>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >>> analysis
> >>> on
> >>> this. This is required and critical for enabling any multicast
> services.
> >>> However,
> >>> Behcet may disagree with the scope of the work.
> >>
> >> See above.
> >>
> >>> 3. Bulk Registration Support
> >>>
> >>> This is a simple extension which helps in signaling optimization, along
> >>> the
> >>> lines of:
> >>>
> >>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >>
> >> This is in the charter as well.
> >>
> >>> 4. Partial Failover Support
> >>>
> >>> We need a mechanism to notify the peer on revoke a partial set of
> >>> bindings.
> >>>
> >>>
> >>>
> >>>
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> .
> >>> txt
> >>
> >> Hmm. Ok. This needs more discussion.
> >>
> >>> 5. Group Identifier Support for Proxy Mobile IPv6
> >>>
> >>> This provides a simple and a generic semantic for assigning a group
> >>> identifier
> >>> to a mobile node's binding. GTP has very similar semantics, Connexion
> Set
> >>> Id.
> >>> Both #3 and #4 can leverage this. Additionally, in load balancer
> systems
> >>> where
> >>> the load balancer is in path for all signaling messages, it can use
> this
> >>> as
> >>> a
> >>> tag for redirecting the message.
> >>>
> >>>
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >>
> >> Since the bulk registration work is in the charter, can't you do the
> >> sensible design (whatever it is) under that? There is no requirement
> that
> >> one charter item equals one document.
> >>
> >>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >>> handoffs:
> >>>
> >>>
> >>> RFC-5213 supports handoff between two interfaces. The ability to move
> >>> prefixes between interfaces. In other words address continuity is
> assured
> >>> with any IPv6 host on the planet and with absolutely no changes. This
> >>> meets
> >>> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
> >>> not assured is the aspect of session continuity. Which requires a
> virtual
> >>> interface implementation on the host, by binding the address/prefix to
> a
> >>> virtual interface and by not exposing the physical interface or by
> hiding
> >>> the handoff events from the layer-3 stack.
> >>>
> >>> In essence, we need an informational specification which provides some
> >>> general guidance to how to leverage the feature support provided in
> >>> RFC-5213,
> >>> along the lines of:
> >>>
> >>>
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >>
> >> This is part of the discussion that we need to finish. But I plan to let
> >> the
> >> rest of the stuff move forward even before we have done that.
> >>
> >>
> >>> 7. Route Optimization for Proxy Mobile IPv6
> >>>
> >>> There were atleast 4 drafts in this area on Route Optimization. Marco
> >>> Liebsch
> >>> analyzed this exensively:
> >>>
> >>>
> >>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >>>
> >>>
> >>>
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> .
> >>> txt
> >>
> >> This is in the charter.
> >>
> >>> 8. Prefix Management in Proxy Mobile IPv6 support
> >>>
> >>> Proxy Mobile IPv6 allows the assignment of multiple home network
> prefixes
> >>> to a given mobile node's interface. It might be useful to specify how
> the
> >>> LMA manages this aspects. It can potentially use DHCP PD, Local Pools
> or
> >>> AAA to manage this aspect. Behcet has one draft on this.
> >>
> >> I'm not personally sold on this particular work. But again, this could
> be
> >> something to consider.
> >>
> >>> 9. Partial Handoff Support
> >>>
> >>> We are missing some semantics in 5213 for moving a subset of the
> prefixes
> >>> between interfaces as part of the inter-tech handoff. This is about
> >>> defining
> >>> a new handoff value. This allows partial flow management, but moving
> the
> >>> flows associated to a prefix, as a whole group.
> >>>
> >>>
> >>>
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >>
> >> A part of the topic we still need to discuss...
> >>
> >>> 10. CMIPv4/PMIP Interworking
> >>>
> >>> This is probably required to specify how an IPv4-only can move between
> >>> CMIP and PMIP environments.
> >>>
> >>>
> >>>
> >>>
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >>> meghana-netlmm-pmipv6-mipv4-00.txt
> >>
> >> Client MIPv6 and Proxy MIPv6 interoperability is already in the NETLMM
> >> charter, but this work is presumably about interaction with MIPv4. Might
> >> be
> >> useful work, I wouldn't mind if this was done in NETEXT at some point.
> Is
> >> this crucial to be in the first revision of the WG's charter?
> >>
> >>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >>
> >> Can you expand on this?
> >>
> >> Jari
> >>
> >> _______________________________________________
> >> 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
> >
> >
>
> _______________________________________________
> 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/20090409/5e6e82ee/attachment-0001.html>

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Wed, 8 Apr 2009 07:20:17 -0700 (PDT)
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Mohana,
? Pls find a little comment below.

Regards,

Behcet

________________________________

From: Mohana Jeyatharan <Mohana..Jeyatharan at sg.panasonic.com>
To: "Koodli, Rajeev" <rkoodli at starentnetworks.com>; netext at mail.mobileip.jp
Sent: Wednesday, April 8, 2009 12:41:49 AM
Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext

[behcet] Then this simple question comes to one's mind: what if MN does not have these some minor modifications to MN??you mentioned above? 
How do we interoperate these MNs?

For scenarios where MIP6 is used to handle mobility for all interfaces, then client based multihoming given as extensions of MIP6 is excellent. No one can deny this. For mixed scenarios such as PMIP and CMIP scenarios involving multiple inetrafces, then again probably MIP6 based multihoming may be ideal. This is something we need to explore as well.

But our discussion currently at Netext is, operator decides PMIPv6 for all interfaces and what solution do we have for multihoming and flow mobility? I think we should think along these lines. Is this PMIPv6 multihoming solution identical to MIP6 Multihoming solution. I don't think so. So we need to look at some drafts available that handles PMIPv6 multihoming and flow mobility and see the changes in UE and some functional modules introduced in architectural entities, to understand the differences. If same then no need of any new work. If different then need to look at benefits. Can we reduce signaling in MN-AR interface, can we make the protocol chnages of a leagcy MN minimal, can we reduce core network signaling. All such criteria need to be taken into account for comparision.

Well if the operator does not mind CMIP running over PMIP fine and good. 
But, what if not....

Thanks.
BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> Sent: Wednesday, April 08, 2009 7:46 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> 
> 
> Folks,
> 
> Let's step back a bit..It doesn't help to pit one protocol against another
> like this, especially when they are both developed by us :-)
> 
> If the problem is well-understood - i.e., how to selectively move flows
> across interfaces for MIP, the same problem is being investigated here for
> PMIP6. Why? With multiple interfaces, there seems to be interest in this
> (so-called flow mobility). How will this work? We don't know yet, we don't
> have a standards spec, but there are a few drafts.. We are only setting the
> stage for solution(s).
> 
> Given this, we should try to focus on investigating the problem and
> agreeing on how to go about working on a protocol specification. People
> already know they could use MIP6 for this. We could re-state it surely,
> but that cannot be the only approach.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> > Sent: Tuesday, April 07, 2009 3:27 PM
> > To: Vijay Devarapalli
> > Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next
> > steps for netext
> >
> >
> >
> >
> > On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >
> > > Hesham Soliman wrote:
> > >> I don't know which people you're talking about or on which planet
> > >> this stuff is being deployed.
> > >
> > > Thats easy. Search for "LTE HRPD" at google.com. :)
> > >
> > >> In any case, I'm interested in discussing technical
> > aspects of this
> > >> work and I have zero interest in politics and projections.
> > >
> > > But I don't see that. You seem to want to tell people to use Mobile
> > > IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> >
> > => I'm not *telling* people to do it, I'm arguing that this
> > is the best approach. All I'm getting back is "SDOx want
> > this" and "people want this"
> > and "the ship has sailed". It's very frustrating to have a
> > discussion like this instead of showing a real PS.
> >
> > >
> > > FWIW, the way I see it, the flow mobility solution for
> > PMIPv6 does not
> > > have to be that different from what we have for MIPv6.
> > Instead of the
> > > mobile node sending the service selection option (defined
> > in RFC 5149)
> > > and flow identification option in the BU, it?s the MAG that
> > sends this
> > > information in the PBU. The solution is the same. You tell
> > the HA or
> > > the LMA which flow filters to install.
> > >
> > > The solution could be along the lines I wrote in section 3.3 of
> > > draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > Nov 2007).
> > > It says
> >
> > => If there is a solution to be had I don't care whether it
> > uses our draft or something new. My point is that making
> > those decisions in the network just doesn't work. Yes there
> > bits on the wire that can do anything but the decision to
> > trigger these actions in the network is flawed. And without
> > getting into too much detail, before we decide to go one way
> > or another, I think a technical argument needs to be made
> > about "why" it's needed and not "how" it might work. This
> > might sound old-fashioned these days but I find it difficult
> > to rubber stamp things without understanding why.
> > This is all I'm going to say about this BoF unless someone
> > has a PS to discuss.
> >
> > Hesham
> >
> > >
> > >? ? For this scenario to work, the mobile node must be able
> > to indicate
> > >? ? to the attached MAG which flow will be sent over the
> > attachment to
> > >? ? the MAG.? It may do this by indicating the service
> > identifer during
> > >? ? the layer 2 attachment to the MAG.? The service identifier is
> > >? ? described in [4].? The MAG, in turn must include the
> > flow information
> > >? ? in the Proxy Binding Update sent to the LMA.? The MAG
> > may use the
> > >? ? Service Selection option [4] in the Proxy Binding
> > Update to indicate
> > >? ? the flow information.? The MAG may also contruct a flow
> > filter and
> > >? ? convey the information in the Proxy Binding Update.
> > See [3] for more
> > >? ? information on carrying flow filters in the proxy
> > binding update.
> > >
> > >? ? The LMA processes the Proxy Binding Update from the MAG
> > and creates a
> > >? ? filter based on the flow information.? The flow filters
> > may be stored
> > >? ? in the binding cache entry for the mobile node.
> > >
> > >? ? [3]? Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> > >? ? ? ? ? Support", draft-soliman-monami6-flow-binding-04 (work in
> > >? ? ? ? ? progress), March 2007.
> > >
> > >? ? [4]? Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > >? ? ? ? ? Selection for Mobile IPv6",
> > draft-korhonen-mip6-service-04 (work
> > >? ? ? ? ? in progress), October 2007.
> > >
> > > [4] got published as RFC 5149.
> > >
> > > Anyway, I don't think we should get into discussing
> > solutions at this
> > > point. The above is to just show that the MIPv6 solutions can be
> > > re-used for PMIPv6. We don't have to re-invent what we have
> > done in the IETF so far.
> > >
> > > I would prefer that we let the market decide whether they
> > want to go
> > > with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > or PMIPv6.
> > > that would be a political discussion. :)
> > >
> > > Vijay
> > >
> > >>
> > >> Hesham
> > >>
> > >>
> > >> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>
> > >>> George, Hesham,
> > >>>
> > >>> I don't see the point in having philosophical discussions
> > on whether
> > >>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > point. That
> > >>> ship has sailed. What we have as a reality is folks deploying
> > >>> systems with inter access technology handovers with PMIPv6 as the
> > >>> mobility management protocol. Asking these folks to now
> > use Mobile
> > >>> IPv6 does not help anyone, IMHO.
> > >>>
> > >>> Vijay
> > >>>
> > >>
> > >>
> > >
> >
> >
> >
> > _______________________________________________
> > 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

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

Hi Rajeev and All,

I like the summary you have put forward here. As you have mentioned and many others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
Currently we have a scenario where the MN MUST use PMIPv6 for mobility management for its multiple interfaces. I do not want to quote SDO, but
3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or s2b(WLAN) interface. Then if this MN wants multihoming, flow mobility etc, how can we do this? Are we going to run MIP6 ony for multihoimg purpose, on top of PMIP being used in corenetwork. Is this a good idea or are we going to do major multihoming work in MAG-LMA path and do some minor modifications to MN to keep it light weight as far as protocol modification is concerned. The second option seems more logical for pure PMIpv6 scenario. Reason is: operator may not allov two mobility manamgement protocols running just to achieve multihoming and what if the MN does not have MIP6 stack implemented. 

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090408/d166911e/attachment-0001.html>

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Wed, 8 Apr 2009 07:11:51 -0700
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Mohana,

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Mohana Jeyatharan
> Sent: Wednesday, April 08, 2009 12:36 AM
> To: Hesham Soliman; Koodli, Rajeev; netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> Hi,
> 
> What I meant is a legacy MN attaching via multiple interfaces, then the
> default mechansim is GTP/PMIP via LTE and PMIP via non-3GP. Reference TS
> 23.401, TS 23.402. This is why I mentioned must for such MNs.
> 

Uhm, this sounds at least weird to me. How can a legacy MN supports LTE? 

Based on TS 23.402, the support of PMIPv6 for inter-technology handovers and the support of DSMIPv6 are both optional in the MN/UE.

If the MN/UE does not support either PMIPv6 for inter-technology handovers or DSMIPv6, then PMIPv6 is used for basic connectivity but no IP address preservation is provided.

Gerardo

PS: Yes, 3GPP recognized about two years ago that a MN needs to support something new to support inter-system handovers with PMIPv6

> If MN has CMIP, then the 3GPP spec TS 23.402 says the MN can possibly
> negotiate a preferred mobility management mode or in some static configuration
> the network may decide on the mobility mode. In this case, ok, CMIP can be
> used if the operator allows it.
> 
> 
> So I was just focusing on the first part.
> 
> BR,
> Mohana
> 
> > -----Original Message-----
> > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > Sent: Wednesday, April 08, 2009 2:06 PM
> > To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> >
> >
> >
> >
> > On 8/04/09 4:41 PM, "Mohana Jeyatharan"
> > <Mohana.Jeyatharan at sg.panasonic.com>
> > wrote:
> >
> > > Hi Rajeev and All,
> > >
> > > I like the summary you have put forward here. As you have mentioned and
> > many
> > > others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
> > > Currently we have a scenario where the MN MUST use PMIPv6 for mobility
> > > management for its multiple interfaces. I do not want to quote SDO, but
> > > 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or
> > > s2b(WLAN) interface.
> >
> > => If you're going to say "MUST" then yes you must quote that requirement.
> > If it came from an SDO then please send us a reference to that. Other 3GPP
> > people don't agree with you and stated that publicly on the list.
> >
> > Hesham
> >
> > Then if this MN wants multihoming, flow mobility etc, how
> > > can we do this? Are we going to run MIP6 ony for multihoimg purpose, on
> > top of
> > > PMIP being used in corenetwork. Is this a good idea or are we going to
> > do
> > > major multihoming work in MAG-LMA path and do some minor modifications
> > to MN
> > > to keep it light weight as far as protocol modification is concerned.
> > The
> > > second option seems more logical for pure PMIpv6 scenario. Reason is:
> > operator
> > > may not allov two mobility manamgement protocols running just to achieve
> > > multihoming and what if the MN does not have MIP6 stack implemented.
> > >
> > > For scenarios where MIP6 is used to handle mobility for all interfaces,
> > then
> > > client based multihoming given as extensions of MIP6 is excellent. No
> > one can
> > > deny this. For mixed scenarios such as PMIP and CMIP scenarios involving
> > > multiple inetrafces, then again probably MIP6 based multihoming may be
> > ideal.
> > > This is something we need to explore as well.
> > >
> > > But our discussion currently at Netext is, operator decides PMIPv6 for
> > all
> > > interfaces and what solution do we have for multihoming and flow
> > mobility? I
> > > think we should think along these lines. Is this PMIPv6 multihoming
> > solution
> > > identical to MIP6 Multihoming solution. I don't think so. So we need to
> > look
> > > at some drafts available that handles PMIPv6 multihoming and flow
> > mobility and
> > > see the changes in UE and some functional modules introduced in
> > architectural
> > > entities, to understand the differences. If same then no need of any new
> > work.
> > > If different then need to look at benefits. Can we reduce signaling in
> > MN-AR
> > > interface, can we make the protocol chnages of a leagcy MN minimal, can
> > we
> > > reduce core network signaling. All such criteria need to be taken into
> > account
> > > for comparision.
> > >
> > > Well if the operator does not mind CMIP running over PMIP fine and good.
> > > But, what if not....
> > >
> > > Thanks.
> > > BR,
> > > Mohana
> > >
> > >> -----Original Message-----
> > >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> > >> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> > >> Sent: Wednesday, April 08, 2009 7:46 AM
> > >> To: netext at mail.mobileip.jp
> > >> Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> > netext
> > >>
> > >>
> > >>
> > >> Folks,
> > >>
> > >> Let's step back a bit..It doesn't help to pit one protocol against
> > another
> > >> like this, especially when they are both developed by us :-)
> > >>
> > >> If the problem is well-understood - i.e., how to selectively move flows
> > >> across interfaces for MIP, the same problem is being investigated here
> > for
> > >> PMIP6. Why? With multiple interfaces, there seems to be interest in
> > this
> > >> (so-called flow mobility). How will this work? We don't know yet, we
> > don't
> > >> have a standards spec, but there are a few drafts. We are only setting
> > the
> > >> stage for solution(s).
> > >>
> > >> Given this, we should try to focus on investigating the problem and
> > >> agreeing on how to go about working on a protocol specification. People
> > >> already know they could use MIP6 for this. We could re-state it surely,
> > >> but that cannot be the only approach.
> > >>
> > >> Thanks,
> > >>
> > >> -Rajeev
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: netext-bounces at mail.mobileip.jp
> > >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> > >>> Sent: Tuesday, April 07, 2009 3:27 PM
> > >>> To: Vijay Devarapalli
> > >>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > >>> Subject: Re: [Netext] Keep missing the point .. Re: next
> > >>> steps for netext
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>>
> > >>>> Hesham Soliman wrote:
> > >>>>> I don't know which people you're talking about or on which planet
> > >>>>> this stuff is being deployed.
> > >>>>
> > >>>> Thats easy. Search for "LTE HRPD" at google.com. :)
> > >>>>
> > >>>>> In any case, I'm interested in discussing technical
> > >>> aspects of this
> > >>>>> work and I have zero interest in politics and projections.
> > >>>>
> > >>>> But I don't see that. You seem to want to tell people to use Mobile
> > >>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> > >>>
> > >>> => I'm not *telling* people to do it, I'm arguing that this
> > >>> is the best approach. All I'm getting back is "SDOx want
> > >>> this" and "people want this"
> > >>> and "the ship has sailed". It's very frustrating to have a
> > >>> discussion like this instead of showing a real PS.
> > >>>
> > >>>>
> > >>>> FWIW, the way I see it, the flow mobility solution for
> > >>> PMIPv6 does not
> > >>>> have to be that different from what we have for MIPv6.
> > >>> Instead of the
> > >>>> mobile node sending the service selection option (defined
> > >>> in RFC 5149)
> > >>>> and flow identification option in the BU, it?s the MAG that
> > >>> sends this
> > >>>> information in the PBU. The solution is the same. You tell
> > >>> the HA or
> > >>>> the LMA which flow filters to install.
> > >>>>
> > >>>> The solution could be along the lines I wrote in section 3.3 of
> > >>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > >>> Nov 2007).
> > >>>> It says
> > >>>
> > >>> => If there is a solution to be had I don't care whether it
> > >>> uses our draft or something new. My point is that making
> > >>> those decisions in the network just doesn't work. Yes there
> > >>> bits on the wire that can do anything but the decision to
> > >>> trigger these actions in the network is flawed. And without
> > >>> getting into too much detail, before we decide to go one way
> > >>> or another, I think a technical argument needs to be made
> > >>> about "why" it's needed and not "how" it might work. This
> > >>> might sound old-fashioned these days but I find it difficult
> > >>> to rubber stamp things without understanding why.
> > >>> This is all I'm going to say about this BoF unless someone
> > >>> has a PS to discuss.
> > >>>
> > >>> Hesham
> > >>>
> > >>>>
> > >>>>     For this scenario to work, the mobile node must be able
> > >>> to indicate
> > >>>>     to the attached MAG which flow will be sent over the
> > >>> attachment to
> > >>>>     the MAG.  It may do this by indicating the service
> > >>> identifer during
> > >>>>     the layer 2 attachment to the MAG.  The service identifier is
> > >>>>     described in [4].  The MAG, in turn must include the
> > >>> flow information
> > >>>>     in the Proxy Binding Update sent to the LMA.  The MAG
> > >>> may use the
> > >>>>     Service Selection option [4] in the Proxy Binding
> > >>> Update to indicate
> > >>>>     the flow information.  The MAG may also contruct a flow
> > >>> filter and
> > >>>>     convey the information in the Proxy Binding Update.
> > >>> See [3] for more
> > >>>>     information on carrying flow filters in the proxy
> > >>> binding update.
> > >>>>
> > >>>>     The LMA processes the Proxy Binding Update from the MAG
> > >>> and creates a
> > >>>>     filter based on the flow information.  The flow filters
> > >>> may be stored
> > >>>>     in the binding cache entry for the mobile node.
> > >>>>
> > >>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> > >>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
> > >>>>          progress), March 2007.
> > >>>>
> > >>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > >>>>          Selection for Mobile IPv6",
> > >>> draft-korhonen-mip6-service-04 (work
> > >>>>          in progress), October 2007.
> > >>>>
> > >>>> [4] got published as RFC 5149.
> > >>>>
> > >>>> Anyway, I don't think we should get into discussing
> > >>> solutions at this
> > >>>> point. The above is to just show that the MIPv6 solutions can be
> > >>>> re-used for PMIPv6. We don't have to re-invent what we have
> > >>> done in the IETF so far.
> > >>>>
> > >>>> I would prefer that we let the market decide whether they
> > >>> want to go
> > >>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > >>> or PMIPv6.
> > >>>> that would be a political discussion. :)
> > >>>>
> > >>>> Vijay
> > >>>>
> > >>>>>
> > >>>>> Hesham
> > >>>>>
> > >>>>>
> > >>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>>>>
> > >>>>>> George, Hesham,
> > >>>>>>
> > >>>>>> I don't see the point in having philosophical discussions
> > >>> on whether
> > >>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > >>> point. That
> > >>>>>> ship has sailed. What we have as a reality is folks deploying
> > >>>>>> systems with inter access technology handovers with PMIPv6 as the
> > >>>>>> mobility management protocol. Asking these folks to now
> > >>> use Mobile
> > >>>>>> IPv6 does not help anyone, IMHO.
> > >>>>>>
> > >>>>>> Vijay
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >
> > > _______________________________________________
> > > 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

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Wed, 8 Apr 2009 11:45:16 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

> On the WiMAX side, I know there are still open issues 
> (discussed at the last 3GPP SA2 meeting) to make a handover 
> between 3GPP and WiMAX with PMIPv6 working.

Yes, this is an issue. PMIPv6 is the only specified method for LTE-WiMAX
handover. PMIPv6 doesn't work in this particular case because WiMAX doesn't
have the L2 extensions in support of PMIPv6.

> 
> > Such
> > large scale managed networks are the main consumers of PMIP6 so we 
> > shouldn't be ignoring what they're doing.
> 
> This is mainly true for intra-technology mobility - and note 
> that I am considering LTE-eHRPD intra-technology here as they 
> are homogeneous from a link layer point of view.

I consider the WiMAX-LTE handover as inter-system handover. My preference is
to look into solving the PMIPv6 handover issues in a generic and access
independent way so that we have a solution for link layers which don't
provide PMIPv6 enhancements.

domagoj

> -----Original Message-----
> From: ext Giaretta, Gerardo [mailto:gerardog at qualcomm.com] 
> Sent: 07. travanj 2009 17:34
> To: Domagoj Premec; 'ext Hesham Soliman'; 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: RE: [Netext] next steps for netext
> 
> Hi Domagoj,
> 
> A couple of clarifications below.
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp]
> > On Behalf Of Domagoj Premec
> > Sent: Tuesday, April 07, 2009 3:56 AM
> > To: 'ext Hesham Soliman'; 'Marco Liebsch'
> > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > Subject: Re: [Netext] next steps for netext
> > 
> > Hi Hesham, all,
> > 
> > > What's being said here is "PMIP
> > > doesn't support advanced cases therefore we need something new", 
> > > which is completely bogus because PMIP was not designed 
> to support 
> > > those cases because we already have something else for supporting 
> > > those cases. Hence my reference to 4830...
> > >
> > 
> > Both 3GPP and WiMAX adopted PMIP6 as means for inter-access 
> handover. 
> 
> 3GPP allows both PMIPv6 and DSMIPv6 for inter-access 
> handover. PMIPv6 is used for LTE-eHRPD handovers and 3GPP2 
> designed a new link layer for eHRPD exactly because that was 
> needed for PMIPv6. For example 3G-WLAN inter-system handover 
> is only specified for DSMIPv6 in 3GPP. So let's be clear and 
> stop claiming 3GPP needs PMIPv6 extensions.
> 
> On the WiMAX side, I know there are still open issues 
> (discussed at the last 3GPP SA2 meeting) to make a handover 
> between 3GPP and WiMAX with PMIPv6 working.
> 
> > Such
> > large scale managed networks are the main consumers of PMIP6 so we 
> > shouldn't be ignoring what they're doing.
> 
> This is mainly true for intra-technology mobility - and note 
> that I am considering LTE-eHRPD intra-technology here as they 
> are homogeneous from a link layer point of view.
> 
> Gerardo
> 
> > Saying to use MIP for inter-access
> > handovers/multihoming is not helping as they have really set their 
> > mind on using PMIP6 and they're already doing this. Without 
> going into 
> > the reasoning behind such a decision, the fact is that PMIP6, as 
> > defined in RFC 5213, has issues with inter-access 
> handovers. I think 
> > it is better to fix those PMIP6 issues in the IETF then to let each 
> > SDO come up with their own way of dealing with this.
> > 
> > domagoj
> > 
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Hesham 
> > > Soliman
> > > Sent: 07. travanj 2009 11:14
> > > To: Marco Liebsch
> > > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > Subject: Re: [Netext] next steps for netext
> > >
> > >
> > > >> => We're discussing a problem statement for the BoF, so
> > > 4830 is quite
> > > >> appropriate as a reference for why people wanted PMIP in
> > > the first place.
> > > >>
> > > > Yes, a problem statement about an existing solution for
> > > network-based
> > > > mobility management (PMIPv6) to support advanced use cases.
> > >
> > > => Where is that PS?
> > >
> > >   Not the problem of
> > > > existing solutions for localized mobility, as RFC4830 does. I 
> > > > don't think NetExt aims at turning PMIPv6 into a host-based 
> > > > mobility protocol again.
> > >
> > > => I don't know what the goal is based on the BoF discussion and 
> > > this discussion on the list. The reason I don't know that 
> is that no 
> > > one is
> > > saying:
> > > Here is the state of the art (including BOTH MIP and 
> PMIP) and here 
> > > is why they don't work, therefore we need to do something new.
> > > That's what a PS should say. What's being said here is 
> "PMIP doesn't 
> > > support advanced cases therefore we need something new", which is 
> > > completely bogus because PMIP was not designed to support those 
> > > cases because we already have something else for supporting those 
> > > cases. Hence my reference to 4830...
> > >
> > > I'm going to retire from the discussion till someone makes the 
> > > argument above. Because I feel that if there is no such argument 
> > > then the discussion is not a good use of time.
> > >
> > >
> > > >> => Yes, additional software like the existing MIP. I don't
> > > understand
> > > >> the motivation for creating something new. I've detailed
> > > this in my
> > > >> previous emails and the points remain unanswered.
> > > >>
> > > > Nobody talks about adding a piece of client mobility management 
> > > > software, such as a MIP client, to the mobile. That 
> seems to be a 
> > > > wrong interpretation of what NetExt wants to do.
> > >
> > > => You're missing the point. Why isn't anybody talking 
> about MIP??? 
> > > That's what a PS should say.
> > >
> > > Hesham
> > >
> > > >
> > > > marco
> > > >
> > > >
> > > >> Hesham
> > > >>
> > > >>
> > > >> and obviously also according to RFC4831. We should
> > > >>
> > > >>> distinguish modification for mobility management, which
> > > is not what
> > > >>> we want to do, and enabling local functions, such as 
> the use of 
> > > >>> multiple interfaces, where you have to add routes, configure 
> > > >>> interfaces etc. to enable the use case.
> > > >>>
> > > >>> marco
> > > >>>
> > > >>>
> > > >>> Hesham Soliman schrieb:
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>>> => I think you're distinguishing between modified and
> > > unmodified
> > > >>>>>> based on whether the modification affects IETF
> > > protocols or not.
> > > >>>>>> That's fine, but for those that did not attend the 
> BoF, our 
> > > >>>>>> conclusions were that you will either end up modifying
> > > the host
> > > >>>>>> (i.e. Adding new SW) and adding new signalling on
> > > >>>>>> L2 to handle the multihoming cases, or you can 
> stick with MIP.
> > > >>>>>> My opinion, and at least half the room's was that this
> > > is not a
> > > >>>>>> good way to
> > > >>>>>>
> > > >>>>>>
> > > >>>>> We can discuss what implies host changes and why 
> this is such 
> > > >>>>> a big deal anyway. But I don't think that half the 
> room was in 
> > > >>>>> agreement as such. At least from the count of hands
> > > raised for the
> > > >>>>> question about whether we should work on multihoming
> > > and intertech
> > > >>>>> handovers it was about 18-9 (in favor).
> > > >>>>>
> > > >>>>>
> > > >>>> => I think the question changed a few times :) The final
> > > question
> > > >>>> (which was specific to whether people wanted to work
> > > with this or
> > > >>>> not) showed a split room.
> > > >>>> The host changes are not a big deal but they are 
> mentioned here 
> > > >>>> because they were one of the very few reasons for using
> > > NETLMM in
> > > >>>> the first place: Host changes (adding new SW to the 
> host) and 
> > > >>>> signalling from the MN. You can see them in section 4 of
> > > RFC 4830.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>> go and that it's better to stick with MIP instead of
> > > relying on a
> > > >>>>>> solution that will:
> > > >>>>>> - work on some L2s and not others,
> > > >>>>>>
> > > >>>>>>
> > > >>>>> We have no ability to specify changes to L2 anyway. 
> However if 
> > > >>>>> some L2s do have such capability, why would we not 
> specify how 
> > > >>>>> multihoming would work in such scenarios.
> > > >>>>>
> > > >>>>>
> > > >>>> => Because we already have a solution that works in all L2s, 
> > > >>>> doesn't require
> > > >>>> L2 changes that we don't control and doesn't cause
> > > confusing host
> > > >>>> config solutions.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>> - Require additional SW and config on the host which
> > > is not done
> > > >>>>>> anywhere today, and
> > > >>>>>>
> > > >>>>>>
> > > >>>>> Why is there as much of a concern about additional SW
> > > or config?
> > > >>>>> After all everything (or most of it anyway) that we do
> > > in the IETF
> > > >>>>> requires configurations, protocol changes, changes 
> to SW etc.
> > > >>>>> There is nothing unique about this.
> > > >>>>>
> > > >>>>>
> > > >>>> => Sure, but see above and see RFC 4830. These were the
> > > reasons for
> > > >>>> using PMIP in the first place. We can't have it both
> > > ways, or can
> > > >>>> we? :)
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>> - Require L2 signalling which is out of our scope in IETF
> > > >>>>>>
> > > >>>>>>
> > > >>>>> Agree. We cannot do anything about L2s. But we could specify
> > > >>>>> (informatively)
> > > >>>>> what L2 capabilities would enable these features if that is 
> > > >>>>> the conclusion that we arrive at.
> > > >>>>>
> > > >>>>>
> > > >>>> => We can, but I don't know why we should do that when a
> > > solution
> > > >>>> already exists. Especially when the alternative is 
> inferior in 
> > > >>>> terms of its applicability.
> > > >>>>
> > > >>>> Hesham
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> -Raj
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> This is why I think we should stick with the charter
> > > that Jari sent.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Hesham
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> I share the same view with respect to all your other
> > > comments.
> > > >>>>>>> We need to seperate the cases of flow mobility vs
> > > basic handoff
> > > >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow 
> > > >>>>>>> mobility and not the basic handoff cases supported
> > > today in 5213.
> > > >>>>>>>
> > > >>>>>>> Sri
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> _______________________________________________
> > > >>>>>>> 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
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > 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
> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Wed, 8 Apr 2009 09:55:36 +0100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Apr 8, 2009 at 12:17 AM, Vijay Devarapalli <vijay at wichorus.com> wrote:
> Hi Gerardo,
>
>> 3GPP has a study item on this feature. There was no PMIPv6
>> solutions proposed on any I-D - there is a 3GPP-specific
>> solution proposed for PMIPv6 (based on the policy infrastructure).
>
> This is exactly what I would like to avoid. I would prefer using a
> solution developed in the IETF rather than something in 3GPP.
>

GT> Why not? 3GPP and other SDOs have been creating technology for
almost as long as the IETF. Getting the IETF to do something only
makes sense if the given protocol has general applicability and does
not damage the Internet, which is why we are having this discussion.

GT> In another e-mail where you are over-viewing a possible solution
to PMIP multihoming you talk about how the MN may use an L2 to signal
to indicate what flows need to go to a given MAG. I do not see how the
IETF can define a protocol that fully depends on such an L2 signal. If
such functionality is needed then the IETF must define it at the IP
layer to make sure that this works across ALL link layers (which is
the main reason the IETF and the Internet exist).

GT> So, in my book you (pmip mhoming fans) have two hurdles to overcome:
1) Admit to yourself that to do this in the IETF you need to define an
MN-MAG protocol at the IP layer (e.g., see Conny's draft)
2) Convince people that defining such a client based protocol in
addition to the existing standard (MIPv6) is warranted. In the
process, explain to people why you want to introduce FA functionality
to MIPv6, which is what MAGs become if you add an MN-MAG leg to PMIP's
MAG-HA leg.

George

> Vijay
>
>> 3GPP has not decided yet to do any normative work on any of
>> the solutions.
>>
>> Gerardo
>>
>> > -----Original Message-----
>> > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>> > Sent: Tuesday, April 07, 2009 2:52 PM
>> > To: Giaretta, Gerardo
>> > Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
>> > Basavaraj.Patil at nokia.com
>> > Subject: Re: [Netext] next steps for netext
>> >
>> >
>> > >
>> > > I will now stop discussing 3GPP specific issues in this
>> list, sorry for that
>> > > :-)
>> >
>> > => Please continue to tell us whether 3GPP needs certain
>> function though.
>> > Based on your last email, I don't understand what is the
>> basis for the
>> > claims of 3GPP needing this function. Seems like a baseless
>> claim not backed
>> > by 3GPP.
>> >
>> > Hesham
>> >
>> >
>> > >
>> > > Gerardo
>> > >
>> > >
>> > >
>> > >> Vijay
>> > >>
>> > >>> On the WiMAX side, I know there are still open issues
>> (discussed at the
>> > last
>> > >> 3GPP SA2 meeting) to make a handover between 3GPP and
>> WiMAX with PMIPv6
>> > >> working.
>> > >>>
>> > >>>> Such
>> > >>>> large scale managed networks are the main consumers of
>> PMIP6 so we
>> > >> shouldn't
>> > >>>> be ignoring what they're doing.
>> > >>>
>> > >>> This is mainly true for intra-technology mobility - and
>> note that I am
>> > >> considering LTE-eHRPD intra-technology here as they are
>> homogeneous from a
>> > >> link layer point of view.
>> > >>>
>> > >>> Gerardo
>> > >>>
>> > >>>> Saying to use MIP for inter-access
>> > >>>> handovers/multihoming is not helping as they have
>> really set their mind
>> > on
>> > >>>> using PMIP6 and they're already doing this. Without
>> going into the
>> > >> reasoning
>> > >>>> behind such a decision, the fact is that PMIP6, as
>> defined in RFC 5213,
>> > has
>> > >>>> issues with inter-access handovers. I think it is
>> better to fix those
>> > PMIP6
>> > >>>> issues in the IETF then to let each SDO come up with
>> their own way of
>> > >>>> dealing with this.
>> > >>>>
>> > >>>> domagoj
>> > >>>>
>> > >>>>
>> > >>>>> -----Original Message-----
>> > >>>>> From: netext-bounces at mail.mobileip.jp
>> > >>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>> > >>>>> Hesham Soliman
>> > >>>>> Sent: 07. travanj 2009 11:14
>> > >>>>> To: Marco Liebsch
>> > >>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> > >>>>> Subject: Re: [Netext] next steps for netext
>> > >>>>>
>> > >>>>>
>> > >>>>>>> => We're discussing a problem statement for the BoF, so
>> > >>>>> 4830 is quite
>> > >>>>>>> appropriate as a reference for why people wanted PMIP in
>> > >>>>> the first place.
>> > >>>>>> Yes, a problem statement about an existing solution for
>> > >>>>> network-based
>> > >>>>>> mobility management (PMIPv6) to support advanced use cases.
>> > >>>>> => Where is that PS?
>> > >>>>>
>> > >>>>> ? Not the problem of
>> > >>>>>> existing solutions for localized mobility, as
>> RFC4830 does. I don't
>> > >>>>>> think NetExt aims at turning PMIPv6 into a
>> host-based mobility
>> > >>>>>> protocol again.
>> > >>>>> => I don't know what the goal is based on the BoF discussion
>> > >>>>> and this discussion on the list. The reason I don't know that
>> > >>>>> is that no one is
>> > >>>>> saying:
>> > >>>>> Here is the state of the art (including BOTH MIP and PMIP)
>> > >>>>> and here is why they don't work, therefore we need to do
>> > >>>>> something new.
>> > >>>>> That's what a PS should say. What's being said here is "PMIP
>> > >>>>> doesn't support advanced cases therefore we need something
>> > >>>>> new", which is completely bogus because PMIP was not designed
>> > >>>>> to support those cases because we already have something else
>> > >>>>> for supporting those cases. Hence my reference to 4830...
>> > >>>>>
>> > >>>>> I'm going to retire from the discussion till someone makes
>> > >>>>> the argument above. Because I feel that if there is no such
>> > >>>>> argument then the discussion is not a good use of time.
>> > >>>>>
>> > >>>>>
>> > >>>>>>> => Yes, additional software like the existing MIP. I don't
>> > >>>>> understand
>> > >>>>>>> the motivation for creating something new. I've detailed
>> > >>>>> this in my
>> > >>>>>>> previous emails and the points remain unanswered.
>> > >>>>>>>
>> > >>>>>> Nobody talks about adding a piece of client mobility
>> management
>> > >>>>>> software, such as a MIP client, to the mobile. That
>> seems to be a
>> > >>>>>> wrong interpretation of what NetExt wants to do.
>> > >>>>> => You're missing the point. Why isn't anybody talking about
>> > >>>>> MIP??? That's what a PS should say.
>> > >>>>>
>> > >>>>> Hesham
>> > >>>>>
>> > >>>>>> marco
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>> Hesham
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> and obviously also according to RFC4831. We should
>> > >>>>>>>
>> > >>>>>>>> distinguish modification for mobility management, which
>> > >>>>> is not what
>> > >>>>>>>> we want to do, and enabling local functions, such
>> as the use of
>> > >>>>>>>> multiple interfaces, where you have to add routes,
>> configure
>> > >>>>>>>> interfaces etc. to enable the use case.
>> > >>>>>>>>
>> > >>>>>>>> marco
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> Hesham Soliman schrieb:
>> > >>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>> => I think you're distinguishing between modified and
>> > >>>>> unmodified
>> > >>>>>>>>>>> based on whether the modification affects IETF
>> > >>>>> protocols or not.
>> > >>>>>>>>>>> That's fine, but for those that did not attend
>> the BoF, our
>> > >>>>>>>>>>> conclusions were that you will either end up modifying
>> > >>>>> the host
>> > >>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>> > >>>>>>>>>>> L2 to handle the multihoming cases, or you can
>> stick with MIP.
>> > >>>>>>>>>>> My opinion, and at least half the room's was that this
>> > >>>>> is not a
>> > >>>>>>>>>>> good way to
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>> We can discuss what implies host changes and why
>> this is such a
>> > >>>>>>>>>> big deal anyway. But I don't think that half the
>> room was in
>> > >>>>>>>>>> agreement as such. At least from the count of hands
>> > >>>>> raised for the
>> > >>>>>>>>>> question about whether we should work on multihoming
>> > >>>>> and intertech
>> > >>>>>>>>>> handovers it was about 18-9 (in favor).
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>> => I think the question changed a few times :) The final
>> > >>>>> question
>> > >>>>>>>>> (which was specific to whether people wanted to work
>> > >>>>> with this or
>> > >>>>>>>>> not) showed a split room.
>> > >>>>>>>>> The host changes are not a big deal but they are
>> mentioned here
>> > >>>>>>>>> because they were one of the very few reasons for using
>> > >>>>> NETLMM in
>> > >>>>>>>>> the first place: Host changes (adding new SW to
>> the host) and
>> > >>>>>>>>> signalling from the MN. You can see them in section 4 of
>> > >>>>> RFC 4830.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>> go and that it's better to stick with MIP instead of
>> > >>>>> relying on a
>> > >>>>>>>>>>> solution that will:
>> > >>>>>>>>>>> - work on some L2s and not others,
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>> We have no ability to specify changes to L2
>> anyway. However if
>> > >>>>>>>>>> some L2s do have such capability, why would we
>> not specify how
>> > >>>>>>>>>> multihoming would work in such scenarios.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>> => Because we already have a solution that works
>> in all L2s,
>> > >>>>>>>>> doesn't require
>> > >>>>>>>>> L2 changes that we don't control and doesn't cause
>> > >>>>> confusing host
>> > >>>>>>>>> config solutions.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>> - Require additional SW and config on the host which
>> > >>>>> is not done
>> > >>>>>>>>>>> anywhere today, and
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>> Why is there as much of a concern about additional SW
>> > >>>>> or config?
>> > >>>>>>>>>> After all everything (or most of it anyway) that we do
>> > >>>>> in the IETF
>> > >>>>>>>>>> requires configurations, protocol changes,
>> changes to SW etc.
>> > >>>>>>>>>> There is nothing unique about this.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>> > >>>>> reasons for
>> > >>>>>>>>> using PMIP in the first place. We can't have it both
>> > >>>>> ways, or can
>> > >>>>>>>>> we? :)
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>> - Require L2 signalling which is out of our
>> scope in IETF
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>> Agree. We cannot do anything about L2s. But we
>> could specify
>> > >>>>>>>>>> (informatively)
>> > >>>>>>>>>> what L2 capabilities would enable these features
>> if that is the
>> > >>>>>>>>>> conclusion that we arrive at.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>> => We can, but I don't know why we should do that when a
>> > >>>>> solution
>> > >>>>>>>>> already exists. Especially when the alternative
>> is inferior in
>> > >>>>>>>>> terms of its applicability.
>> > >>>>>>>>>
>> > >>>>>>>>> Hesham
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>> -Raj
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> This is why I think we should stick with the charter
>> > >>>>> that Jari sent.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Hesham
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> I share the same view with respect to all your other
>> > >>>>> comments.
>> > >>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>> > >>>>> basic handoff
>> > >>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed
>> mostly flow
>> > >>>>>>>>>>>> mobility and not the basic handoff cases supported
>> > >>>>> today in 5213.
>> > >>>>>>>>>>>> Sri
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> _______________________________________________
>> > >>>>>>>>>>>> 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
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>> _______________________________________________
>> > >>>>> 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
>> > >>>
>> > >>> _______________________________________________
>> > >>> 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
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: uchida at sfc.wide.ad.jp (Yogo Uchida)
Date: Wed, 8 Apr 2009 17:33:27 +0900
Subject: [Netext] (no subject)
Message-ID: <5FD8F2CC0B1F40C9ADE64223F55F21D6@yogoPC>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090408/206158a6/attachment.html>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Wed, 8 Apr 2009 15:36:22 +0800
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

What I meant is a legacy MN attaching via multiple interfaces, then the default mechansim is GTP/PMIP via LTE and PMIP via non-3GP. Reference TS 23.401, TS 23.402. This is why I mentioned must for such MNs. 

If MN has CMIP, then the 3GPP spec TS 23.402 says the MN can possibly negotiate a preferred mobility management mode or in some static configuration the network may decide on the mobility mode. In this case, ok, CMIP can be used if the operator allows it.

So I was just focusing on the first part.

BR,
Mohana

> -----Original Message-----
> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Sent: Wednesday, April 08, 2009 2:06 PM
> To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> 
> 
> 
> On 8/04/09 4:41 PM, "Mohana Jeyatharan"
> <Mohana.Jeyatharan at sg.panasonic.com>
> wrote:
> 
> > Hi Rajeev and All,
> >
> > I like the summary you have put forward here. As you have mentioned and
> many
> > others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
> > Currently we have a scenario where the MN MUST use PMIPv6 for mobility
> > management for its multiple interfaces. I do not want to quote SDO, but
> > 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or
> > s2b(WLAN) interface.
> 
> => If you're going to say "MUST" then yes you must quote that requirement.
> If it came from an SDO then please send us a reference to that. Other 3GPP
> people don't agree with you and stated that publicly on the list.
> 
> Hesham
> 
> Then if this MN wants multihoming, flow mobility etc, how
> > can we do this? Are we going to run MIP6 ony for multihoimg purpose, on
> top of
> > PMIP being used in corenetwork. Is this a good idea or are we going to
> do
> > major multihoming work in MAG-LMA path and do some minor modifications
> to MN
> > to keep it light weight as far as protocol modification is concerned.
> The
> > second option seems more logical for pure PMIpv6 scenario. Reason is:
> operator
> > may not allov two mobility manamgement protocols running just to achieve
> > multihoming and what if the MN does not have MIP6 stack implemented.
> >
> > For scenarios where MIP6 is used to handle mobility for all interfaces,
> then
> > client based multihoming given as extensions of MIP6 is excellent. No
> one can
> > deny this. For mixed scenarios such as PMIP and CMIP scenarios involving
> > multiple inetrafces, then again probably MIP6 based multihoming may be
> ideal.
> > This is something we need to explore as well.
> >
> > But our discussion currently at Netext is, operator decides PMIPv6 for
> all
> > interfaces and what solution do we have for multihoming and flow
> mobility? I
> > think we should think along these lines. Is this PMIPv6 multihoming
> solution
> > identical to MIP6 Multihoming solution. I don't think so. So we need to
> look
> > at some drafts available that handles PMIPv6 multihoming and flow
> mobility and
> > see the changes in UE and some functional modules introduced in
> architectural
> > entities, to understand the differences. If same then no need of any new
> work.
> > If different then need to look at benefits. Can we reduce signaling in
> MN-AR
> > interface, can we make the protocol chnages of a leagcy MN minimal, can
> we
> > reduce core network signaling. All such criteria need to be taken into
> account
> > for comparision.
> >
> > Well if the operator does not mind CMIP running over PMIP fine and good.
> > But, what if not....
> >
> > Thanks.
> > BR,
> > Mohana
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> >> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> >> Sent: Wednesday, April 08, 2009 7:46 AM
> >> To: netext at mail.mobileip.jp
> >> Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> netext
> >>
> >>
> >>
> >> Folks,
> >>
> >> Let's step back a bit..It doesn't help to pit one protocol against
> another
> >> like this, especially when they are both developed by us :-)
> >>
> >> If the problem is well-understood - i.e., how to selectively move flows
> >> across interfaces for MIP, the same problem is being investigated here
> for
> >> PMIP6. Why? With multiple interfaces, there seems to be interest in
> this
> >> (so-called flow mobility). How will this work? We don't know yet, we
> don't
> >> have a standards spec, but there are a few drafts. We are only setting
> the
> >> stage for solution(s).
> >>
> >> Given this, we should try to focus on investigating the problem and
> >> agreeing on how to go about working on a protocol specification. People
> >> already know they could use MIP6 for this. We could re-state it surely,
> >> but that cannot be the only approach.
> >>
> >> Thanks,
> >>
> >> -Rajeev
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: netext-bounces at mail.mobileip.jp
> >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> >>> Sent: Tuesday, April 07, 2009 3:27 PM
> >>> To: Vijay Devarapalli
> >>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> >>> Subject: Re: [Netext] Keep missing the point .. Re: next
> >>> steps for netext
> >>>
> >>>
> >>>
> >>>
> >>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >>>
> >>>> Hesham Soliman wrote:
> >>>>> I don't know which people you're talking about or on which planet
> >>>>> this stuff is being deployed.
> >>>>
> >>>> Thats easy. Search for "LTE HRPD" at google.com. :)
> >>>>
> >>>>> In any case, I'm interested in discussing technical
> >>> aspects of this
> >>>>> work and I have zero interest in politics and projections.
> >>>>
> >>>> But I don't see that. You seem to want to tell people to use Mobile
> >>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> >>>
> >>> => I'm not *telling* people to do it, I'm arguing that this
> >>> is the best approach. All I'm getting back is "SDOx want
> >>> this" and "people want this"
> >>> and "the ship has sailed". It's very frustrating to have a
> >>> discussion like this instead of showing a real PS.
> >>>
> >>>>
> >>>> FWIW, the way I see it, the flow mobility solution for
> >>> PMIPv6 does not
> >>>> have to be that different from what we have for MIPv6.
> >>> Instead of the
> >>>> mobile node sending the service selection option (defined
> >>> in RFC 5149)
> >>>> and flow identification option in the BU, it?s the MAG that
> >>> sends this
> >>>> information in the PBU. The solution is the same. You tell
> >>> the HA or
> >>>> the LMA which flow filters to install.
> >>>>
> >>>> The solution could be along the lines I wrote in section 3.3 of
> >>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> >>> Nov 2007).
> >>>> It says
> >>>
> >>> => If there is a solution to be had I don't care whether it
> >>> uses our draft or something new. My point is that making
> >>> those decisions in the network just doesn't work. Yes there
> >>> bits on the wire that can do anything but the decision to
> >>> trigger these actions in the network is flawed. And without
> >>> getting into too much detail, before we decide to go one way
> >>> or another, I think a technical argument needs to be made
> >>> about "why" it's needed and not "how" it might work. This
> >>> might sound old-fashioned these days but I find it difficult
> >>> to rubber stamp things without understanding why.
> >>> This is all I'm going to say about this BoF unless someone
> >>> has a PS to discuss.
> >>>
> >>> Hesham
> >>>
> >>>>
> >>>>     For this scenario to work, the mobile node must be able
> >>> to indicate
> >>>>     to the attached MAG which flow will be sent over the
> >>> attachment to
> >>>>     the MAG.  It may do this by indicating the service
> >>> identifer during
> >>>>     the layer 2 attachment to the MAG.  The service identifier is
> >>>>     described in [4].  The MAG, in turn must include the
> >>> flow information
> >>>>     in the Proxy Binding Update sent to the LMA.  The MAG
> >>> may use the
> >>>>     Service Selection option [4] in the Proxy Binding
> >>> Update to indicate
> >>>>     the flow information.  The MAG may also contruct a flow
> >>> filter and
> >>>>     convey the information in the Proxy Binding Update.
> >>> See [3] for more
> >>>>     information on carrying flow filters in the proxy
> >>> binding update.
> >>>>
> >>>>     The LMA processes the Proxy Binding Update from the MAG
> >>> and creates a
> >>>>     filter based on the flow information.  The flow filters
> >>> may be stored
> >>>>     in the binding cache entry for the mobile node.
> >>>>
> >>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> >>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
> >>>>          progress), March 2007.
> >>>>
> >>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> >>>>          Selection for Mobile IPv6",
> >>> draft-korhonen-mip6-service-04 (work
> >>>>          in progress), October 2007.
> >>>>
> >>>> [4] got published as RFC 5149.
> >>>>
> >>>> Anyway, I don't think we should get into discussing
> >>> solutions at this
> >>>> point. The above is to just show that the MIPv6 solutions can be
> >>>> re-used for PMIPv6. We don't have to re-invent what we have
> >>> done in the IETF so far.
> >>>>
> >>>> I would prefer that we let the market decide whether they
> >>> want to go
> >>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> >>> or PMIPv6.
> >>>> that would be a political discussion. :)
> >>>>
> >>>> Vijay
> >>>>
> >>>>>
> >>>>> Hesham
> >>>>>
> >>>>>
> >>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >>>>>
> >>>>>> George, Hesham,
> >>>>>>
> >>>>>> I don't see the point in having philosophical discussions
> >>> on whether
> >>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> >>> point. That
> >>>>>> ship has sailed. What we have as a reality is folks deploying
> >>>>>> systems with inter access technology handovers with PMIPv6 as the
> >>>>>> mobility management protocol. Asking these folks to now
> >>> use Mobile
> >>>>>> IPv6 does not help anyone, IMHO.
> >>>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Wed, 08 Apr 2009 17:05:30 +1100
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 8/04/09 4:41 PM, "Mohana Jeyatharan" <Mohana.Jeyatharan at sg.panasonic.com>
wrote:

> Hi Rajeev and All,
> 
> I like the summary you have put forward here. As you have mentioned and many
> others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
> Currently we have a scenario where the MN MUST use PMIPv6 for mobility
> management for its multiple interfaces. I do not want to quote SDO, but
> 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or
> s2b(WLAN) interface.

=> If you're going to say "MUST" then yes you must quote that requirement.
If it came from an SDO then please send us a reference to that. Other 3GPP
people don't agree with you and stated that publicly on the list.

Hesham

Then if this MN wants multihoming, flow mobility etc, how
> can we do this? Are we going to run MIP6 ony for multihoimg purpose, on top of
> PMIP being used in corenetwork. Is this a good idea or are we going to do
> major multihoming work in MAG-LMA path and do some minor modifications to MN
> to keep it light weight as far as protocol modification is concerned. The
> second option seems more logical for pure PMIpv6 scenario. Reason is: operator
> may not allov two mobility manamgement protocols running just to achieve
> multihoming and what if the MN does not have MIP6 stack implemented.
> 
> For scenarios where MIP6 is used to handle mobility for all interfaces, then
> client based multihoming given as extensions of MIP6 is excellent. No one can
> deny this. For mixed scenarios such as PMIP and CMIP scenarios involving
> multiple inetrafces, then again probably MIP6 based multihoming may be ideal.
> This is something we need to explore as well.
> 
> But our discussion currently at Netext is, operator decides PMIPv6 for all
> interfaces and what solution do we have for multihoming and flow mobility? I
> think we should think along these lines. Is this PMIPv6 multihoming solution
> identical to MIP6 Multihoming solution. I don't think so. So we need to look
> at some drafts available that handles PMIPv6 multihoming and flow mobility and
> see the changes in UE and some functional modules introduced in architectural
> entities, to understand the differences. If same then no need of any new work.
> If different then need to look at benefits. Can we reduce signaling in MN-AR
> interface, can we make the protocol chnages of a leagcy MN minimal, can we
> reduce core network signaling. All such criteria need to be taken into account
> for comparision.
> 
> Well if the operator does not mind CMIP running over PMIP fine and good.
> But, what if not....
> 
> Thanks.
> BR,
> Mohana
> 
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
>> Sent: Wednesday, April 08, 2009 7:46 AM
>> To: netext at mail.mobileip.jp
>> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
>> 
>> 
>> 
>> Folks,
>> 
>> Let's step back a bit..It doesn't help to pit one protocol against another
>> like this, especially when they are both developed by us :-)
>> 
>> If the problem is well-understood - i.e., how to selectively move flows
>> across interfaces for MIP, the same problem is being investigated here for
>> PMIP6. Why? With multiple interfaces, there seems to be interest in this
>> (so-called flow mobility). How will this work? We don't know yet, we don't
>> have a standards spec, but there are a few drafts. We are only setting the
>> stage for solution(s).
>> 
>> Given this, we should try to focus on investigating the problem and
>> agreeing on how to go about working on a protocol specification. People
>> already know they could use MIP6 for this. We could re-state it surely,
>> but that cannot be the only approach.
>> 
>> Thanks,
>> 
>> -Rajeev
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
>>> Sent: Tuesday, April 07, 2009 3:27 PM
>>> To: Vijay Devarapalli
>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>> Subject: Re: [Netext] Keep missing the point .. Re: next
>>> steps for netext
>>> 
>>> 
>>> 
>>> 
>>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
>>> 
>>>> Hesham Soliman wrote:
>>>>> I don't know which people you're talking about or on which planet
>>>>> this stuff is being deployed.
>>>> 
>>>> Thats easy. Search for "LTE HRPD" at google.com. :)
>>>> 
>>>>> In any case, I'm interested in discussing technical
>>> aspects of this
>>>>> work and I have zero interest in politics and projections.
>>>> 
>>>> But I don't see that. You seem to want to tell people to use Mobile
>>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
>>> 
>>> => I'm not *telling* people to do it, I'm arguing that this
>>> is the best approach. All I'm getting back is "SDOx want
>>> this" and "people want this"
>>> and "the ship has sailed". It's very frustrating to have a
>>> discussion like this instead of showing a real PS.
>>> 
>>>> 
>>>> FWIW, the way I see it, the flow mobility solution for
>>> PMIPv6 does not
>>>> have to be that different from what we have for MIPv6.
>>> Instead of the
>>>> mobile node sending the service selection option (defined
>>> in RFC 5149)
>>>> and flow identification option in the BU, it?s the MAG that
>>> sends this
>>>> information in the PBU. The solution is the same. You tell
>>> the HA or
>>>> the LMA which flow filters to install.
>>>> 
>>>> The solution could be along the lines I wrote in section 3.3 of
>>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
>>> Nov 2007).
>>>> It says
>>> 
>>> => If there is a solution to be had I don't care whether it
>>> uses our draft or something new. My point is that making
>>> those decisions in the network just doesn't work. Yes there
>>> bits on the wire that can do anything but the decision to
>>> trigger these actions in the network is flawed. And without
>>> getting into too much detail, before we decide to go one way
>>> or another, I think a technical argument needs to be made
>>> about "why" it's needed and not "how" it might work. This
>>> might sound old-fashioned these days but I find it difficult
>>> to rubber stamp things without understanding why.
>>> This is all I'm going to say about this BoF unless someone
>>> has a PS to discuss.
>>> 
>>> Hesham
>>> 
>>>> 
>>>>     For this scenario to work, the mobile node must be able
>>> to indicate
>>>>     to the attached MAG which flow will be sent over the
>>> attachment to
>>>>     the MAG.  It may do this by indicating the service
>>> identifer during
>>>>     the layer 2 attachment to the MAG.  The service identifier is
>>>>     described in [4].  The MAG, in turn must include the
>>> flow information
>>>>     in the Proxy Binding Update sent to the LMA.  The MAG
>>> may use the
>>>>     Service Selection option [4] in the Proxy Binding
>>> Update to indicate
>>>>     the flow information.  The MAG may also contruct a flow
>>> filter and
>>>>     convey the information in the Proxy Binding Update.
>>> See [3] for more
>>>>     information on carrying flow filters in the proxy
>>> binding update.
>>>> 
>>>>     The LMA processes the Proxy Binding Update from the MAG
>>> and creates a
>>>>     filter based on the flow information.  The flow filters
>>> may be stored
>>>>     in the binding cache entry for the mobile node.
>>>> 
>>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
>>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
>>>>          progress), March 2007.
>>>> 
>>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
>>>>          Selection for Mobile IPv6",
>>> draft-korhonen-mip6-service-04 (work
>>>>          in progress), October 2007.
>>>> 
>>>> [4] got published as RFC 5149.
>>>> 
>>>> Anyway, I don't think we should get into discussing
>>> solutions at this
>>>> point. The above is to just show that the MIPv6 solutions can be
>>>> re-used for PMIPv6. We don't have to re-invent what we have
>>> done in the IETF so far.
>>>> 
>>>> I would prefer that we let the market decide whether they
>>> want to go
>>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
>>> or PMIPv6.
>>>> that would be a political discussion. :)
>>>> 
>>>> Vijay
>>>> 
>>>>> 
>>>>> Hesham
>>>>> 
>>>>> 
>>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
>>>>> 
>>>>>> George, Hesham,
>>>>>> 
>>>>>> I don't see the point in having philosophical discussions
>>> on whether
>>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
>>> point. That
>>>>>> ship has sailed. What we have as a reality is folks deploying
>>>>>> systems with inter access technology handovers with PMIPv6 as the
>>>>>> mobility management protocol. Asking these folks to now
>>> use Mobile
>>>>>> IPv6 does not help anyone, IMHO.
>>>>>> 
>>>>>> Vijay
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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: Wed, 8 Apr 2009 13:41:49 +0800
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev and All,

I like the summary you have put forward here. As you have mentioned and many others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
Currently we have a scenario where the MN MUST use PMIPv6 for mobility management for its multiple interfaces. I do not want to quote SDO, but
3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or s2b(WLAN) interface. Then if this MN wants multihoming, flow mobility etc, how can we do this? Are we going to run MIP6 ony for multihoimg purpose, on top of PMIP being used in corenetwork. Is this a good idea or are we going to do major multihoming work in MAG-LMA path and do some minor modifications to MN to keep it light weight as far as protocol modification is concerned. The second option seems more logical for pure PMIpv6 scenario. Reason is: operator may not allov two mobility manamgement protocols running just to achieve multihoming and what if the MN does not have MIP6 stack implemented. 

For scenarios where MIP6 is used to handle mobility for all interfaces, then client based multihoming given as extensions of MIP6 is excellent. No one can deny this. For mixed scenarios such as PMIP and CMIP scenarios involving multiple inetrafces, then again probably MIP6 based multihoming may be ideal. This is something we need to explore as well.

But our discussion currently at Netext is, operator decides PMIPv6 for all interfaces and what solution do we have for multihoming and flow mobility? I think we should think along these lines. Is this PMIPv6 multihoming solution identical to MIP6 Multihoming solution. I don't think so. So we need to look at some drafts available that handles PMIPv6 multihoming and flow mobility and see the changes in UE and some functional modules introduced in architectural entities, to understand the differences. If same then no need of any new work. If different then need to look at benefits. Can we reduce signaling in MN-AR interface, can we make the protocol chnages of a leagcy MN minimal, can we reduce core network signaling. All such criteria need to be taken into account for comparision.

Well if the operator does not mind CMIP running over PMIP fine and good. 
But, what if not....

Thanks.
BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> Sent: Wednesday, April 08, 2009 7:46 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> 
> 
> Folks,
> 
> Let's step back a bit..It doesn't help to pit one protocol against another
> like this, especially when they are both developed by us :-)
> 
> If the problem is well-understood - i.e., how to selectively move flows
> across interfaces for MIP, the same problem is being investigated here for
> PMIP6. Why? With multiple interfaces, there seems to be interest in this
> (so-called flow mobility). How will this work? We don't know yet, we don't
> have a standards spec, but there are a few drafts. We are only setting the
> stage for solution(s).
> 
> Given this, we should try to focus on investigating the problem and
> agreeing on how to go about working on a protocol specification. People
> already know they could use MIP6 for this. We could re-state it surely,
> but that cannot be the only approach.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> > Sent: Tuesday, April 07, 2009 3:27 PM
> > To: Vijay Devarapalli
> > Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next
> > steps for netext
> >
> >
> >
> >
> > On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >
> > > Hesham Soliman wrote:
> > >> I don't know which people you're talking about or on which planet
> > >> this stuff is being deployed.
> > >
> > > Thats easy. Search for "LTE HRPD" at google.com. :)
> > >
> > >> In any case, I'm interested in discussing technical
> > aspects of this
> > >> work and I have zero interest in politics and projections.
> > >
> > > But I don't see that. You seem to want to tell people to use Mobile
> > > IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> >
> > => I'm not *telling* people to do it, I'm arguing that this
> > is the best approach. All I'm getting back is "SDOx want
> > this" and "people want this"
> > and "the ship has sailed". It's very frustrating to have a
> > discussion like this instead of showing a real PS.
> >
> > >
> > > FWIW, the way I see it, the flow mobility solution for
> > PMIPv6 does not
> > > have to be that different from what we have for MIPv6.
> > Instead of the
> > > mobile node sending the service selection option (defined
> > in RFC 5149)
> > > and flow identification option in the BU, it?s the MAG that
> > sends this
> > > information in the PBU. The solution is the same. You tell
> > the HA or
> > > the LMA which flow filters to install.
> > >
> > > The solution could be along the lines I wrote in section 3.3 of
> > > draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > Nov 2007).
> > > It says
> >
> > => If there is a solution to be had I don't care whether it
> > uses our draft or something new. My point is that making
> > those decisions in the network just doesn't work. Yes there
> > bits on the wire that can do anything but the decision to
> > trigger these actions in the network is flawed. And without
> > getting into too much detail, before we decide to go one way
> > or another, I think a technical argument needs to be made
> > about "why" it's needed and not "how" it might work. This
> > might sound old-fashioned these days but I find it difficult
> > to rubber stamp things without understanding why.
> > This is all I'm going to say about this BoF unless someone
> > has a PS to discuss.
> >
> > Hesham
> >
> > >
> > >     For this scenario to work, the mobile node must be able
> > to indicate
> > >     to the attached MAG which flow will be sent over the
> > attachment to
> > >     the MAG.  It may do this by indicating the service
> > identifer during
> > >     the layer 2 attachment to the MAG.  The service identifier is
> > >     described in [4].  The MAG, in turn must include the
> > flow information
> > >     in the Proxy Binding Update sent to the LMA.  The MAG
> > may use the
> > >     Service Selection option [4] in the Proxy Binding
> > Update to indicate
> > >     the flow information.  The MAG may also contruct a flow
> > filter and
> > >     convey the information in the Proxy Binding Update.
> > See [3] for more
> > >     information on carrying flow filters in the proxy
> > binding update.
> > >
> > >     The LMA processes the Proxy Binding Update from the MAG
> > and creates a
> > >     filter based on the flow information.  The flow filters
> > may be stored
> > >     in the binding cache entry for the mobile node.
> > >
> > >     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> > >          Support", draft-soliman-monami6-flow-binding-04 (work in
> > >          progress), March 2007.
> > >
> > >     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > >          Selection for Mobile IPv6",
> > draft-korhonen-mip6-service-04 (work
> > >          in progress), October 2007.
> > >
> > > [4] got published as RFC 5149.
> > >
> > > Anyway, I don't think we should get into discussing
> > solutions at this
> > > point. The above is to just show that the MIPv6 solutions can be
> > > re-used for PMIPv6. We don't have to re-invent what we have
> > done in the IETF so far.
> > >
> > > I would prefer that we let the market decide whether they
> > want to go
> > > with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > or PMIPv6.
> > > that would be a political discussion. :)
> > >
> > > Vijay
> > >
> > >>
> > >> Hesham
> > >>
> > >>
> > >> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>
> > >>> George, Hesham,
> > >>>
> > >>> I don't see the point in having philosophical discussions
> > on whether
> > >>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > point. That
> > >>> ship has sailed. What we have as a reality is folks deploying
> > >>> systems with inter access technology handovers with PMIPv6 as the
> > >>> mobility management protocol. Asking these folks to now
> > use Mobile
> > >>> IPv6 does not help anyone, IMHO.
> > >>>
> > >>> Vijay
> > >>>
> > >>
> > >>
> > >
> >
> >
> >
> > _______________________________________________
> > 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

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 7 Apr 2009 19:46:04 -0400
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Folks,

Let's step back a bit..It doesn't help to pit one protocol against another like this, especially when they are both developed by us :-)

If the problem is well-understood - i.e., how to selectively move flows across interfaces for MIP, the same problem is being investigated here for PMIP6. Why? With multiple interfaces, there seems to be interest in this (so-called flow mobility). How will this work? We don't know yet, we don't have a standards spec, but there are a few drafts. We are only setting the stage for solution(s). 

Given this, we should try to focus on investigating the problem and agreeing on how to go about working on a protocol specification. People already know they could use MIP6 for this. We could re-state it surely, but that cannot be the only approach. 

Thanks,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> Sent: Tuesday, April 07, 2009 3:27 PM
> To: Vijay Devarapalli
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next 
> steps for netext
> 
> 
> 
> 
> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> 
> > Hesham Soliman wrote:
> >> I don't know which people you're talking about or on which planet 
> >> this stuff is being deployed.
> > 
> > Thats easy. Search for "LTE HRPD" at google.com. :)
> > 
> >> In any case, I'm interested in discussing technical 
> aspects of this 
> >> work and I have zero interest in politics and projections.
> > 
> > But I don't see that. You seem to want to tell people to use Mobile 
> > IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> 
> => I'm not *telling* people to do it, I'm arguing that this 
> is the best approach. All I'm getting back is "SDOx want 
> this" and "people want this"
> and "the ship has sailed". It's very frustrating to have a 
> discussion like this instead of showing a real PS.
> 
> > 
> > FWIW, the way I see it, the flow mobility solution for 
> PMIPv6 does not 
> > have to be that different from what we have for MIPv6. 
> Instead of the 
> > mobile node sending the service selection option (defined 
> in RFC 5149) 
> > and flow identification option in the BU, it?s the MAG that 
> sends this 
> > information in the PBU. The solution is the same. You tell 
> the HA or 
> > the LMA which flow filters to install.
> > 
> > The solution could be along the lines I wrote in section 3.3 of 
> > draft-devarapalli-netlmm-multihoming-01.txt (submitted in 
> Nov 2007). 
> > It says
> 
> => If there is a solution to be had I don't care whether it 
> uses our draft or something new. My point is that making 
> those decisions in the network just doesn't work. Yes there 
> bits on the wire that can do anything but the decision to 
> trigger these actions in the network is flawed. And without 
> getting into too much detail, before we decide to go one way 
> or another, I think a technical argument needs to be made 
> about "why" it's needed and not "how" it might work. This 
> might sound old-fashioned these days but I find it difficult 
> to rubber stamp things without understanding why.
> This is all I'm going to say about this BoF unless someone 
> has a PS to discuss.
> 
> Hesham
> 
> > 
> >     For this scenario to work, the mobile node must be able 
> to indicate
> >     to the attached MAG which flow will be sent over the 
> attachment to
> >     the MAG.  It may do this by indicating the service 
> identifer during
> >     the layer 2 attachment to the MAG.  The service identifier is
> >     described in [4].  The MAG, in turn must include the 
> flow information
> >     in the Proxy Binding Update sent to the LMA.  The MAG 
> may use the
> >     Service Selection option [4] in the Proxy Binding 
> Update to indicate
> >     the flow information.  The MAG may also contruct a flow 
> filter and
> >     convey the information in the Proxy Binding Update.  
> See [3] for more
> >     information on carrying flow filters in the proxy 
> binding update.
> > 
> >     The LMA processes the Proxy Binding Update from the MAG 
> and creates a
> >     filter based on the flow information.  The flow filters 
> may be stored
> >     in the binding cache entry for the mobile node.
> > 
> >     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> >          Support", draft-soliman-monami6-flow-binding-04 (work in
> >          progress), March 2007.
> > 
> >     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> >          Selection for Mobile IPv6", 
> draft-korhonen-mip6-service-04 (work
> >          in progress), October 2007.
> > 
> > [4] got published as RFC 5149.
> > 
> > Anyway, I don't think we should get into discussing 
> solutions at this 
> > point. The above is to just show that the MIPv6 solutions can be 
> > re-used for PMIPv6. We don't have to re-invent what we have 
> done in the IETF so far.
> > 
> > I would prefer that we let the market decide whether they 
> want to go 
> > with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6 
> or PMIPv6.
> > that would be a political discussion. :)
> > 
> > Vijay
> > 
> >> 
> >> Hesham
> >> 
> >> 
> >> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> >> 
> >>> George, Hesham,
> >>> 
> >>> I don't see the point in having philosophical discussions 
> on whether 
> >>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this 
> point. That 
> >>> ship has sailed. What we have as a reality is folks deploying 
> >>> systems with inter access technology handovers with PMIPv6 as the 
> >>> mobility management protocol. Asking these folks to now 
> use Mobile 
> >>> IPv6 does not help anyone, IMHO.
> >>> 
> >>> Vijay
> >>> 
> >> 
> >> 
> > 
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 7 Apr 2009 19:17:43 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo, 

> 3GPP has a study item on this feature. There was no PMIPv6 
> solutions proposed on any I-D - there is a 3GPP-specific 
> solution proposed for PMIPv6 (based on the policy infrastructure).

This is exactly what I would like to avoid. I would prefer using a
solution developed in the IETF rather than something in 3GPP. 

Vijay

> 3GPP has not decided yet to do any normative work on any of 
> the solutions. 
> 
> Gerardo
> 
> > -----Original Message-----
> > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > Sent: Tuesday, April 07, 2009 2:52 PM
> > To: Giaretta, Gerardo
> > Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
> > Basavaraj.Patil at nokia.com
> > Subject: Re: [Netext] next steps for netext
> > 
> > 
> > >
> > > I will now stop discussing 3GPP specific issues in this 
> list, sorry for that
> > > :-)
> > 
> > => Please continue to tell us whether 3GPP needs certain 
> function though.
> > Based on your last email, I don't understand what is the 
> basis for the
> > claims of 3GPP needing this function. Seems like a baseless 
> claim not backed
> > by 3GPP.
> > 
> > Hesham
> > 
> > 
> > >
> > > Gerardo
> > >
> > >
> > >
> > >> Vijay
> > >>
> > >>> On the WiMAX side, I know there are still open issues 
> (discussed at the
> > last
> > >> 3GPP SA2 meeting) to make a handover between 3GPP and 
> WiMAX with PMIPv6
> > >> working.
> > >>>
> > >>>> Such
> > >>>> large scale managed networks are the main consumers of 
> PMIP6 so we
> > >> shouldn't
> > >>>> be ignoring what they're doing.
> > >>>
> > >>> This is mainly true for intra-technology mobility - and 
> note that I am
> > >> considering LTE-eHRPD intra-technology here as they are 
> homogeneous from a
> > >> link layer point of view.
> > >>>
> > >>> Gerardo
> > >>>
> > >>>> Saying to use MIP for inter-access
> > >>>> handovers/multihoming is not helping as they have 
> really set their mind
> > on
> > >>>> using PMIP6 and they're already doing this. Without 
> going into the
> > >> reasoning
> > >>>> behind such a decision, the fact is that PMIP6, as 
> defined in RFC 5213,
> > has
> > >>>> issues with inter-access handovers. I think it is 
> better to fix those
> > PMIP6
> > >>>> issues in the IETF then to let each SDO come up with 
> their own way of
> > >>>> dealing with this.
> > >>>>
> > >>>> domagoj
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: netext-bounces at mail.mobileip.jp
> > >>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> > >>>>> Hesham Soliman
> > >>>>> Sent: 07. travanj 2009 11:14
> > >>>>> To: Marco Liebsch
> > >>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > >>>>> Subject: Re: [Netext] next steps for netext
> > >>>>>
> > >>>>>
> > >>>>>>> => We're discussing a problem statement for the BoF, so
> > >>>>> 4830 is quite
> > >>>>>>> appropriate as a reference for why people wanted PMIP in
> > >>>>> the first place.
> > >>>>>> Yes, a problem statement about an existing solution for
> > >>>>> network-based
> > >>>>>> mobility management (PMIPv6) to support advanced use cases.
> > >>>>> => Where is that PS?
> > >>>>>
> > >>>>>   Not the problem of
> > >>>>>> existing solutions for localized mobility, as 
> RFC4830 does. I don't
> > >>>>>> think NetExt aims at turning PMIPv6 into a 
> host-based mobility
> > >>>>>> protocol again.
> > >>>>> => I don't know what the goal is based on the BoF discussion
> > >>>>> and this discussion on the list. The reason I don't know that
> > >>>>> is that no one is
> > >>>>> saying:
> > >>>>> Here is the state of the art (including BOTH MIP and PMIP)
> > >>>>> and here is why they don't work, therefore we need to do
> > >>>>> something new.
> > >>>>> That's what a PS should say. What's being said here is "PMIP
> > >>>>> doesn't support advanced cases therefore we need something
> > >>>>> new", which is completely bogus because PMIP was not designed
> > >>>>> to support those cases because we already have something else
> > >>>>> for supporting those cases. Hence my reference to 4830...
> > >>>>>
> > >>>>> I'm going to retire from the discussion till someone makes
> > >>>>> the argument above. Because I feel that if there is no such
> > >>>>> argument then the discussion is not a good use of time.
> > >>>>>
> > >>>>>
> > >>>>>>> => Yes, additional software like the existing MIP. I don't
> > >>>>> understand
> > >>>>>>> the motivation for creating something new. I've detailed
> > >>>>> this in my
> > >>>>>>> previous emails and the points remain unanswered.
> > >>>>>>>
> > >>>>>> Nobody talks about adding a piece of client mobility 
> management
> > >>>>>> software, such as a MIP client, to the mobile. That 
> seems to be a
> > >>>>>> wrong interpretation of what NetExt wants to do.
> > >>>>> => You're missing the point. Why isn't anybody talking about
> > >>>>> MIP??? That's what a PS should say.
> > >>>>>
> > >>>>> Hesham
> > >>>>>
> > >>>>>> marco
> > >>>>>>
> > >>>>>>
> > >>>>>>> Hesham
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> and obviously also according to RFC4831. We should
> > >>>>>>>
> > >>>>>>>> distinguish modification for mobility management, which
> > >>>>> is not what
> > >>>>>>>> we want to do, and enabling local functions, such 
> as the use of
> > >>>>>>>> multiple interfaces, where you have to add routes, 
> configure
> > >>>>>>>> interfaces etc. to enable the use case.
> > >>>>>>>>
> > >>>>>>>> marco
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Hesham Soliman schrieb:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> => I think you're distinguishing between modified and
> > >>>>> unmodified
> > >>>>>>>>>>> based on whether the modification affects IETF
> > >>>>> protocols or not.
> > >>>>>>>>>>> That's fine, but for those that did not attend 
> the BoF, our
> > >>>>>>>>>>> conclusions were that you will either end up modifying
> > >>>>> the host
> > >>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> > >>>>>>>>>>> L2 to handle the multihoming cases, or you can 
> stick with MIP.
> > >>>>>>>>>>> My opinion, and at least half the room's was that this
> > >>>>> is not a
> > >>>>>>>>>>> good way to
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> We can discuss what implies host changes and why 
> this is such a
> > >>>>>>>>>> big deal anyway. But I don't think that half the 
> room was in
> > >>>>>>>>>> agreement as such. At least from the count of hands
> > >>>>> raised for the
> > >>>>>>>>>> question about whether we should work on multihoming
> > >>>>> and intertech
> > >>>>>>>>>> handovers it was about 18-9 (in favor).
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> => I think the question changed a few times :) The final
> > >>>>> question
> > >>>>>>>>> (which was specific to whether people wanted to work
> > >>>>> with this or
> > >>>>>>>>> not) showed a split room.
> > >>>>>>>>> The host changes are not a big deal but they are 
> mentioned here
> > >>>>>>>>> because they were one of the very few reasons for using
> > >>>>> NETLMM in
> > >>>>>>>>> the first place: Host changes (adding new SW to 
> the host) and
> > >>>>>>>>> signalling from the MN. You can see them in section 4 of
> > >>>>> RFC 4830.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> go and that it's better to stick with MIP instead of
> > >>>>> relying on a
> > >>>>>>>>>>> solution that will:
> > >>>>>>>>>>> - work on some L2s and not others,
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> We have no ability to specify changes to L2 
> anyway. However if
> > >>>>>>>>>> some L2s do have such capability, why would we 
> not specify how
> > >>>>>>>>>> multihoming would work in such scenarios.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> => Because we already have a solution that works 
> in all L2s,
> > >>>>>>>>> doesn't require
> > >>>>>>>>> L2 changes that we don't control and doesn't cause
> > >>>>> confusing host
> > >>>>>>>>> config solutions.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> - Require additional SW and config on the host which
> > >>>>> is not done
> > >>>>>>>>>>> anywhere today, and
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> Why is there as much of a concern about additional SW
> > >>>>> or config?
> > >>>>>>>>>> After all everything (or most of it anyway) that we do
> > >>>>> in the IETF
> > >>>>>>>>>> requires configurations, protocol changes, 
> changes to SW etc.
> > >>>>>>>>>> There is nothing unique about this.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> => Sure, but see above and see RFC 4830. These were the
> > >>>>> reasons for
> > >>>>>>>>> using PMIP in the first place. We can't have it both
> > >>>>> ways, or can
> > >>>>>>>>> we? :)
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>> - Require L2 signalling which is out of our 
> scope in IETF
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> Agree. We cannot do anything about L2s. But we 
> could specify
> > >>>>>>>>>> (informatively)
> > >>>>>>>>>> what L2 capabilities would enable these features 
> if that is the
> > >>>>>>>>>> conclusion that we arrive at.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> => We can, but I don't know why we should do that when a
> > >>>>> solution
> > >>>>>>>>> already exists. Especially when the alternative 
> is inferior in
> > >>>>>>>>> terms of its applicability.
> > >>>>>>>>>
> > >>>>>>>>> Hesham
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> -Raj
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> This is why I think we should stick with the charter
> > >>>>> that Jari sent.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Hesham
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I share the same view with respect to all your other
> > >>>>> comments.
> > >>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> > >>>>> basic handoff
> > >>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed 
> mostly flow
> > >>>>>>>>>>>> mobility and not the basic handoff cases supported
> > >>>>> today in 5213.
> > >>>>>>>>>>>> Sri
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> _______________________________________________
> > >>>>>>>>>>>> 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
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> 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
> > >>>
> > >>> _______________________________________________
> > >>> 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
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 07 Apr 2009 16:12:58 -0700
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hesham Soliman wrote:
> I don't know which people you're talking about or on which planet this stuff
> is being deployed. 

Thats easy. Search for "LTE HRPD" at google.com. :)

 > In any case, I'm interested in discussing technical
> aspects of this work and I have zero interest in politics and projections.

But I don't see that. You seem to want to tell people to use Mobile IPv6 
instead of PMIPv6. That doesn't help anyone, IMHO.

FWIW, the way I see it, the flow mobility solution for PMIPv6 does not 
have to be that different from what we have for MIPv6. Instead of the 
mobile node sending the service selection option (defined in RFC 5149) 
and flow identification option in the BU, it?s the MAG that sends this 
information in the PBU. The solution is the same. You tell the HA or the 
LMA which flow filters to install.

The solution could be along the lines I wrote in section 3.3 of 
draft-devarapalli-netlmm-multihoming-01.txt (submitted in Nov 2007). It says

    For this scenario to work, the mobile node must be able to indicate
    to the attached MAG which flow will be sent over the attachment to
    the MAG.  It may do this by indicating the service identifer during
    the layer 2 attachment to the MAG.  The service identifier is
    described in [4].  The MAG, in turn must include the flow information
    in the Proxy Binding Update sent to the LMA.  The MAG may use the
    Service Selection option [4] in the Proxy Binding Update to indicate
    the flow information.  The MAG may also contruct a flow filter and
    convey the information in the Proxy Binding Update.  See [3] for more
    information on carrying flow filters in the proxy binding update.

    The LMA processes the Proxy Binding Update from the MAG and creates a
    filter based on the flow information.  The flow filters may be stored
    in the binding cache entry for the mobile node.

    [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
         Support", draft-soliman-monami6-flow-binding-04 (work in
         progress), March 2007.

    [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
         Selection for Mobile IPv6", draft-korhonen-mip6-service-04 (work
         in progress), October 2007.

[4] got published as RFC 5149.

Anyway, I don't think we should get into discussing solutions at this 
point. The above is to just show that the MIPv6 solutions can be re-used 
for PMIPv6. We don't have to re-invent what we have done in the IETF so far.

I would prefer that we let the market decide whether they want to go 
with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6 or PMIPv6. 
that would be a political discussion. :)

Vijay

> 
> Hesham
> 
> 
> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> 
>> George, Hesham,
>>
>> I don't see the point in having philosophical discussions on whether
>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
>> has sailed. What we have as a reality is folks deploying systems with
>> inter access technology handovers with PMIPv6 as the mobility management
>> protocol. Asking these folks to now use Mobile IPv6 does not help
>> anyone, IMHO.
>>
>> Vijay
>>
> 
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 15:59:45 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

3GPP has a study item on this feature. There was no PMIPv6 solutions proposed on any I-D - there is a 3GPP-specific solution proposed for PMIPv6 (based on the policy infrastructure).

3GPP has not decided yet to do any normative work on any of the solutions. 

Gerardo

> -----Original Message-----
> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Sent: Tuesday, April 07, 2009 2:52 PM
> To: Giaretta, Gerardo
> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
> Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> >
> > I will now stop discussing 3GPP specific issues in this list, sorry for that
> > :-)
> 
> => Please continue to tell us whether 3GPP needs certain function though.
> Based on your last email, I don't understand what is the basis for the
> claims of 3GPP needing this function. Seems like a baseless claim not backed
> by 3GPP.
> 
> Hesham
> 
> 
> >
> > Gerardo
> >
> >
> >
> >> Vijay
> >>
> >>> On the WiMAX side, I know there are still open issues (discussed at the
> last
> >> 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6
> >> working.
> >>>
> >>>> Such
> >>>> large scale managed networks are the main consumers of PMIP6 so we
> >> shouldn't
> >>>> be ignoring what they're doing.
> >>>
> >>> This is mainly true for intra-technology mobility - and note that I am
> >> considering LTE-eHRPD intra-technology here as they are homogeneous from a
> >> link layer point of view.
> >>>
> >>> Gerardo
> >>>
> >>>> Saying to use MIP for inter-access
> >>>> handovers/multihoming is not helping as they have really set their mind
> on
> >>>> using PMIP6 and they're already doing this. Without going into the
> >> reasoning
> >>>> behind such a decision, the fact is that PMIP6, as defined in RFC 5213,
> has
> >>>> issues with inter-access handovers. I think it is better to fix those
> PMIP6
> >>>> issues in the IETF then to let each SDO come up with their own way of
> >>>> dealing with this.
> >>>>
> >>>> domagoj
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: netext-bounces at mail.mobileip.jp
> >>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> >>>>> Hesham Soliman
> >>>>> Sent: 07. travanj 2009 11:14
> >>>>> To: Marco Liebsch
> >>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>>>> Subject: Re: [Netext] next steps for netext
> >>>>>
> >>>>>
> >>>>>>> => We're discussing a problem statement for the BoF, so
> >>>>> 4830 is quite
> >>>>>>> appropriate as a reference for why people wanted PMIP in
> >>>>> the first place.
> >>>>>> Yes, a problem statement about an existing solution for
> >>>>> network-based
> >>>>>> mobility management (PMIPv6) to support advanced use cases.
> >>>>> => Where is that PS?
> >>>>>
> >>>>>   Not the problem of
> >>>>>> existing solutions for localized mobility, as RFC4830 does. I don't
> >>>>>> think NetExt aims at turning PMIPv6 into a host-based mobility
> >>>>>> protocol again.
> >>>>> => I don't know what the goal is based on the BoF discussion
> >>>>> and this discussion on the list. The reason I don't know that
> >>>>> is that no one is
> >>>>> saying:
> >>>>> Here is the state of the art (including BOTH MIP and PMIP)
> >>>>> and here is why they don't work, therefore we need to do
> >>>>> something new.
> >>>>> That's what a PS should say. What's being said here is "PMIP
> >>>>> doesn't support advanced cases therefore we need something
> >>>>> new", which is completely bogus because PMIP was not designed
> >>>>> to support those cases because we already have something else
> >>>>> for supporting those cases. Hence my reference to 4830...
> >>>>>
> >>>>> I'm going to retire from the discussion till someone makes
> >>>>> the argument above. Because I feel that if there is no such
> >>>>> argument then the discussion is not a good use of time.
> >>>>>
> >>>>>
> >>>>>>> => Yes, additional software like the existing MIP. I don't
> >>>>> understand
> >>>>>>> the motivation for creating something new. I've detailed
> >>>>> this in my
> >>>>>>> previous emails and the points remain unanswered.
> >>>>>>>
> >>>>>> Nobody talks about adding a piece of client mobility management
> >>>>>> software, such as a MIP client, to the mobile. That seems to be a
> >>>>>> wrong interpretation of what NetExt wants to do.
> >>>>> => You're missing the point. Why isn't anybody talking about
> >>>>> MIP??? That's what a PS should say.
> >>>>>
> >>>>> Hesham
> >>>>>
> >>>>>> marco
> >>>>>>
> >>>>>>
> >>>>>>> Hesham
> >>>>>>>
> >>>>>>>
> >>>>>>> and obviously also according to RFC4831. We should
> >>>>>>>
> >>>>>>>> distinguish modification for mobility management, which
> >>>>> is not what
> >>>>>>>> we want to do, and enabling local functions, such as the use of
> >>>>>>>> multiple interfaces, where you have to add routes, configure
> >>>>>>>> interfaces etc. to enable the use case.
> >>>>>>>>
> >>>>>>>> marco
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hesham Soliman schrieb:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> => I think you're distinguishing between modified and
> >>>>> unmodified
> >>>>>>>>>>> based on whether the modification affects IETF
> >>>>> protocols or not.
> >>>>>>>>>>> That's fine, but for those that did not attend the BoF, our
> >>>>>>>>>>> conclusions were that you will either end up modifying
> >>>>> the host
> >>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
> >>>>>>>>>>> My opinion, and at least half the room's was that this
> >>>>> is not a
> >>>>>>>>>>> good way to
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> We can discuss what implies host changes and why this is such a
> >>>>>>>>>> big deal anyway. But I don't think that half the room was in
> >>>>>>>>>> agreement as such. At least from the count of hands
> >>>>> raised for the
> >>>>>>>>>> question about whether we should work on multihoming
> >>>>> and intertech
> >>>>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> => I think the question changed a few times :) The final
> >>>>> question
> >>>>>>>>> (which was specific to whether people wanted to work
> >>>>> with this or
> >>>>>>>>> not) showed a split room.
> >>>>>>>>> The host changes are not a big deal but they are mentioned here
> >>>>>>>>> because they were one of the very few reasons for using
> >>>>> NETLMM in
> >>>>>>>>> the first place: Host changes (adding new SW to the host) and
> >>>>>>>>> signalling from the MN. You can see them in section 4 of
> >>>>> RFC 4830.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> go and that it's better to stick with MIP instead of
> >>>>> relying on a
> >>>>>>>>>>> solution that will:
> >>>>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> We have no ability to specify changes to L2 anyway. However if
> >>>>>>>>>> some L2s do have such capability, why would we not specify how
> >>>>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> => Because we already have a solution that works in all L2s,
> >>>>>>>>> doesn't require
> >>>>>>>>> L2 changes that we don't control and doesn't cause
> >>>>> confusing host
> >>>>>>>>> config solutions.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> - Require additional SW and config on the host which
> >>>>> is not done
> >>>>>>>>>>> anywhere today, and
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Why is there as much of a concern about additional SW
> >>>>> or config?
> >>>>>>>>>> After all everything (or most of it anyway) that we do
> >>>>> in the IETF
> >>>>>>>>>> requires configurations, protocol changes, changes to SW etc.
> >>>>>>>>>> There is nothing unique about this.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> => Sure, but see above and see RFC 4830. These were the
> >>>>> reasons for
> >>>>>>>>> using PMIP in the first place. We can't have it both
> >>>>> ways, or can
> >>>>>>>>> we? :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> - Require L2 signalling which is out of our scope in IETF
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Agree. We cannot do anything about L2s. But we could specify
> >>>>>>>>>> (informatively)
> >>>>>>>>>> what L2 capabilities would enable these features if that is the
> >>>>>>>>>> conclusion that we arrive at.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> => We can, but I don't know why we should do that when a
> >>>>> solution
> >>>>>>>>> already exists. Especially when the alternative is inferior in
> >>>>>>>>> terms of its applicability.
> >>>>>>>>>
> >>>>>>>>> Hesham
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -Raj
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> This is why I think we should stick with the charter
> >>>>> that Jari sent.
> >>>>>>>>>>>
> >>>>>>>>>>> Hesham
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> I share the same view with respect to all your other
> >>>>> comments.
> >>>>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>>>> basic handoff
> >>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
> >>>>>>>>>>>> mobility and not the basic handoff cases supported
> >>>>> today in 5213.
> >>>>>>>>>>>> Sri
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>> _______________________________________________
> >>> NetExt mailing list
> >>> NetExt at mail.mobileip.jp
> >>> http://www.mobileip.jp/mailman/listinfo/netext
> >
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Wed, 08 Apr 2009 09:26:34 +1100
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:

> Hesham Soliman wrote:
>> I don't know which people you're talking about or on which planet this stuff
>> is being deployed.
> 
> Thats easy. Search for "LTE HRPD" at google.com. :)
> 
>> In any case, I'm interested in discussing technical
>> aspects of this work and I have zero interest in politics and projections.
> 
> But I don't see that. You seem to want to tell people to use Mobile IPv6
> instead of PMIPv6. That doesn't help anyone, IMHO.

=> I'm not *telling* people to do it, I'm arguing that this is the best
approach. All I'm getting back is "SDOx want this" and "people want this"
and "the ship has sailed". It's very frustrating to have a discussion like
this instead of showing a real PS.

> 
> FWIW, the way I see it, the flow mobility solution for PMIPv6 does not
> have to be that different from what we have for MIPv6. Instead of the
> mobile node sending the service selection option (defined in RFC 5149)
> and flow identification option in the BU, it?s the MAG that sends this
> information in the PBU. The solution is the same. You tell the HA or the
> LMA which flow filters to install.
> 
> The solution could be along the lines I wrote in section 3.3 of
> draft-devarapalli-netlmm-multihoming-01.txt (submitted in Nov 2007). It says

=> If there is a solution to be had I don't care whether it uses our draft
or something new. My point is that making those decisions in the network
just doesn't work. Yes there bits on the wire that can do anything but the
decision to trigger these actions in the network is flawed. And without
getting into too much detail, before we decide to go one way or another, I
think a technical argument needs to be made about "why" it's needed and not
"how" it might work. This might sound old-fashioned these days but I find it
difficult to rubber stamp things without understanding why.
This is all I'm going to say about this BoF unless someone has a PS to
discuss.

Hesham

> 
>     For this scenario to work, the mobile node must be able to indicate
>     to the attached MAG which flow will be sent over the attachment to
>     the MAG.  It may do this by indicating the service identifer during
>     the layer 2 attachment to the MAG.  The service identifier is
>     described in [4].  The MAG, in turn must include the flow information
>     in the Proxy Binding Update sent to the LMA.  The MAG may use the
>     Service Selection option [4] in the Proxy Binding Update to indicate
>     the flow information.  The MAG may also contruct a flow filter and
>     convey the information in the Proxy Binding Update.  See [3] for more
>     information on carrying flow filters in the proxy binding update.
> 
>     The LMA processes the Proxy Binding Update from the MAG and creates a
>     filter based on the flow information.  The flow filters may be stored
>     in the binding cache entry for the mobile node.
> 
>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
>          Support", draft-soliman-monami6-flow-binding-04 (work in
>          progress), March 2007.
> 
>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
>          Selection for Mobile IPv6", draft-korhonen-mip6-service-04 (work
>          in progress), October 2007.
> 
> [4] got published as RFC 5149.
> 
> Anyway, I don't think we should get into discussing solutions at this
> point. The above is to just show that the MIPv6 solutions can be re-used
> for PMIPv6. We don't have to re-invent what we have done in the IETF so far.
> 
> I would prefer that we let the market decide whether they want to go
> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6 or PMIPv6.
> that would be a political discussion. :)
> 
> Vijay
> 
>> 
>> Hesham
>> 
>> 
>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
>> 
>>> George, Hesham,
>>> 
>>> I don't see the point in having philosophical discussions on whether
>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
>>> has sailed. What we have as a reality is folks deploying systems with
>>> inter access technology handovers with PMIPv6 as the mobility management
>>> protocol. Asking these folks to now use Mobile IPv6 does not help
>>> anyone, IMHO.
>>> 
>>> Vijay
>>> 
>> 
>> 
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Wed, 08 Apr 2009 08:57:08 +1100
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I don't know which people you're talking about or on which planet this stuff
is being deployed. In any case, I'm interested in discussing technical
aspects of this work and I have zero interest in politics and projections.

Hesham

On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:

> George, Hesham,
> 
> I don't see the point in having philosophical discussions on whether
> Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
> has sailed. What we have as a reality is folks deploying systems with
> inter access technology handovers with PMIPv6 as the mobility management
> protocol. Asking these folks to now use Mobile IPv6 does not help
> anyone, IMHO.
> 
> Vijay
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Wed, 08 Apr 2009 08:52:20 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> I will now stop discussing 3GPP specific issues in this list, sorry for that
> :-)

=> Please continue to tell us whether 3GPP needs certain function though.
Based on your last email, I don't understand what is the basis for the
claims of 3GPP needing this function. Seems like a baseless claim not backed
by 3GPP.

Hesham

> 
> Gerardo
> 
> 
> 
>> Vijay
>> 
>>> On the WiMAX side, I know there are still open issues (discussed at the last
>> 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6
>> working.
>>> 
>>>> Such
>>>> large scale managed networks are the main consumers of PMIP6 so we
>> shouldn't
>>>> be ignoring what they're doing.
>>> 
>>> This is mainly true for intra-technology mobility - and note that I am
>> considering LTE-eHRPD intra-technology here as they are homogeneous from a
>> link layer point of view.
>>> 
>>> Gerardo
>>> 
>>>> Saying to use MIP for inter-access
>>>> handovers/multihoming is not helping as they have really set their mind on
>>>> using PMIP6 and they're already doing this. Without going into the
>> reasoning
>>>> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
>>>> issues with inter-access handovers. I think it is better to fix those PMIP6
>>>> issues in the IETF then to let each SDO come up with their own way of
>>>> dealing with this.
>>>> 
>>>> domagoj
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: netext-bounces at mail.mobileip.jp
>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>> Hesham Soliman
>>>>> Sent: 07. travanj 2009 11:14
>>>>> To: Marco Liebsch
>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>> Subject: Re: [Netext] next steps for netext
>>>>> 
>>>>> 
>>>>>>> => We're discussing a problem statement for the BoF, so
>>>>> 4830 is quite
>>>>>>> appropriate as a reference for why people wanted PMIP in
>>>>> the first place.
>>>>>> Yes, a problem statement about an existing solution for
>>>>> network-based
>>>>>> mobility management (PMIPv6) to support advanced use cases.
>>>>> => Where is that PS?
>>>>> 
>>>>>   Not the problem of
>>>>>> existing solutions for localized mobility, as RFC4830 does. I don't
>>>>>> think NetExt aims at turning PMIPv6 into a host-based mobility
>>>>>> protocol again.
>>>>> => I don't know what the goal is based on the BoF discussion
>>>>> and this discussion on the list. The reason I don't know that
>>>>> is that no one is
>>>>> saying:
>>>>> Here is the state of the art (including BOTH MIP and PMIP)
>>>>> and here is why they don't work, therefore we need to do
>>>>> something new.
>>>>> That's what a PS should say. What's being said here is "PMIP
>>>>> doesn't support advanced cases therefore we need something
>>>>> new", which is completely bogus because PMIP was not designed
>>>>> to support those cases because we already have something else
>>>>> for supporting those cases. Hence my reference to 4830...
>>>>> 
>>>>> I'm going to retire from the discussion till someone makes
>>>>> the argument above. Because I feel that if there is no such
>>>>> argument then the discussion is not a good use of time.
>>>>> 
>>>>> 
>>>>>>> => Yes, additional software like the existing MIP. I don't
>>>>> understand
>>>>>>> the motivation for creating something new. I've detailed
>>>>> this in my
>>>>>>> previous emails and the points remain unanswered.
>>>>>>> 
>>>>>> Nobody talks about adding a piece of client mobility management
>>>>>> software, such as a MIP client, to the mobile. That seems to be a
>>>>>> wrong interpretation of what NetExt wants to do.
>>>>> => You're missing the point. Why isn't anybody talking about
>>>>> MIP??? That's what a PS should say.
>>>>> 
>>>>> Hesham
>>>>> 
>>>>>> marco
>>>>>> 
>>>>>> 
>>>>>>> Hesham
>>>>>>> 
>>>>>>> 
>>>>>>> and obviously also according to RFC4831. We should
>>>>>>> 
>>>>>>>> distinguish modification for mobility management, which
>>>>> is not what
>>>>>>>> we want to do, and enabling local functions, such as the use of
>>>>>>>> multiple interfaces, where you have to add routes, configure
>>>>>>>> interfaces etc. to enable the use case.
>>>>>>>> 
>>>>>>>> marco
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hesham Soliman schrieb:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> => I think you're distinguishing between modified and
>>>>> unmodified
>>>>>>>>>>> based on whether the modification affects IETF
>>>>> protocols or not.
>>>>>>>>>>> That's fine, but for those that did not attend the BoF, our
>>>>>>>>>>> conclusions were that you will either end up modifying
>>>>> the host
>>>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>>>>>>> My opinion, and at least half the room's was that this
>>>>> is not a
>>>>>>>>>>> good way to
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> We can discuss what implies host changes and why this is such a
>>>>>>>>>> big deal anyway. But I don't think that half the room was in
>>>>>>>>>> agreement as such. At least from the count of hands
>>>>> raised for the
>>>>>>>>>> question about whether we should work on multihoming
>>>>> and intertech
>>>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> => I think the question changed a few times :) The final
>>>>> question
>>>>>>>>> (which was specific to whether people wanted to work
>>>>> with this or
>>>>>>>>> not) showed a split room.
>>>>>>>>> The host changes are not a big deal but they are mentioned here
>>>>>>>>> because they were one of the very few reasons for using
>>>>> NETLMM in
>>>>>>>>> the first place: Host changes (adding new SW to the host) and
>>>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>> RFC 4830.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>> relying on a
>>>>>>>>>>> solution that will:
>>>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> We have no ability to specify changes to L2 anyway. However if
>>>>>>>>>> some L2s do have such capability, why would we not specify how
>>>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> => Because we already have a solution that works in all L2s,
>>>>>>>>> doesn't require
>>>>>>>>> L2 changes that we don't control and doesn't cause
>>>>> confusing host
>>>>>>>>> config solutions.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> - Require additional SW and config on the host which
>>>>> is not done
>>>>>>>>>>> anywhere today, and
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> Why is there as much of a concern about additional SW
>>>>> or config?
>>>>>>>>>> After all everything (or most of it anyway) that we do
>>>>> in the IETF
>>>>>>>>>> requires configurations, protocol changes, changes to SW etc.
>>>>>>>>>> There is nothing unique about this.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>> reasons for
>>>>>>>>> using PMIP in the first place. We can't have it both
>>>>> ways, or can
>>>>>>>>> we? :)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>>>>>>> (informatively)
>>>>>>>>>> what L2 capabilities would enable these features if that is the
>>>>>>>>>> conclusion that we arrive at.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> => We can, but I don't know why we should do that when a
>>>>> solution
>>>>>>>>> already exists. Especially when the alternative is inferior in
>>>>>>>>> terms of its applicability.
>>>>>>>>> 
>>>>>>>>> Hesham
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> -Raj
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> This is why I think we should stick with the charter
>>>>> that Jari sent.
>>>>>>>>>>> 
>>>>>>>>>>> Hesham
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> I share the same view with respect to all your other
>>>>> comments.
>>>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>> basic handoff
>>>>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>>>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>> today in 5213.
>>>>>>>>>>>> Sri
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 13:02:16 -0700
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

I agree we should not go into the details of 3GPP here, I was just providing that perspective as it was mentioned in some previous emails. We should focus more on the generic problem statement on why IETF should work on these aspects and why a solution is needed for the Internet, no matter what other SDOs are considering.

Cheers
Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Koodli, Rajeev
> Sent: Tuesday, April 07, 2009 11:18 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] PMIP multihoming/flow mobility: a different perspective
> 
> 
> Hi Gerardo,
> 
> thanks for your perspective. Perhaps we should not delve into insinuating 3GPP
> views here; we have a separate channel for any official discussion.
> 
> About your reference to L2 changes being necessary for WiFi: that's debatable.
> For one, when you move flows from WiFi to Cellular, the latter has support for
> MN signaling. For the other way around, you could still use th cellular radio
> to inform about movement to WiFi (LMA, being the anchor can inform the
> Cellular-MAG to initiate L2 signaling). There are other possibilities too. So,
> this is still open.
> 
> Regards,
> 
> -Rajeev
> 
> 
> ________________________________
> 
> From: netext-bounces at mail.mobileip.jp on behalf of Giaretta, Gerardo
> Sent: Tue 4/7/2009 9:10 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
> 
> 
> 
> Hi all,
> 
> I would like to provide a different perspective on the discussion about the
> need of this work. Note that I am focusing only on the multihoming and flow
> mobility aspects of Netext and not on other issues. This perspective comes
> mainly from the discussion 3GPP had in the last 6 months, therefore it cannot
> be considered a complete analysis for the Internet but just an input to the
> discussion.
> 
> As many have mentioned, 3GPP is currently studying the possibility of
> standardizing flow mobility. After some initial broad scope discussion, the
> study is now focusing on two specific radio technologies, one being cellular
> and the other being WiFi. This restriction is not yet official but it is
> pretty clear from the discussion at the meetings, the inputs from operators
> and the contributions from companies. The motivation for this restriction is
> twofold: first this is the only scenario operators see as beneficial; second
> from a terminal point of view, this seems to be the only realistic assumption
> (i.e. two high power radios on at the same time do not seem feasible,
> acceptable or desirable).
> 
> As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated L2
> signaling is needed between the MN and the MAG. However WiFi does not support
> any type of L2 signaling to enable this scenario and therefore PMIPv6
> multihoming/flow mobility is not possible in the scenarios mentioned above
> (unless we change/enhance the L2 of 802.11 WLAN).
> 
> In my opinion this boils down to the following point: if we look at deployment
> scenarios industry is looking at, a PMIPv6 solution for multihoming and flow
> mobility is basically not possible due to lack of support of L2 signaling in
> the accesses which are considered. Therefore the work proposed in Netext tends
> to be an academic exercise, rather than something really needed by the
> industry. At least this is what I think after having looked at this issue with
> other companies in the last 6 months.
> 
> Gerardo
> 
> _______________________________________________
> 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

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Tue, 7 Apr 2009 21:36:07 +0200
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Vijay,

Not all Wifi accesses are considered to be untrusted. If a Wifi access is
considered as a trusted access (depends on whether the wifi access is owned
by the 3GPP operator or the 3GPP operator has a business relationship with
the Wifi access operator for example), it is viewed as a trusted network and
the UE does not need to connect through an IPsec GW.

-Raj

On 4/7/09 2:23 PM, "ext Vijay Devarapalli" <vijay at wichorus.com> wrote:

> Hi Gerardo,
> 
>>>> As discussed, to enable PMIPv6 multihoming and flow mobility,
>>>> dedicated L2 signaling is needed between the MN and the MAG.
>>>> However WiFi does not support any type of L2 signaling to
>>>> enable this scenario and therefore PMIPv6 multihoming/flow
>>>> mobility is not possible in the scenarios mentioned above
>>>> (unless we change/enhance the L2 of 802.11 WLAN).
>>> 
>>> You can't access the 3GPP packet core from WiFi.
>> 
>> Not correct - the operator can consider the WiFi trusted and
>> you can access the 3GPP packet core without IPsec tunnel. It
>> is up to operator's decision.
> 
> Which document are you looking at? AFAIK, neither TS 23.402 nor TS
> 23.327 allow the mobile node to attach directly to the home agent from
> an untrusted access. The mobile node needs to go through an IPsec
> gateway always. When PMIPv6 is used, the MAG would be co-located with
> this IPsec gateway.
> 
> Am I missing something? Or is this some new development in 3GPP that I
> just don't know about yet?
> 
> Vijay
> 
>> 
>>> There is an IKEv2
>>> exchange and IPsec tunnel between the mobile node and the
>> MAG. The APN
>>> (or the service selection option as we call it in the IETF)
>> is sent as
>>> part of the IKEv2 signaling. So I think you are
>> exaggerating a bit in
>>> the above paragraph by saying a solution is not possible.
>>> 
>> 
>> That would allow you to perform just a normal handover and
>> not flow mobility.
>> 
>>> There is obviously no MAG in the WiFi hotspot or a generic
>> 802.11 access
>>> network.
>>> 
>> 
>> Indeed
>> 
>> Gerardo
>> 
>>> Vijay
>> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 7 Apr 2009 15:23:12 -0400
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo, 

> > > As discussed, to enable PMIPv6 multihoming and flow mobility,
> > > dedicated L2 signaling is needed between the MN and the MAG.
> > > However WiFi does not support any type of L2 signaling to
> > > enable this scenario and therefore PMIPv6 multihoming/flow
> > > mobility is not possible in the scenarios mentioned above
> > > (unless we change/enhance the L2 of 802.11 WLAN).
> > 
> > You can't access the 3GPP packet core from WiFi. 
> 
> Not correct - the operator can consider the WiFi trusted and 
> you can access the 3GPP packet core without IPsec tunnel. It 
> is up to operator's decision.

Which document are you looking at? AFAIK, neither TS 23.402 nor TS
23.327 allow the mobile node to attach directly to the home agent from
an untrusted access. The mobile node needs to go through an IPsec
gateway always. When PMIPv6 is used, the MAG would be co-located with
this IPsec gateway. 

Am I missing something? Or is this some new development in 3GPP that I
just don't know about yet?

Vijay

> 
> > There is an IKEv2
> > exchange and IPsec tunnel between the mobile node and the 
> MAG. The APN
> > (or the service selection option as we call it in the IETF) 
> is sent as
> > part of the IKEv2 signaling. So I think you are 
> exaggerating a bit in
> > the above paragraph by saying a solution is not possible.
> > 
> 
> That would allow you to perform just a normal handover and 
> not flow mobility.
> 
> > There is obviously no MAG in the WiFi hotspot or a generic 
> 802.11 access
> > network.
> > 
> 
> Indeed
> 
> Gerardo
> 
> > Vijay
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 12:02:33 -0700
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> Sent: Tuesday, April 07, 2009 11:52 AM
> To: Giaretta, Gerardo; netext at mail.mobileip.jp
> Subject: RE: [Netext] PMIP multihoming/flow mobility: a different perspective
> 
> Hi Gerardo,
> 
> > As discussed, to enable PMIPv6 multihoming and flow mobility,
> > dedicated L2 signaling is needed between the MN and the MAG.
> > However WiFi does not support any type of L2 signaling to
> > enable this scenario and therefore PMIPv6 multihoming/flow
> > mobility is not possible in the scenarios mentioned above
> > (unless we change/enhance the L2 of 802.11 WLAN).
> 
> You can't access the 3GPP packet core from WiFi. 

Not correct - the operator can consider the WiFi trusted and you can access the 3GPP packet core without IPsec tunnel. It is up to operator's decision.

> There is an IKEv2
> exchange and IPsec tunnel between the mobile node and the MAG. The APN
> (or the service selection option as we call it in the IETF) is sent as
> part of the IKEv2 signaling. So I think you are exaggerating a bit in
> the above paragraph by saying a solution is not possible.
> 

That would allow you to perform just a normal handover and not flow mobility.

> There is obviously no MAG in the WiFi hotspot or a generic 802.11 access
> network.
> 

Indeed

Gerardo

> Vijay

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 7 Apr 2009 14:51:47 -0400
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo, 

> As discussed, to enable PMIPv6 multihoming and flow mobility, 
> dedicated L2 signaling is needed between the MN and the MAG. 
> However WiFi does not support any type of L2 signaling to 
> enable this scenario and therefore PMIPv6 multihoming/flow 
> mobility is not possible in the scenarios mentioned above 
> (unless we change/enhance the L2 of 802.11 WLAN). 

You can't access the 3GPP packet core from WiFi. There is an IKEv2
exchange and IPsec tunnel between the mobile node and the MAG. The APN
(or the service selection option as we call it in the IETF) is sent as
part of the IKEv2 signaling. So I think you are exaggerating a bit in
the above paragraph by saying a solution is not possible.

There is obviously no MAG in the WiFi hotspot or a generic 802.11 access
network.

Vijay

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Tue, 7 Apr 2009 20:41:59 +0200
Subject: [Netext] Keep missing the point .. Re: next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

The two features that are at the centre of this discussion are:
Multihoming (and flow mobility) and Inter-technology handovers.

It is natural to compare Mobile IPv6 and PMIP6 protocols in terms of how
best they are able to provide solutions for these. It is okay to discuss
them in the context of the IETF (I don't see where else you would have a
debate of IETF protocols).

Debating which protocol is deployed currently or will get deployed is less
useful. It is better to have a discussion of the protocol issues, scenarios,
limitations and solutions as a means to making a decision of what work we
choose to do. Deployments and industry will anyway choose a protocol that
best fits their needs and maybe we can do them a favor by providing a
comparative analysis via this discussion.

-Raj 

On 4/7/09 1:11 PM, "ext George Tsirtsis" <tsirtsis at googlemail.com> wrote:

> First of all no one is deploying anything yet :-)
> 
> In any case discussion is useful. People also want to deploy NAT66 but
> the community is debating vigorously whether the IETF should define
> these...in other words just because people want to do something it
> does not mean that the IETF has to comply.
> 
> George
> 
> On Tue, Apr 7, 2009 at 6:59 PM, Vijay Devarapalli <vijay at wichorus.com> wrote:
>> George, Hesham,
>> 
>> I don't see the point in having philosophical discussions on whether
>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
>> has sailed. What we have as a reality is folks deploying systems with
>> inter access technology handovers with PMIPv6 as the mobility management
>> protocol. Asking these folks to now use Mobile IPv6 does not help
>> anyone, IMHO.
>> 
>> Vijay
>> 
>> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 7 Apr 2009 14:18:20 -0400
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,
 
thanks for your perspective. Perhaps we should not delve into insinuating 3GPP views here; we have a separate channel for any official discussion.
 
About your reference to L2 changes being necessary for WiFi: that's debatable. For one, when you move flows from WiFi to Cellular, the latter has support for MN signaling. For the other way around, you could still use th cellular radio to inform about movement to WiFi (LMA, being the anchor can inform the Cellular-MAG to initiate L2 signaling). There are other possibilities too. So, this is still open.
 
Regards,
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of Giaretta, Gerardo
Sent: Tue 4/7/2009 9:10 AM
To: netext at mail.mobileip.jp
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective

Hi all,

I would like to provide a different perspective on the discussion about the need of this work. Note that I am focusing only on the multihoming and flow mobility aspects of Netext and not on other issues. This perspective comes mainly from the discussion 3GPP had in the last 6 months, therefore it cannot be considered a complete analysis for the Internet but just an input to the discussion.

As many have mentioned, 3GPP is currently studying the possibility of standardizing flow mobility. After some initial broad scope discussion, the study is now focusing on two specific radio technologies, one being cellular and the other being WiFi. This restriction is not yet official but it is pretty clear from the discussion at the meetings, the inputs from operators and the contributions from companies. The motivation for this restriction is twofold: first this is the only scenario operators see as beneficial; second from a terminal point of view, this seems to be the only realistic assumption (i.e. two high power radios on at the same time do not seem feasible, acceptable or desirable).

As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated L2 signaling is needed between the MN and the MAG. However WiFi does not support any type of L2 signaling to enable this scenario and therefore PMIPv6 multihoming/flow mobility is not possible in the scenarios mentioned above (unless we change/enhance the L2 of 802.11 WLAN).

In my opinion this boils down to the following point: if we look at deployment scenarios industry is looking at, a PMIPv6 solution for multihoming and flow mobility is basically not possible due to lack of support of L2 signaling in the accesses which are considered. Therefore the work proposed in Netext tends to be an academic exercise, rather than something really needed by the industry. At least this is what I think after having looked at this issue with other companies in the last 6 months.

Gerardo

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

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Tue, 7 Apr 2009 19:11:45 +0100
Subject: [Netext] Keep missing the point .. Re: next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

First of all no one is deploying anything yet :-)

In any case discussion is useful. People also want to deploy NAT66 but
the community is debating vigorously whether the IETF should define
these...in other words just because people want to do something it
does not mean that the IETF has to comply.

George

On Tue, Apr 7, 2009 at 6:59 PM, Vijay Devarapalli <vijay at wichorus.com> wrote:
> George, Hesham,
>
> I don't see the point in having philosophical discussions on whether
> Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
> has sailed. What we have as a reality is folks deploying systems with
> inter access technology handovers with PMIPv6 as the mobility management
> protocol. Asking these folks to now use Mobile IPv6 does not help
> anyone, IMHO.
>
> Vijay
>
>

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 7 Apr 2009 13:59:01 -0400
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

George, Hesham,

I don't see the point in having philosophical discussions on whether
Mobile IPv6 or Proxy Mobile IPv6 should be used at this point. That ship
has sailed. What we have as a reality is folks deploying systems with
inter access technology handovers with PMIPv6 as the mobility management
protocol. Asking these folks to now use Mobile IPv6 does not help
anyone, IMHO.

Vijay

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 10:58:02 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi vijay,

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> Sent: Tuesday, April 07, 2009 10:52 AM
> To: Giaretta, Gerardo
> Cc: Domagoj Premec; 'ext Hesham Soliman'; 'Marco Liebsch';
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> Hi Gerardo,
> 
> Giaretta, Gerardo wrote:
> 
> >>> What's being said here is "PMIP
> >>> doesn't support advanced cases therefore we need something
> >>> new", which is completely bogus because PMIP was not designed
> >>> to support those cases because we already have something else
> >>> for supporting those cases. Hence my reference to 4830...
> >>>
> >> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover.
> >
> > 3GPP allows both PMIPv6 and DSMIPv6 for inter-access handover. PMIPv6 is
> used for LTE-eHRPD handovers and 3GPP2 designed a new link layer for eHRPD
> exactly because that was needed for PMIPv6. For example 3G-WLAN inter-system
> handover is only specified for DSMIPv6 in 3GPP. So let's be clear and stop
> claiming 3GPP needs PMIPv6 extensions.
> 
> This is not correct. The use of PMIPv6 for handovers between LTE-WiMAX
> and LTE-I-WLAN has been completely specified. I don't know which specs
> you are looking at.
> 

I referred to 3G-WLAN in my email as only DSMIPv6 and LTE-eHRPD as only PMIPv6. I did not mention LTE-WiMAX or LTE-IWLAN as they are generic inter-access handovers and, as per my first sentence above, they can be done with both DSMIPv6 and PMIPv6. As you said, this is specified in 3GPP and does not require any further work from IETF.

I will now stop discussing 3GPP specific issues in this list, sorry for that :-)

Gerardo

> Vijay
> 
> > On the WiMAX side, I know there are still open issues (discussed at the last
> 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6
> working.
> >
> >> Such
> >> large scale managed networks are the main consumers of PMIP6 so we
> shouldn't
> >> be ignoring what they're doing.
> >
> > This is mainly true for intra-technology mobility - and note that I am
> considering LTE-eHRPD intra-technology here as they are homogeneous from a
> link layer point of view.
> >
> > Gerardo
> >
> >> Saying to use MIP for inter-access
> >> handovers/multihoming is not helping as they have really set their mind on
> >> using PMIP6 and they're already doing this. Without going into the
> reasoning
> >> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
> >> issues with inter-access handovers. I think it is better to fix those PMIP6
> >> issues in the IETF then to let each SDO come up with their own way of
> >> dealing with this.
> >>
> >> domagoj
> >>
> >>
> >>> -----Original Message-----
> >>> From: netext-bounces at mail.mobileip.jp
> >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> >>> Hesham Soliman
> >>> Sent: 07. travanj 2009 11:14
> >>> To: Marco Liebsch
> >>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >>> Subject: Re: [Netext] next steps for netext
> >>>
> >>>
> >>>>> => We're discussing a problem statement for the BoF, so
> >>> 4830 is quite
> >>>>> appropriate as a reference for why people wanted PMIP in
> >>> the first place.
> >>>> Yes, a problem statement about an existing solution for
> >>> network-based
> >>>> mobility management (PMIPv6) to support advanced use cases.
> >>> => Where is that PS?
> >>>
> >>>   Not the problem of
> >>>> existing solutions for localized mobility, as RFC4830 does. I don't
> >>>> think NetExt aims at turning PMIPv6 into a host-based mobility
> >>>> protocol again.
> >>> => I don't know what the goal is based on the BoF discussion
> >>> and this discussion on the list. The reason I don't know that
> >>> is that no one is
> >>> saying:
> >>> Here is the state of the art (including BOTH MIP and PMIP)
> >>> and here is why they don't work, therefore we need to do
> >>> something new.
> >>> That's what a PS should say. What's being said here is "PMIP
> >>> doesn't support advanced cases therefore we need something
> >>> new", which is completely bogus because PMIP was not designed
> >>> to support those cases because we already have something else
> >>> for supporting those cases. Hence my reference to 4830...
> >>>
> >>> I'm going to retire from the discussion till someone makes
> >>> the argument above. Because I feel that if there is no such
> >>> argument then the discussion is not a good use of time.
> >>>
> >>>
> >>>>> => Yes, additional software like the existing MIP. I don't
> >>> understand
> >>>>> the motivation for creating something new. I've detailed
> >>> this in my
> >>>>> previous emails and the points remain unanswered.
> >>>>>
> >>>> Nobody talks about adding a piece of client mobility management
> >>>> software, such as a MIP client, to the mobile. That seems to be a
> >>>> wrong interpretation of what NetExt wants to do.
> >>> => You're missing the point. Why isn't anybody talking about
> >>> MIP??? That's what a PS should say.
> >>>
> >>> Hesham
> >>>
> >>>> marco
> >>>>
> >>>>
> >>>>> Hesham
> >>>>>
> >>>>>
> >>>>> and obviously also according to RFC4831. We should
> >>>>>
> >>>>>> distinguish modification for mobility management, which
> >>> is not what
> >>>>>> we want to do, and enabling local functions, such as the use of
> >>>>>> multiple interfaces, where you have to add routes, configure
> >>>>>> interfaces etc. to enable the use case.
> >>>>>>
> >>>>>> marco
> >>>>>>
> >>>>>>
> >>>>>> Hesham Soliman schrieb:
> >>>>>>
> >>>>>>>
> >>>>>>>>> => I think you're distinguishing between modified and
> >>> unmodified
> >>>>>>>>> based on whether the modification affects IETF
> >>> protocols or not.
> >>>>>>>>> That's fine, but for those that did not attend the BoF, our
> >>>>>>>>> conclusions were that you will either end up modifying
> >>> the host
> >>>>>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
> >>>>>>>>> My opinion, and at least half the room's was that this
> >>> is not a
> >>>>>>>>> good way to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> We can discuss what implies host changes and why this is such a
> >>>>>>>> big deal anyway. But I don't think that half the room was in
> >>>>>>>> agreement as such. At least from the count of hands
> >>> raised for the
> >>>>>>>> question about whether we should work on multihoming
> >>> and intertech
> >>>>>>>> handovers it was about 18-9 (in favor).
> >>>>>>>>
> >>>>>>>>
> >>>>>>> => I think the question changed a few times :) The final
> >>> question
> >>>>>>> (which was specific to whether people wanted to work
> >>> with this or
> >>>>>>> not) showed a split room.
> >>>>>>> The host changes are not a big deal but they are mentioned here
> >>>>>>> because they were one of the very few reasons for using
> >>> NETLMM in
> >>>>>>> the first place: Host changes (adding new SW to the host) and
> >>>>>>> signalling from the MN. You can see them in section 4 of
> >>> RFC 4830.
> >>>>>>>
> >>>>>>>
> >>>>>>>>> go and that it's better to stick with MIP instead of
> >>> relying on a
> >>>>>>>>> solution that will:
> >>>>>>>>> - work on some L2s and not others,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> We have no ability to specify changes to L2 anyway. However if
> >>>>>>>> some L2s do have such capability, why would we not specify how
> >>>>>>>> multihoming would work in such scenarios.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> => Because we already have a solution that works in all L2s,
> >>>>>>> doesn't require
> >>>>>>> L2 changes that we don't control and doesn't cause
> >>> confusing host
> >>>>>>> config solutions.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> - Require additional SW and config on the host which
> >>> is not done
> >>>>>>>>> anywhere today, and
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Why is there as much of a concern about additional SW
> >>> or config?
> >>>>>>>> After all everything (or most of it anyway) that we do
> >>> in the IETF
> >>>>>>>> requires configurations, protocol changes, changes to SW etc.
> >>>>>>>> There is nothing unique about this.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> => Sure, but see above and see RFC 4830. These were the
> >>> reasons for
> >>>>>>> using PMIP in the first place. We can't have it both
> >>> ways, or can
> >>>>>>> we? :)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> - Require L2 signalling which is out of our scope in IETF
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Agree. We cannot do anything about L2s. But we could specify
> >>>>>>>> (informatively)
> >>>>>>>> what L2 capabilities would enable these features if that is the
> >>>>>>>> conclusion that we arrive at.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> => We can, but I don't know why we should do that when a
> >>> solution
> >>>>>>> already exists. Especially when the alternative is inferior in
> >>>>>>> terms of its applicability.
> >>>>>>>
> >>>>>>> Hesham
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Raj
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> This is why I think we should stick with the charter
> >>> that Jari sent.
> >>>>>>>>>
> >>>>>>>>> Hesham
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I share the same view with respect to all your other
> >>> comments.
> >>>>>>>>>> We need to seperate the cases of flow mobility vs
> >>> basic handoff
> >>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
> >>>>>>>>>> mobility and not the basic handoff cases supported
> >>> today in 5213.
> >>>>>>>>>> Sri
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Tue, 07 Apr 2009 10:51:47 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

Giaretta, Gerardo wrote:

>>> What's being said here is "PMIP
>>> doesn't support advanced cases therefore we need something
>>> new", which is completely bogus because PMIP was not designed
>>> to support those cases because we already have something else
>>> for supporting those cases. Hence my reference to 4830...
>>>
>> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. 
> 
> 3GPP allows both PMIPv6 and DSMIPv6 for inter-access handover. PMIPv6 is used for LTE-eHRPD handovers and 3GPP2 designed a new link layer for eHRPD exactly because that was needed for PMIPv6. For example 3G-WLAN inter-system handover is only specified for DSMIPv6 in 3GPP. So let's be clear and stop claiming 3GPP needs PMIPv6 extensions.

This is not correct. The use of PMIPv6 for handovers between LTE-WiMAX 
and LTE-I-WLAN has been completely specified. I don't know which specs 
you are looking at.

Vijay

> On the WiMAX side, I know there are still open issues (discussed at the last 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6 working.
> 
>> Such
>> large scale managed networks are the main consumers of PMIP6 so we shouldn't
>> be ignoring what they're doing. 
> 
> This is mainly true for intra-technology mobility - and note that I am considering LTE-eHRPD intra-technology here as they are homogeneous from a link layer point of view.
> 
> Gerardo
> 
>> Saying to use MIP for inter-access
>> handovers/multihoming is not helping as they have really set their mind on
>> using PMIP6 and they're already doing this. Without going into the reasoning
>> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
>> issues with inter-access handovers. I think it is better to fix those PMIP6
>> issues in the IETF then to let each SDO come up with their own way of
>> dealing with this.
>>
>> domagoj
>>
>>
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>> Hesham Soliman
>>> Sent: 07. travanj 2009 11:14
>>> To: Marco Liebsch
>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] next steps for netext
>>>
>>>
>>>>> => We're discussing a problem statement for the BoF, so
>>> 4830 is quite
>>>>> appropriate as a reference for why people wanted PMIP in
>>> the first place.
>>>> Yes, a problem statement about an existing solution for
>>> network-based
>>>> mobility management (PMIPv6) to support advanced use cases.
>>> => Where is that PS?
>>>
>>>   Not the problem of
>>>> existing solutions for localized mobility, as RFC4830 does. I don't
>>>> think NetExt aims at turning PMIPv6 into a host-based mobility
>>>> protocol again.
>>> => I don't know what the goal is based on the BoF discussion
>>> and this discussion on the list. The reason I don't know that
>>> is that no one is
>>> saying:
>>> Here is the state of the art (including BOTH MIP and PMIP)
>>> and here is why they don't work, therefore we need to do
>>> something new.
>>> That's what a PS should say. What's being said here is "PMIP
>>> doesn't support advanced cases therefore we need something
>>> new", which is completely bogus because PMIP was not designed
>>> to support those cases because we already have something else
>>> for supporting those cases. Hence my reference to 4830...
>>>
>>> I'm going to retire from the discussion till someone makes
>>> the argument above. Because I feel that if there is no such
>>> argument then the discussion is not a good use of time.
>>>
>>>
>>>>> => Yes, additional software like the existing MIP. I don't
>>> understand
>>>>> the motivation for creating something new. I've detailed
>>> this in my
>>>>> previous emails and the points remain unanswered.
>>>>>
>>>> Nobody talks about adding a piece of client mobility management
>>>> software, such as a MIP client, to the mobile. That seems to be a
>>>> wrong interpretation of what NetExt wants to do.
>>> => You're missing the point. Why isn't anybody talking about
>>> MIP??? That's what a PS should say.
>>>
>>> Hesham
>>>
>>>> marco
>>>>
>>>>
>>>>> Hesham
>>>>>
>>>>>
>>>>> and obviously also according to RFC4831. We should
>>>>>
>>>>>> distinguish modification for mobility management, which
>>> is not what
>>>>>> we want to do, and enabling local functions, such as the use of
>>>>>> multiple interfaces, where you have to add routes, configure
>>>>>> interfaces etc. to enable the use case.
>>>>>>
>>>>>> marco
>>>>>>
>>>>>>
>>>>>> Hesham Soliman schrieb:
>>>>>>
>>>>>>>
>>>>>>>>> => I think you're distinguishing between modified and
>>> unmodified
>>>>>>>>> based on whether the modification affects IETF
>>> protocols or not.
>>>>>>>>> That's fine, but for those that did not attend the BoF, our
>>>>>>>>> conclusions were that you will either end up modifying
>>> the host
>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>>>>> My opinion, and at least half the room's was that this
>>> is not a
>>>>>>>>> good way to
>>>>>>>>>
>>>>>>>>>
>>>>>>>> We can discuss what implies host changes and why this is such a
>>>>>>>> big deal anyway. But I don't think that half the room was in
>>>>>>>> agreement as such. At least from the count of hands
>>> raised for the
>>>>>>>> question about whether we should work on multihoming
>>> and intertech
>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>
>>>>>>>>
>>>>>>> => I think the question changed a few times :) The final
>>> question
>>>>>>> (which was specific to whether people wanted to work
>>> with this or
>>>>>>> not) showed a split room.
>>>>>>> The host changes are not a big deal but they are mentioned here
>>>>>>> because they were one of the very few reasons for using
>>> NETLMM in
>>>>>>> the first place: Host changes (adding new SW to the host) and
>>>>>>> signalling from the MN. You can see them in section 4 of
>>> RFC 4830.
>>>>>>>
>>>>>>>
>>>>>>>>> go and that it's better to stick with MIP instead of
>>> relying on a
>>>>>>>>> solution that will:
>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>
>>>>>>>>>
>>>>>>>> We have no ability to specify changes to L2 anyway. However if
>>>>>>>> some L2s do have such capability, why would we not specify how
>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>
>>>>>>>>
>>>>>>> => Because we already have a solution that works in all L2s,
>>>>>>> doesn't require
>>>>>>> L2 changes that we don't control and doesn't cause
>>> confusing host
>>>>>>> config solutions.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> - Require additional SW and config on the host which
>>> is not done
>>>>>>>>> anywhere today, and
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Why is there as much of a concern about additional SW
>>> or config?
>>>>>>>> After all everything (or most of it anyway) that we do
>>> in the IETF
>>>>>>>> requires configurations, protocol changes, changes to SW etc.
>>>>>>>> There is nothing unique about this.
>>>>>>>>
>>>>>>>>
>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>> reasons for
>>>>>>> using PMIP in the first place. We can't have it both
>>> ways, or can
>>>>>>> we? :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>>>>> (informatively)
>>>>>>>> what L2 capabilities would enable these features if that is the
>>>>>>>> conclusion that we arrive at.
>>>>>>>>
>>>>>>>>
>>>>>>> => We can, but I don't know why we should do that when a
>>> solution
>>>>>>> already exists. Especially when the alternative is inferior in
>>>>>>> terms of its applicability.
>>>>>>>
>>>>>>> Hesham
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -Raj
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> This is why I think we should stick with the charter
>>> that Jari sent.
>>>>>>>>>
>>>>>>>>> Hesham
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I share the same view with respect to all your other
>>> comments.
>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>> basic handoff
>>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>>>>>>>>>> mobility and not the basic handoff cases supported
>>> today in 5213.
>>>>>>>>>> Sri
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: cjbc at it.uc3m.es (=?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?=)
Date: Tue, 7 Apr 2009 18:51:01 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Behcet,

I've quickly checked the document. I think it does address the same
problem I was referring to. This draft addresses the problem of
delegating a prefix to a router that attaches to a PMIPv6 domain, so
it can provide connectivity to nodes attached to it. I think this was
already discussed in a past meeting (a draft with the problem
statement) and I mentioned that IMHO this can basically be achieved by
just using plain NEMO support on the router. The only difference in
this draft is that it doesn't impose the router to be a NEMO RFC3963
MR, although still it needs to do some additional things that a normal
router (not mobile) doesn't. Anyway, I'm not against this type of
support if there are scenarios in which it's useful.

However, the kind of NEMO+PMIPv6 support I'm considering goes a little
bit beyond that, since what I want to enable is node to be able to
benefit from network based localised mobility support not only when
roaming between fixed points of attachment (this is what RFC5213 does
today) but also when roaming between fixed and mobile points of
attachment. What people do think about this scenario?

Thanks,

Carlos

2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> Hi Carlos,
> ? Check this out:
> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00
>
> Regards,
>
> Behcet
>
> ________________________________
> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> To: Jari Arkko <jari.arkko at piuha.net>
> Cc: netext at mail.mobileip.jp
> Sent: Tuesday, April 7, 2009 6:15:42 AM
> Subject: Re: [Netext] next steps for netext
>
> Hi Jari, all,
>
> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> personal view on that is that it'd be nice to extend PMIPv6 to support
> mobile networks. What I mean here is that it'd be nice to enable MAGs
> to also move (like MRs, but without even supporting RFC3963), so an MR
> would be able to move between fixed and mobile MAGs without changing
> its IP address (same support RFC5213 gives now). There are some
> interesting scenarios that could benefit from this.
>
> What do others think? It is interesting to work on this?
>
> Thanks,
>
> Carlos
>
> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
>> Sri,
>>
>> Thanks for your input. Inline:
>>
>>> I've a concern with the planned charter. The list is too random and
>>> cherry picked and I dont believe proper input from all the folks went
>>> into
>>> this. There are many other items that are required for a reasonable
>>> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
>>> years, some of them that were left out in the base spec, some that we
>>> realized as gaps when compared to other SDO protocols and some as
>>> optimizations that we realized while implementing PMIP6, these items
>>> should be in the initial scope.
>>>
>>> I understand the charter needs to be limited in scope, but just 3 or 4
>>> random items, I'm not sure if this helps in short term PMIP6
>>> requirements.
>>> I've no issue with the currently listed items, but there are other items
>>> that should get equal or higher priority.
>>
>> I have no problem with adding more. Even the charter says new things can
>> be
>> added.
>>
>> However, from a process perspective what I did was to take the proposal on
>> the table, i.e., the full BOF scope and see what parts of that we already
>> have an agreement on. I didn't include other things that were not
>> discussed
>> in the BOF. Maybe that would have been useful, but they were not on the
>> table.
>>
>> We could add more items now, if there's general agreement that those
>> things
>> are useful. However, I do not want to declare an open season on doing
>> everything. We pick a reasonable subset of all proposed work, based on
>> priorities, community agreement that they are the right things to do,
>> management reasons to ensure that we are not doing too much, etc.
>>
>>> For example, item #6, is absolutely required, from the perspective of
>>> having a complete specification of 5213. There we allowed a mobile node
>>> to
>>> perform handoff betweek two interfaces. We defined all the hooks on the
>>> network side, but we did not provide how a terminal vendor can support
>>> that. A simple informational draft on how some one move prefixes between
>>> interfaces will greatly help. Some guidance on how to create a virtual
>>> interface and also some related notes for each platform (Linux, BSD,
>>> Android ..etc). This should not fall in the controversial discussion
>>> scope
>>> of same address on two interfaces etc, thats a different problem, or
>>> about
>>> the issue of enhancing mobile node's capabilities. This is just
>>> informational work, required to leverage what 5213 already supports.
>>
>> I suspect this is about the scoping of the handoff work. Lets try to
>> figure
>> out what makes sense (I personally believe the above item makes sense, for
>> instance) and what doesn't.
>>
>> The fact that these parts were not in the charter was not a declaration
>> that
>> we're dismissing them. Its just that we didn't finish the discussion, but
>> I
>> still wanted to let the other things move forward.
>>
>>> Item #2, is required. The multimob BOF raised some issues, we need to
>>> show how multicast services can be enabled in PMIP network. May be this
>>> wont require extensions, a simple draft covering those aspects will help.
>>
>> As you may recall, in the Multimob BOF we did not have an agreement on
>> what
>> exactly is needed, if anything. My own conclusion is that we probably need
>> at least an informational document that explains how to use RFC 5213 for
>> multicast. I think we discussed the possibility of doing this as some kind
>> of AD sponsored document or in one of the relevant WGs, as a joint work
>> between PMIP and multicast experts.
>>
>> I'm on the fence about adding this work to the charter right now, mainly
>> because the BOF back then was very inconclusive. I'd be happier if I saw
>> an
>> actual well written draft from say you and some of the multicast experts.
>> There's no problem moving good documents forward, even if they are not in
>> the charter of some WG. Then again, I wouldn't necessarily mind a
>> maintenance like item for this in one of the WG charters either.
>>
>>> I think, the charter should be bit more relaxed and more extensive. As I
>>> see it, atleast the folks are interested in doing the work. We should add
>>> atleast 4 or 5 more items to this list.
>>
>> Generally speaking IETF WG charters give specific work items that the WG
>> should work on. I had hoped that the charter text:
>>
>> "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."
>>
>> gives an indication that we intend to do more! I am also personally very
>> happy to add more items to the group's charter. All in all, I do know that
>> the current charter is a bit on the thin side -- mostly because the
>> multihoming/interaccess issue is under discussion.
>>
>> There's also the question of general maintenance items. Some IETF WGs have
>> a
>> general work item to fix problems and issue updates to existing
>> specifications. I think we need to do that for Proxy Mobile IPv6 as well.
>> But we have not decided whether that item should go to NETLMM or NETEXT WG
>> yet. Please rest assured that the work will be possible regardless of
>> this.
>>
>>> 1. Dynamic LMA Assignment
>>>
>>> In blade architecture systems or in a load balancer configuration, the
>>> PDNGW
>>> should have the ability to dynamically assign a LMA on the fly, along the
>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>>> [RFC-4433].
>>> Currently, GTP provides such semantics and this is a important
>>> requirement
>>> for deployment. Here the goal is to
>>>
>>> a.) Expose a single IP address to the SGW
>>> b.) The exposed IP address should not be in path once the assignment is
>>> done.
>>>
>>>
>>>
>>> [LMA1]---
>>> | |
>>> [LMA2]--[LMA]==========[MAG]
>>> | |
>>> [LMA3]---
>>>
>>>
>>> Along the lines of:
>>>
>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>>
>> This is in the proposed NETEXT charter already.
>>
>>> 2. Multicast Support in Proxy Mobile IPv6
>>>
>>> We need an informational specification on how multicast support can be
>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>>> analysis
>>> on
>>> this. This is required and critical for enabling any multicast services.
>>> However,
>>> Behcet may disagree with the scope of the work.
>>
>> See above.
>>
>>> 3. Bulk Registration Support
>>>
>>> This is a simple extension which helps in signaling optimization, along
>>> the
>>> lines of:
>>>
>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>>
>> This is in the charter as well.
>>
>>> 4. Partial Failover Support
>>>
>>> We need a mechanism to notify the peer on revoke a partial set of
>>> bindings.
>>>
>>>
>>>
>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>>> txt
>>
>> Hmm. Ok. This needs more discussion.
>>
>>> 5. Group Identifier Support for Proxy Mobile IPv6
>>>
>>> This provides a simple and a generic semantic for assigning a group
>>> identifier
>>> to a mobile node's binding. GTP has very similar semantics, Connexion Set
>>> Id.
>>> Both #3 and #4 can leverage this. Additionally, in load balancer systems
>>> where
>>> the load balancer is in path for all signaling messages, it can use this
>>> as
>>> a
>>> tag for redirecting the message.
>>>
>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>>
>> Since the bulk registration work is in the charter, can't you do the
>> sensible design (whatever it is) under that? There is no requirement that
>> one charter item equals one document.
>>
>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>>> handoffs:
>>>
>>>
>>> RFC-5213 supports handoff between two interfaces. The ability to move
>>> prefixes between interfaces. In other words address continuity is assured
>>> with any IPv6 host on the planet and with absolutely no changes. This
>>> meets
>>> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>>> not assured is the aspect of session continuity. Which requires a virtual
>>> interface implementation on the host, by binding the address/prefix to a
>>> virtual interface and by not exposing the physical interface or by hiding
>>> the handoff events from the layer-3 stack.
>>>
>>> In essence, we need an informational specification which provides some
>>> general guidance to how to leverage the feature support provided in
>>> RFC-5213,
>>> along the lines of:
>>>
>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>>
>> This is part of the discussion that we need to finish. But I plan to let
>> the
>> rest of the stuff move forward even before we have done that.
>>
>>
>>> 7. Route Optimization for Proxy Mobile IPv6
>>>
>>> There were atleast 4 drafts in this area on Route Optimization. Marco
>>> Liebsch
>>> analyzed this exensively:
>>>
>>>
>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>>>
>>>
>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>>> txt
>>
>> This is in the charter.
>>
>>> 8. Prefix Management in Proxy Mobile IPv6 support
>>>
>>> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
>>> to a given mobile node's interface. It might be useful to specify how the
>>> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
>>> AAA to manage this aspect. Behcet has one draft on this.
>>
>> I'm not personally sold on this particular work. But again, this could be
>> something to consider.
>>
>>> 9. Partial Handoff Support
>>>
>>> We are missing some semantics in 5213 for moving a subset of the prefixes
>>> between interfaces as part of the inter-tech handoff. This is about
>>> defining
>>> a new handoff value. This allows partial flow management, but moving the
>>> flows associated to a prefix, as a whole group.
>>>
>>>
>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>>
>> A part of the topic we still need to discuss...
>>
>>> 10. CMIPv4/PMIP Interworking
>>>
>>> This is probably required to specify how an IPv4-only can move between
>>> CMIP and PMIP environments.
>>>
>>>
>>>
>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>>> meghana-netlmm-pmipv6-mipv4-00.txt
>>
>> Client MIPv6 and Proxy MIPv6 interoperability is already in the NETLMM
>> charter, but this work is presumably about interaction with MIPv4. Might
>> be
>> useful work, I wouldn't mind if this was done in NETEXT at some point. Is
>> this crucial to be in the first revision of the WG's charter?
>>
>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>>
>> Can you expand on this?
>>
>> Jari
>>
>> _______________________________________________
>> 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
>
>

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 09:10:59 -0700
Subject: [Netext] PMIP multihoming/flow mobility: a different perspective
Message-ID: <[email-masked]>

Hi all,

I would like to provide a different perspective on the discussion about the need of this work. Note that I am focusing only on the multihoming and flow mobility aspects of Netext and not on other issues. This perspective comes mainly from the discussion 3GPP had in the last 6 months, therefore it cannot be considered a complete analysis for the Internet but just an input to the discussion.

As many have mentioned, 3GPP is currently studying the possibility of standardizing flow mobility. After some initial broad scope discussion, the study is now focusing on two specific radio technologies, one being cellular and the other being WiFi. This restriction is not yet official but it is pretty clear from the discussion at the meetings, the inputs from operators and the contributions from companies. The motivation for this restriction is twofold: first this is the only scenario operators see as beneficial; second from a terminal point of view, this seems to be the only realistic assumption (i.e. two high power radios on at the same time do not seem feasible, acceptable or desirable).

As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated L2 signaling is needed between the MN and the MAG. However WiFi does not support any type of L2 signaling to enable this scenario and therefore PMIPv6 multihoming/flow mobility is not possible in the scenarios mentioned above (unless we change/enhance the L2 of 802.11 WLAN). 

In my opinion this boils down to the following point: if we look at deployment scenarios industry is looking at, a PMIPv6 solution for multihoming and flow mobility is basically not possible due to lack of support of L2 signaling in the accesses which are considered. Therefore the work proposed in Netext tends to be an academic exercise, rather than something really needed by the industry. At least this is what I think after having looked at this issue with other companies in the last 6 months.

Gerardo

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Tue, 7 Apr 2009 08:33:42 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

A couple of clarifications below.

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Domagoj Premec
> Sent: Tuesday, April 07, 2009 3:56 AM
> To: 'ext Hesham Soliman'; 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> Hi Hesham, all,
> 
> > What's being said here is "PMIP
> > doesn't support advanced cases therefore we need something
> > new", which is completely bogus because PMIP was not designed
> > to support those cases because we already have something else
> > for supporting those cases. Hence my reference to 4830...
> >
> 
> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. 

3GPP allows both PMIPv6 and DSMIPv6 for inter-access handover. PMIPv6 is used for LTE-eHRPD handovers and 3GPP2 designed a new link layer for eHRPD exactly because that was needed for PMIPv6. For example 3G-WLAN inter-system handover is only specified for DSMIPv6 in 3GPP. So let's be clear and stop claiming 3GPP needs PMIPv6 extensions.

On the WiMAX side, I know there are still open issues (discussed at the last 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6 working.

> Such
> large scale managed networks are the main consumers of PMIP6 so we shouldn't
> be ignoring what they're doing. 

This is mainly true for intra-technology mobility - and note that I am considering LTE-eHRPD intra-technology here as they are homogeneous from a link layer point of view.

Gerardo

> Saying to use MIP for inter-access
> handovers/multihoming is not helping as they have really set their mind on
> using PMIP6 and they're already doing this. Without going into the reasoning
> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
> issues with inter-access handovers. I think it is better to fix those PMIP6
> issues in the IETF then to let each SDO come up with their own way of
> dealing with this.
> 
> domagoj
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> > Hesham Soliman
> > Sent: 07. travanj 2009 11:14
> > To: Marco Liebsch
> > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > Subject: Re: [Netext] next steps for netext
> >
> >
> > >> => We're discussing a problem statement for the BoF, so
> > 4830 is quite
> > >> appropriate as a reference for why people wanted PMIP in
> > the first place.
> > >>
> > > Yes, a problem statement about an existing solution for
> > network-based
> > > mobility management (PMIPv6) to support advanced use cases.
> >
> > => Where is that PS?
> >
> >   Not the problem of
> > > existing solutions for localized mobility, as RFC4830 does. I don't
> > > think NetExt aims at turning PMIPv6 into a host-based mobility
> > > protocol again.
> >
> > => I don't know what the goal is based on the BoF discussion
> > and this discussion on the list. The reason I don't know that
> > is that no one is
> > saying:
> > Here is the state of the art (including BOTH MIP and PMIP)
> > and here is why they don't work, therefore we need to do
> > something new.
> > That's what a PS should say. What's being said here is "PMIP
> > doesn't support advanced cases therefore we need something
> > new", which is completely bogus because PMIP was not designed
> > to support those cases because we already have something else
> > for supporting those cases. Hence my reference to 4830...
> >
> > I'm going to retire from the discussion till someone makes
> > the argument above. Because I feel that if there is no such
> > argument then the discussion is not a good use of time.
> >
> >
> > >> => Yes, additional software like the existing MIP. I don't
> > understand
> > >> the motivation for creating something new. I've detailed
> > this in my
> > >> previous emails and the points remain unanswered.
> > >>
> > > Nobody talks about adding a piece of client mobility management
> > > software, such as a MIP client, to the mobile. That seems to be a
> > > wrong interpretation of what NetExt wants to do.
> >
> > => You're missing the point. Why isn't anybody talking about
> > MIP??? That's what a PS should say.
> >
> > Hesham
> >
> > >
> > > marco
> > >
> > >
> > >> Hesham
> > >>
> > >>
> > >> and obviously also according to RFC4831. We should
> > >>
> > >>> distinguish modification for mobility management, which
> > is not what
> > >>> we want to do, and enabling local functions, such as the use of
> > >>> multiple interfaces, where you have to add routes, configure
> > >>> interfaces etc. to enable the use case.
> > >>>
> > >>> marco
> > >>>
> > >>>
> > >>> Hesham Soliman schrieb:
> > >>>
> > >>>>
> > >>>>
> > >>>>>> => I think you're distinguishing between modified and
> > unmodified
> > >>>>>> based on whether the modification affects IETF
> > protocols or not.
> > >>>>>> That's fine, but for those that did not attend the BoF, our
> > >>>>>> conclusions were that you will either end up modifying
> > the host
> > >>>>>> (i.e. Adding new SW) and adding new signalling on
> > >>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
> > >>>>>> My opinion, and at least half the room's was that this
> > is not a
> > >>>>>> good way to
> > >>>>>>
> > >>>>>>
> > >>>>> We can discuss what implies host changes and why this is such a
> > >>>>> big deal anyway. But I don't think that half the room was in
> > >>>>> agreement as such. At least from the count of hands
> > raised for the
> > >>>>> question about whether we should work on multihoming
> > and intertech
> > >>>>> handovers it was about 18-9 (in favor).
> > >>>>>
> > >>>>>
> > >>>> => I think the question changed a few times :) The final
> > question
> > >>>> (which was specific to whether people wanted to work
> > with this or
> > >>>> not) showed a split room.
> > >>>> The host changes are not a big deal but they are mentioned here
> > >>>> because they were one of the very few reasons for using
> > NETLMM in
> > >>>> the first place: Host changes (adding new SW to the host) and
> > >>>> signalling from the MN. You can see them in section 4 of
> > RFC 4830.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>> go and that it's better to stick with MIP instead of
> > relying on a
> > >>>>>> solution that will:
> > >>>>>> - work on some L2s and not others,
> > >>>>>>
> > >>>>>>
> > >>>>> We have no ability to specify changes to L2 anyway. However if
> > >>>>> some L2s do have such capability, why would we not specify how
> > >>>>> multihoming would work in such scenarios.
> > >>>>>
> > >>>>>
> > >>>> => Because we already have a solution that works in all L2s,
> > >>>> doesn't require
> > >>>> L2 changes that we don't control and doesn't cause
> > confusing host
> > >>>> config solutions.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>> - Require additional SW and config on the host which
> > is not done
> > >>>>>> anywhere today, and
> > >>>>>>
> > >>>>>>
> > >>>>> Why is there as much of a concern about additional SW
> > or config?
> > >>>>> After all everything (or most of it anyway) that we do
> > in the IETF
> > >>>>> requires configurations, protocol changes, changes to SW etc.
> > >>>>> There is nothing unique about this.
> > >>>>>
> > >>>>>
> > >>>> => Sure, but see above and see RFC 4830. These were the
> > reasons for
> > >>>> using PMIP in the first place. We can't have it both
> > ways, or can
> > >>>> we? :)
> > >>>>
> > >>>>
> > >>>>
> > >>>>>> - Require L2 signalling which is out of our scope in IETF
> > >>>>>>
> > >>>>>>
> > >>>>> Agree. We cannot do anything about L2s. But we could specify
> > >>>>> (informatively)
> > >>>>> what L2 capabilities would enable these features if that is the
> > >>>>> conclusion that we arrive at.
> > >>>>>
> > >>>>>
> > >>>> => We can, but I don't know why we should do that when a
> > solution
> > >>>> already exists. Especially when the alternative is inferior in
> > >>>> terms of its applicability.
> > >>>>
> > >>>> Hesham
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -Raj
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> This is why I think we should stick with the charter
> > that Jari sent.
> > >>>>>>
> > >>>>>>
> > >>>>>> Hesham
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> I share the same view with respect to all your other
> > comments.
> > >>>>>>> We need to seperate the cases of flow mobility vs
> > basic handoff
> > >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
> > >>>>>>> mobility and not the basic handoff cases supported
> > today in 5213.
> > >>>>>>>
> > >>>>>>> Sri
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> 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
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> > _______________________________________________
> > 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

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Tue, 7 Apr 2009 08:08:11 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Carlos,
? Check this out:
http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-support-00

Regards,

Behcet

________________________________
From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
To: Jari Arkko <jari.arkko at piuha.net>
Cc: netext at mail.mobileip.jp
Sent: Tuesday, April 7, 2009 6:15:42 AM
Subject: Re: [Netext] next steps for netext

Hi Jari, all,

Regarding the NEMO topic, I don't know what Sri has in mind, but my
personal view on that is that it'd be nice to extend PMIPv6 to support
mobile networks. What I mean here is that it'd be nice to enable MAGs
to also move (like MRs, but without even supporting RFC3963), so an MR
would be able to move between fixed and mobile MAGs without changing
its IP address (same support RFC5213 gives now). There are some
interesting scenarios that could benefit from this.

What do others think? It is interesting to work on this?

Thanks,

Carlos

2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> Sri,
>
> Thanks for your input. Inline:
>
>> I've a concern with the planned charter. The list is too random and
>> cherry picked and I dont believe proper input from all the folks went into
>> this. There are many other items that are required for a reasonable
>> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
>> years, some of them that were left out in the base spec, some that we
>> realized as gaps when compared to other SDO protocols and some as
>> optimizations that we realized while implementing PMIP6, these items
>> should be in the initial scope.
>>
>> I understand the charter needs to be limited in scope, but just 3 or 4
>> random items, I'm not sure if this helps in short term PMIP6 requirements.
>> I've no issue with the currently listed items, but there are other items
>> that should get equal or higher priority.
>
> I have no problem with adding more. Even the charter says new things can be
> added.
>
> However, from a process perspective what I did was to take the proposal on
> the table, i.e., the full BOF scope and see what parts of that we already
> have an agreement on. I didn't include other things that were not discussed
> in the BOF. Maybe that would have been useful, but they were not on the
> table.
>
> We could add more items now, if there's general agreement that those things
> are useful. However, I do not want to declare an open season on doing
> everything. We pick a reasonable subset of all proposed work, based on
> priorities, community agreement that they are the right things to do,
> management reasons to ensure that we are not doing too much, etc.
>
>> For example, item #6, is absolutely required, from the perspective of
>> having a complete specification of 5213. There we allowed a mobile node to
>> perform handoff betweek two interfaces. We defined all the hooks on the
>> network side, but we did not provide how a terminal vendor can support
>> that. A simple informational draft on how some one move prefixes between
>> interfaces will greatly help. Some guidance on how to create a virtual
>> interface and also some related notes for each platform (Linux, BSD,
>> Android ..etc). This should not fall in the controversial discussion scope
>> of same address on two interfaces etc, thats a different problem, or about
>> the issue of enhancing mobile node's capabilities. This is just
>> informational work, required to leverage what 5213 already supports.
>
> I suspect this is about the scoping of the handoff work. Lets try to figure
> out what makes sense (I personally believe the above item makes sense, for
> instance) and what doesn't.
>
> The fact that these parts were not in the charter was not a declaration that
> we're dismissing them. Its just that we didn't finish the discussion, but I
> still wanted to let the other things move forward.
>
>> Item #2, is required. The multimob BOF raised some issues, we need to
>> show how multicast services can be enabled in PMIP network. May be this
>> wont require extensions, a simple draft covering those aspects will help.
>
> As you may recall, in the Multimob BOF we did not have an agreement on what
> exactly is needed, if anything. My own conclusion is that we probably need
> at least an informational document that explains how to use RFC 5213 for
> multicast. I think we discussed the possibility of doing this as some kind
> of AD sponsored document or in one of the relevant WGs, as a joint work
> between PMIP and multicast experts.
>
> I'm on the fence about adding this work to the charter right now, mainly
> because the BOF back then was very inconclusive. I'd be happier if I saw an
> actual well written draft from say you and some of the multicast experts.
> There's no problem moving good documents forward, even if they are not in
> the charter of some WG. Then again, I wouldn't necessarily mind a
> maintenance like item for this in one of the WG charters either.
>
>> I think, the charter should be bit more relaxed and more extensive. As I
>> see it, atleast the folks are interested in doing the work. We should add
>> atleast 4 or 5 more items to this list.
>
> Generally speaking IETF WG charters give specific work items that the WG
> should work on. I had hoped that the charter text:
>
> "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."
>
> gives an indication that we intend to do more! I am also personally very
> happy to add more items to the group's charter. All in all, I do know that
> the current charter is a bit on the thin side -- mostly because the
> multihoming/interaccess issue is under discussion.
>
> There's also the question of general maintenance items. Some IETF WGs have a
> general work item to fix problems and issue updates to existing
> specifications. I think we need to do that for Proxy Mobile IPv6 as well.
> But we have not decided whether that item should go to NETLMM or NETEXT WG
> yet. Please rest assured that the work will be possible regardless of this.
>
>> 1. Dynamic LMA Assignment
>>
>> In blade architecture systems or in a load balancer configuration, the
>> PDNGW
>> should have the ability to dynamically assign a LMA on the fly, along the
>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>> [RFC-4433].
>> Currently, GTP provides such semantics and this is a important requirement
>> for deployment. Here the goal is to
>>
>> a.) Expose a single IP address to the SGW
>> b.) The exposed IP address should not be in path once the assignment is
>> done.
>>
>>
>>
>> [LMA1]---
>> | |
>> [LMA2]--[LMA]==========[MAG]
>> | |
>> [LMA3]---
>>
>>
>> Along the lines of:
>>
>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>
> This is in the proposed NETEXT charter already.
>
>> 2. Multicast Support in Proxy Mobile IPv6
>>
>> We need an informational specification on how multicast support can be
>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>> analysis
>> on
>> this. This is required and critical for enabling any multicast services.
>> However,
>> Behcet may disagree with the scope of the work.
>
> See above.
>
>> 3. Bulk Registration Support
>>
>> This is a simple extension which helps in signaling optimization, along
>> the
>> lines of:
>>
>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>
> This is in the charter as well.
>
>> 4. Partial Failover Support
>>
>> We need a mechanism to notify the peer on revoke a partial set of
>> bindings.
>>
>>
>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>> txt
>
> Hmm. Ok. This needs more discussion.
>
>> 5. Group Identifier Support for Proxy Mobile IPv6
>>
>> This provides a simple and a generic semantic for assigning a group
>> identifier
>> to a mobile node's binding. GTP has very similar semantics, Connexion Set
>> Id.
>> Both #3 and #4 can leverage this. Additionally, in load balancer systems
>> where
>> the load balancer is in path for all signaling messages, it can use this
>> as
>> a
>> tag for redirecting the message.
>>
>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
> Since the bulk registration work is in the charter, can't you do the
> sensible design (whatever it is) under that? There is no requirement that
> one charter item equals one document.
>
>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>> handoffs:
>>
>>
>> RFC-5213 supports handoff between two interfaces. The ability to move
>> prefixes between interfaces. In other words address continuity is assured
>> with any IPv6 host on the planet and with absolutely no changes. This
>> meets
>> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>> not assured is the aspect of session continuity. Which requires a virtual
>> interface implementation on the host, by binding the address/prefix to a
>> virtual interface and by not exposing the physical interface or by hiding
>> the handoff events from the layer-3 stack.
>>
>> In essence, we need an informational specification which provides some
>> general guidance to how to leverage the feature support provided in
>> RFC-5213,
>> along the lines of:
>>
>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
> This is part of the discussion that we need to finish. But I plan to let the
> rest of the stuff move forward even before we have done that.
>
>
>> 7. Route Optimization for Proxy Mobile IPv6
>>
>> There were atleast 4 drafts in this area on Route Optimization. Marco
>> Liebsch
>> analyzed this exensively:
>>
>>
>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>>
>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>> txt
>
> This is in the charter.
>
>> 8. Prefix Management in Proxy Mobile IPv6 support
>>
>> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
>> to a given mobile node's interface. It might be useful to specify how the
>> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
>> AAA to manage this aspect. Behcet has one draft on this.
>
> I'm not personally sold on this particular work. But again, this could be
> something to consider.
>
>> 9. Partial Handoff Support
>>
>> We are missing some semantics in 5213 for moving a subset of the prefixes
>> between interfaces as part of the inter-tech handoff. This is about
>> defining
>> a new handoff value. This allows partial flow management, but moving the
>> flows associated to a prefix, as a whole group.
>>
>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>
> A part of the topic we still need to discuss...
>
>> 10. CMIPv4/PMIP Interworking
>>
>> This is probably required to specify how an IPv4-only can move between
>> CMIP and PMIP environments.
>>
>>
>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>> meghana-netlmm-pmipv6-mipv4-00.txt
>
> Client MIPv6 and Proxy MIPv6 interoperability is already in the NETLMM
> charter, but this work is presumably about interaction with MIPv4. Might be
> useful work, I wouldn't mind if this was done in NETEXT at some point. Is
> this crucial to be in the first revision of the WG's charter?
>
>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
> Can you expand on this?
>
> Jari
>
> _______________________________________________
> 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

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/c31342ed/attachment-0001.html>

From: conny.larsson at ericsson.com (Conny Larsson)
Date: Tue, 07 Apr 2009 16:03:04 +0200
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi George,

I agree with your conclusion and I believe that the important thing for 
the IETF community to answer is how far we should take the PMIPv6 protocol.

The question asked at the end of the Netext BOF was whether people 
believe that CMIP or PMIP should be used to solve the multi-homing 
problem (the final question asked by Jari). There was no rough consensus 
about this in either direction.

As I see it there are two options regarding multi-homing and flow 
mobility support for PMIPv6: Either PMIPv6 is transparent for the host 
and everything is handled by CMIP and associated protocols (this is 
something that has been standardized in the mext WG), or necessary 
additions are made to the PMIPv6 protocol and the host to support it. We 
wrote an Internet draft 
(http://tools.ietf.org/html/draft-larsson-netext-pmipv6-sma-flow-mobility-00) 
were we tried to give an idea of how such a solution could look like for 
PMIPv6. This requires modifications of the host in the sense that 
distributions of outgoing flows over different network interfaces must 
be handled by the host.

Regards
Conny Larsson

George Tsirtsis wrote:
> Folks,
>
> What people keep missing is that 3GPP, 3GPP2, WiMax etc, are all
> PROPRIETARY systems as far as the IETF is concerned. The IETF is
> tasked with making sure that the Internet as a whole holds together.
> The IETF should only standardise protocols/tools requested by SDOs if
> they do not cause harm to the general Internet. This is paramount for
> the long term sustainability of the Internet.
>
> Independently from "architectural" viewpoints, it is perfectly
> reasonable for a given SDO to decide to implement a given technology
> (e.g., PMIP) in their CLOSED System. PMIP for example can work in the
> context of 3GPP (as GTP did for many years) since they define a
> vertical system, from PHY and LINK layers, to Network and even
> Application layers. In that case, they are free to, for example,
> implement whatever Link Layer triggers are necessary to make PMIP work
> in their system.
>
> It is another thing altogether, however, for the IETF to standardise
> such a technology, when here we do not have control over link layers.
> On the contrary what the IETF and the Internet are based on is an
> explicit assumption that "any" link layer should work with minimum
> requirements from the IP layer, all of which are described in host
> requirements
>
> What PMIP proponents have been asking the IETF to do is define a
> technology that will break an RFC4294 host.
> This is simply not acceptable.
>
> George
>
> On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec
> <domagoj.premec.ext at nsn.com> wrote:
>   
>> Hi Hesham, all,
>>
>>     
>>> What's being said here is "PMIP
>>> doesn't support advanced cases therefore we need something
>>> new", which is completely bogus because PMIP was not designed
>>> to support those cases because we already have something else
>>> for supporting those cases. Hence my reference to 4830...
>>>
>>>       
>> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. Such
>> large scale managed networks are the main consumers of PMIP6 so we shouldn't
>> be ignoring what they're doing. Saying to use MIP for inter-access
>> handovers/multihoming is not helping as they have really set their mind on
>> using PMIP6 and they're already doing this. Without going into the reasoning
>> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
>> issues with inter-access handovers. I think it is better to fix those PMIP6
>> issues in the IETF then to let each SDO come up with their own way of
>> dealing with this.
>>
>> domagoj
>>
>>
>>     
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>> Hesham Soliman
>>> Sent: 07. travanj 2009 11:14
>>> To: Marco Liebsch
>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] next steps for netext
>>>
>>>
>>>       
>>>>> => We're discussing a problem statement for the BoF, so
>>>>>           
>>> 4830 is quite
>>>       
>>>>> appropriate as a reference for why people wanted PMIP in
>>>>>           
>>> the first place.
>>>       
>>>> Yes, a problem statement about an existing solution for
>>>>         
>>> network-based
>>>       
>>>> mobility management (PMIPv6) to support advanced use cases.
>>>>         
>>> => Where is that PS?
>>>
>>> ?  Not the problem of
>>>       
>>>> existing solutions for localized mobility, as RFC4830 does. I don't
>>>> think NetExt aims at turning PMIPv6 into a host-based mobility
>>>> protocol again.
>>>>         
>>> => I don't know what the goal is based on the BoF discussion
>>> and this discussion on the list. The reason I don't know that
>>> is that no one is
>>> saying:
>>> Here is the state of the art (including BOTH MIP and PMIP)
>>> and here is why they don't work, therefore we need to do
>>> something new.
>>> That's what a PS should say. What's being said here is "PMIP
>>> doesn't support advanced cases therefore we need something
>>> new", which is completely bogus because PMIP was not designed
>>> to support those cases because we already have something else
>>> for supporting those cases. Hence my reference to 4830...
>>>
>>> I'm going to retire from the discussion till someone makes
>>> the argument above. Because I feel that if there is no such
>>> argument then the discussion is not a good use of time.
>>>
>>>
>>>       
>>>>> => Yes, additional software like the existing MIP. I don't
>>>>>           
>>> understand
>>>       
>>>>> the motivation for creating something new. I've detailed
>>>>>           
>>> this in my
>>>       
>>>>> previous emails and the points remain unanswered.
>>>>>
>>>>>           
>>>> Nobody talks about adding a piece of client mobility management
>>>> software, such as a MIP client, to the mobile. That seems to be a
>>>> wrong interpretation of what NetExt wants to do.
>>>>         
>>> => You're missing the point. Why isn't anybody talking about
>>> MIP??? That's what a PS should say.
>>>
>>> Hesham
>>>
>>>       
>>>> marco
>>>>
>>>>
>>>>         
>>>>> Hesham
>>>>>
>>>>>
>>>>> and obviously also according to RFC4831. We should
>>>>>
>>>>>           
>>>>>> distinguish modification for mobility management, which
>>>>>>             
>>> is not what
>>>       
>>>>>> we want to do, and enabling local functions, such as the use of
>>>>>> multiple interfaces, where you have to add routes, configure
>>>>>> interfaces etc. to enable the use case.
>>>>>>
>>>>>> marco
>>>>>>
>>>>>>
>>>>>> Hesham Soliman schrieb:
>>>>>>
>>>>>>             
>>>>>>>               
>>>>>>>>> => I think you're distinguishing between modified and
>>>>>>>>>                   
>>> unmodified
>>>       
>>>>>>>>> based on whether the modification affects IETF
>>>>>>>>>                   
>>> protocols or not.
>>>       
>>>>>>>>> That's fine, but for those that did not attend the BoF, our
>>>>>>>>> conclusions were that you will either end up modifying
>>>>>>>>>                   
>>> the host
>>>       
>>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>>>>> My opinion, and at least half the room's was that this
>>>>>>>>>                   
>>> is not a
>>>       
>>>>>>>>> good way to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> We can discuss what implies host changes and why this is such a
>>>>>>>> big deal anyway. But I don't think that half the room was in
>>>>>>>> agreement as such. At least from the count of hands
>>>>>>>>                 
>>> raised for the
>>>       
>>>>>>>> question about whether we should work on multihoming
>>>>>>>>                 
>>> and intertech
>>>       
>>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> => I think the question changed a few times :) The final
>>>>>>>               
>>> question
>>>       
>>>>>>> (which was specific to whether people wanted to work
>>>>>>>               
>>> with this or
>>>       
>>>>>>> not) showed a split room.
>>>>>>> The host changes are not a big deal but they are mentioned here
>>>>>>> because they were one of the very few reasons for using
>>>>>>>               
>>> NETLMM in
>>>       
>>>>>>> the first place: Host changes (adding new SW to the host) and
>>>>>>> signalling from the MN. You can see them in section 4 of
>>>>>>>               
>>> RFC 4830.
>>>       
>>>>>>>
>>>>>>>               
>>>>>>>>> go and that it's better to stick with MIP instead of
>>>>>>>>>                   
>>> relying on a
>>>       
>>>>>>>>> solution that will:
>>>>>>>>> - work on some L2s and not others,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> We have no ability to specify changes to L2 anyway. However if
>>>>>>>> some L2s do have such capability, why would we not specify how
>>>>>>>> multihoming would work in such scenarios.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> => Because we already have a solution that works in all L2s,
>>>>>>> doesn't require
>>>>>>> L2 changes that we don't control and doesn't cause
>>>>>>>               
>>> confusing host
>>>       
>>>>>>> config solutions.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> - Require additional SW and config on the host which
>>>>>>>>>                   
>>> is not done
>>>       
>>>>>>>>> anywhere today, and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Why is there as much of a concern about additional SW
>>>>>>>>                 
>>> or config?
>>>       
>>>>>>>> After all everything (or most of it anyway) that we do
>>>>>>>>                 
>>> in the IETF
>>>       
>>>>>>>> requires configurations, protocol changes, changes to SW etc.
>>>>>>>> There is nothing unique about this.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> => Sure, but see above and see RFC 4830. These were the
>>>>>>>               
>>> reasons for
>>>       
>>>>>>> using PMIP in the first place. We can't have it both
>>>>>>>               
>>> ways, or can
>>>       
>>>>>>> we? :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>>>>> (informatively)
>>>>>>>> what L2 capabilities would enable these features if that is the
>>>>>>>> conclusion that we arrive at.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> => We can, but I don't know why we should do that when a
>>>>>>>               
>>> solution
>>>       
>>>>>>> already exists. Especially when the alternative is inferior in
>>>>>>> terms of its applicability.
>>>>>>>
>>>>>>> Hesham
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> -Raj
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> This is why I think we should stick with the charter
>>>>>>>>>                   
>>> that Jari sent.
>>>       
>>>>>>>>> Hesham
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> I share the same view with respect to all your other
>>>>>>>>>>                     
>>> comments.
>>>       
>>>>>>>>>> We need to seperate the cases of flow mobility vs
>>>>>>>>>>                     
>>> basic handoff
>>>       
>>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>>>>>>>>>> mobility and not the basic handoff cases supported
>>>>>>>>>>                     
>>> today in 5213.
>>>       
>>>>>>>>>> Sri
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>
>>>>>           
>>>>         
>>> _______________________________________________
>>> 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
>>
>>     
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/bc14e033/attachment-0001.html>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 7 Apr 2009 15:36:57 +0200
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

George,

Yes, I guess one could look at it from this perspective, too.  I was hoping that IETF would look into the issues first and then come up with an opinion what is the best way to deal with them. It may very well turn out that the conclusion is to address those issues at the link layer, but before that decision is taken I'd like to see an analysis document listing pros and cons of each approach and then recommending the best way to move forward.

Domagoj

> -----Original Message-----
> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com] 
> Sent: 07. travanj 2009 14:34
> To: Domagoj Premec
> Cc: ext Hesham Soliman; Marco Liebsch; 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: Keep missing the point .. Re: [Netext] next 
> steps for netext
> 
> Domagoj,
> 
> Its not like this. These SDOs are explicitly bringing 
> specific technologies under their system architecture. So for 
> example 3GPP defines in Rel9 how movement between 3GPP and 
> specific non-3GPP systems might work using MIP and PMIP. 
> Again the point is that they are defining a closed system, 
> with freedom to affect any layer they want and are totally 
> unconcerned with any technologies (e.g. other link layers) 
> that are not explicitly defined in their system. They are 
> also free to force any requirements they want to devices that 
> want to be called 3GPP-compliant.
> 
> George
> 
> On Tue, Apr 7, 2009 at 1:19 PM, Domagoj Premec 
> <domagoj.premec.ext at nsn.com> wrote:
> > My point is that this is an issue *between different 
> systems*. Those other SDOs are going to use PMIP for 
> *inter-system* handovers, and since this goes beyond the 
> scope of the single SDO, I think that IETF is a proper place 
> to deal with this.
> >
> > From the discussion we're having it seems that the analysis 
> document exploring the PMIPv6 in the context of the 
> inter-access mobility seems like a worthwile effort. If PMIP6 
> in this context is found to be harmful to the general 
> Internet, then IMO we should have an IETF document stating this.
> >
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com]
> >> Sent: 07. travanj 2009 13:27
> >> To: Domagoj Premec
> >> Cc: ext Hesham Soliman; Marco Liebsch; netext at mail.mobileip.jp; 
> >> Basavaraj.Patil at nokia.com
> >> Subject: Keep missing the point .. Re: [Netext] next steps 
> for netext
> >>
> >> Folks,
> >>
> >> What people keep missing is that 3GPP, 3GPP2, WiMax etc, are all 
> >> PROPRIETARY systems as far as the IETF is concerned. The IETF is 
> >> tasked with making sure that the Internet as a whole holds 
> together.
> >> The IETF should only standardise protocols/tools requested 
> by SDOs if 
> >> they do not cause harm to the general Internet. This is 
> paramount for 
> >> the long term sustainability of the Internet.
> >>
> >> Independently from "architectural" viewpoints, it is perfectly 
> >> reasonable for a given SDO to decide to implement a given 
> technology 
> >> (e.g., PMIP) in their CLOSED System. PMIP for example can 
> work in the 
> >> context of 3GPP (as GTP did for many years) since they define a 
> >> vertical system, from PHY and LINK layers, to Network and even 
> >> Application layers. In that case, they are free to, for example, 
> >> implement whatever Link Layer triggers are necessary to make PMIP 
> >> work in their system.
> >>
> >> It is another thing altogether, however, for the IETF to 
> standardise 
> >> such a technology, when here we do not have control over 
> link layers.
> >> On the contrary what the IETF and the Internet are based on is an 
> >> explicit assumption that "any" link layer should work with minimum 
> >> requirements from the IP layer, all of which are described in host 
> >> requirements
> >>
> >> What PMIP proponents have been asking the IETF to do is define a 
> >> technology that will break an RFC4294 host.
> >> This is simply not acceptable.
> >>
> >> George
> >>
> >> On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec 
> >> <domagoj.premec.ext at nsn.com> wrote:
> >> > Hi Hesham, all,
> >> >
> >> >> What's being said here is "PMIP
> >> >> doesn't support advanced cases therefore we need 
> something new", 
> >> >> which is completely bogus because PMIP was not designed 
> to support 
> >> >> those cases because we already have something else for 
> supporting 
> >> >> those cases. Hence my reference to 4830...
> >> >>
> >> >
> >> > Both 3GPP and WiMAX adopted PMIP6 as means for inter-access
> >> handover.
> >> > Such large scale managed networks are the main consumers of
> >> PMIP6 so
> >> > we shouldn't be ignoring what they're doing. Saying to 
> use MIP for 
> >> > inter-access handovers/multihoming is not helping as they
> >> have really
> >> > set their mind on using PMIP6 and they're already doing
> >> this. Without
> >> > going into the reasoning behind such a decision, the 
> fact is that 
> >> > PMIP6, as defined in RFC 5213, has issues with inter-access
> >> handovers.
> >> > I think it is better to fix those PMIP6 issues in the IETF
> >> then to let
> >> > each SDO come up with their own way of dealing with this.
> >> >
> >> > domagoj
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: netext-bounces at mail.mobileip.jp 
> >> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> ext Hesham 
> >> >> Soliman
> >> >> Sent: 07. travanj 2009 11:14
> >> >> To: Marco Liebsch
> >> >> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >> >> Subject: Re: [Netext] next steps for netext
> >> >>
> >> >>
> >> >> >> => We're discussing a problem statement for the BoF, so
> >> >> 4830 is quite
> >> >> >> appropriate as a reference for why people wanted PMIP in
> >> >> the first place.
> >> >> >>
> >> >> > Yes, a problem statement about an existing solution for
> >> >> network-based
> >> >> > mobility management (PMIPv6) to support advanced use cases.
> >> >>
> >> >> => Where is that PS?
> >> >>
> >> >>   Not the problem of
> >> >> > existing solutions for localized mobility, as RFC4830
> >> does. I don't
> >> >> > think NetExt aims at turning PMIPv6 into a host-based 
> mobility 
> >> >> > protocol again.
> >> >>
> >> >> => I don't know what the goal is based on the BoF
> >> discussion and this
> >> >> discussion on the list. The reason I don't know that is
> >> that no one
> >> >> is
> >> >> saying:
> >> >> Here is the state of the art (including BOTH MIP and PMIP)
> >> and here
> >> >> is why they don't work, therefore we need to do something new.
> >> >> That's what a PS should say. What's being said here is
> >> "PMIP doesn't
> >> >> support advanced cases therefore we need something 
> new", which is 
> >> >> completely bogus because PMIP was not designed to support
> >> those cases
> >> >> because we already have something else for supporting 
> those cases.
> >> >> Hence my reference to 4830...
> >> >>
> >> >> I'm going to retire from the discussion till someone makes the 
> >> >> argument above. Because I feel that if there is no such
> >> argument then
> >> >> the discussion is not a good use of time.
> >> >>
> >> >>
> >> >> >> => Yes, additional software like the existing MIP. I don't
> >> >> understand
> >> >> >> the motivation for creating something new. I've detailed
> >> >> this in my
> >> >> >> previous emails and the points remain unanswered.
> >> >> >>
> >> >> > Nobody talks about adding a piece of client mobility 
> management 
> >> >> > software, such as a MIP client, to the mobile. That
> >> seems to be a
> >> >> > wrong interpretation of what NetExt wants to do.
> >> >>
> >> >> => You're missing the point. Why isn't anybody talking
> >> about MIP???
> >> >> That's what a PS should say.
> >> >>
> >> >> Hesham
> >> >>
> >> >> >
> >> >> > marco
> >> >> >
> >> >> >
> >> >> >> Hesham
> >> >> >>
> >> >> >>
> >> >> >> and obviously also according to RFC4831. We should
> >> >> >>
> >> >> >>> distinguish modification for mobility management, which
> >> >> is not what
> >> >> >>> we want to do, and enabling local functions, such as
> >> the use of
> >> >> >>> multiple interfaces, where you have to add routes, 
> configure 
> >> >> >>> interfaces etc. to enable the use case.
> >> >> >>>
> >> >> >>> marco
> >> >> >>>
> >> >> >>>
> >> >> >>> Hesham Soliman schrieb:
> >> >> >>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>>> => I think you're distinguishing between modified and
> >> >> unmodified
> >> >> >>>>>> based on whether the modification affects IETF
> >> >> protocols or not.
> >> >> >>>>>> That's fine, but for those that did not attend 
> the BoF, our 
> >> >> >>>>>> conclusions were that you will either end up modifying
> >> >> the host
> >> >> >>>>>> (i.e. Adding new SW) and adding new signalling on
> >> >> >>>>>> L2 to handle the multihoming cases, or you can
> >> stick with MIP.
> >> >> >>>>>> My opinion, and at least half the room's was that this
> >> >> is not a
> >> >> >>>>>> good way to
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>> We can discuss what implies host changes and why
> >> this is such a
> >> >> >>>>> big deal anyway. But I don't think that half the 
> room was in 
> >> >> >>>>> agreement as such. At least from the count of hands
> >> >> raised for the
> >> >> >>>>> question about whether we should work on multihoming
> >> >> and intertech
> >> >> >>>>> handovers it was about 18-9 (in favor).
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>> => I think the question changed a few times :) The final
> >> >> question
> >> >> >>>> (which was specific to whether people wanted to work
> >> >> with this or
> >> >> >>>> not) showed a split room.
> >> >> >>>> The host changes are not a big deal but they are
> >> mentioned here
> >> >> >>>> because they were one of the very few reasons for using
> >> >> NETLMM in
> >> >> >>>> the first place: Host changes (adding new SW to 
> the host) and 
> >> >> >>>> signalling from the MN. You can see them in section 4 of
> >> >> RFC 4830.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>>> go and that it's better to stick with MIP instead of
> >> >> relying on a
> >> >> >>>>>> solution that will:
> >> >> >>>>>> - work on some L2s and not others,
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>> We have no ability to specify changes to L2 anyway.
> >> However if
> >> >> >>>>> some L2s do have such capability, why would we not
> >> specify how
> >> >> >>>>> multihoming would work in such scenarios.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>> => Because we already have a solution that works 
> in all L2s, 
> >> >> >>>> doesn't require
> >> >> >>>> L2 changes that we don't control and doesn't cause
> >> >> confusing host
> >> >> >>>> config solutions.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>>> - Require additional SW and config on the host which
> >> >> is not done
> >> >> >>>>>> anywhere today, and
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>> Why is there as much of a concern about additional SW
> >> >> or config?
> >> >> >>>>> After all everything (or most of it anyway) that we do
> >> >> in the IETF
> >> >> >>>>> requires configurations, protocol changes, 
> changes to SW etc.
> >> >> >>>>> There is nothing unique about this.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>> => Sure, but see above and see RFC 4830. These were the
> >> >> reasons for
> >> >> >>>> using PMIP in the first place. We can't have it both
> >> >> ways, or can
> >> >> >>>> we? :)
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>>> - Require L2 signalling which is out of our scope in IETF
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>> Agree. We cannot do anything about L2s. But we 
> could specify
> >> >> >>>>> (informatively)
> >> >> >>>>> what L2 capabilities would enable these features if
> >> that is the
> >> >> >>>>> conclusion that we arrive at.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>> => We can, but I don't know why we should do that when a
> >> >> solution
> >> >> >>>> already exists. Especially when the alternative is
> >> inferior in
> >> >> >>>> terms of its applicability.
> >> >> >>>>
> >> >> >>>> Hesham
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>> -Raj
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> This is why I think we should stick with the charter
> >> >> that Jari sent.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> Hesham
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>> I share the same view with respect to all your other
> >> >> comments.
> >> >> >>>>>>> We need to seperate the cases of flow mobility vs
> >> >> basic handoff
> >> >> >>>>>>> as allowed in 5213. In the BOF, we discussed 
> mostly flow 
> >> >> >>>>>>> mobility and not the basic handoff cases supported
> >> >> today in 5213.
> >> >> >>>>>>>
> >> >> >>>>>>> Sri
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> _______________________________________________
> >> >> >>>>>>> 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
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> >> >
> >>
> >
> >
> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Tue, 7 Apr 2009 13:33:45 +0100
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Domagoj,

Its not like this. These SDOs are explicitly bringing specific
technologies under their system architecture. So for example 3GPP
defines in Rel9 how movement between 3GPP and specific non-3GPP
systems might work using MIP and PMIP. Again the point is that they
are defining a closed system, with freedom to affect any layer they
want and are totally unconcerned with any technologies (e.g. other
link layers) that are not explicitly defined in their system. They are
also free to force any requirements they want to devices that want to
be called 3GPP-compliant.

George

On Tue, Apr 7, 2009 at 1:19 PM, Domagoj Premec
<domagoj.premec.ext at nsn.com> wrote:
> My point is that this is an issue *between different systems*. Those other SDOs are going to use PMIP for *inter-system* handovers, and since this goes beyond the scope of the single SDO, I think that IETF is a proper place to deal with this.
>
> From the discussion we're having it seems that the analysis document exploring the PMIPv6 in the context of the inter-access mobility seems like a worthwile effort. If PMIP6 in this context is found to be harmful to the general Internet, then IMO we should have an IETF document stating this.
>
> domagoj
>
>
>> -----Original Message-----
>> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com]
>> Sent: 07. travanj 2009 13:27
>> To: Domagoj Premec
>> Cc: ext Hesham Soliman; Marco Liebsch;
>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Keep missing the point .. Re: [Netext] next steps for netext
>>
>> Folks,
>>
>> What people keep missing is that 3GPP, 3GPP2, WiMax etc, are
>> all PROPRIETARY systems as far as the IETF is concerned. The
>> IETF is tasked with making sure that the Internet as a whole
>> holds together.
>> The IETF should only standardise protocols/tools requested by
>> SDOs if they do not cause harm to the general Internet. This
>> is paramount for the long term sustainability of the Internet.
>>
>> Independently from "architectural" viewpoints, it is
>> perfectly reasonable for a given SDO to decide to implement a
>> given technology (e.g., PMIP) in their CLOSED System. PMIP
>> for example can work in the context of 3GPP (as GTP did for
>> many years) since they define a vertical system, from PHY and
>> LINK layers, to Network and even Application layers. In that
>> case, they are free to, for example, implement whatever Link
>> Layer triggers are necessary to make PMIP work in their system.
>>
>> It is another thing altogether, however, for the IETF to
>> standardise such a technology, when here we do not have
>> control over link layers.
>> On the contrary what the IETF and the Internet are based on
>> is an explicit assumption that "any" link layer should work
>> with minimum requirements from the IP layer, all of which are
>> described in host requirements
>>
>> What PMIP proponents have been asking the IETF to do is
>> define a technology that will break an RFC4294 host.
>> This is simply not acceptable.
>>
>> George
>>
>> On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec
>> <domagoj.premec.ext at nsn.com> wrote:
>> > Hi Hesham, all,
>> >
>> >> What's being said here is "PMIP
>> >> doesn't support advanced cases therefore we need something new",
>> >> which is completely bogus because PMIP was not designed to support
>> >> those cases because we already have something else for supporting
>> >> those cases. Hence my reference to 4830...
>> >>
>> >
>> > Both 3GPP and WiMAX adopted PMIP6 as means for inter-access
>> handover.
>> > Such large scale managed networks are the main consumers of
>> PMIP6 so
>> > we shouldn't be ignoring what they're doing. Saying to use MIP for
>> > inter-access handovers/multihoming is not helping as they
>> have really
>> > set their mind on using PMIP6 and they're already doing
>> this. Without
>> > going into the reasoning behind such a decision, the fact is that
>> > PMIP6, as defined in RFC 5213, has issues with inter-access
>> handovers.
>> > I think it is better to fix those PMIP6 issues in the IETF
>> then to let
>> > each SDO come up with their own way of dealing with this.
>> >
>> > domagoj
>> >
>> >
>> >> -----Original Message-----
>> >> From: netext-bounces at mail.mobileip.jp
>> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Hesham
>> >> Soliman
>> >> Sent: 07. travanj 2009 11:14
>> >> To: Marco Liebsch
>> >> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> >> Subject: Re: [Netext] next steps for netext
>> >>
>> >>
>> >> >> => We're discussing a problem statement for the BoF, so
>> >> 4830 is quite
>> >> >> appropriate as a reference for why people wanted PMIP in
>> >> the first place.
>> >> >>
>> >> > Yes, a problem statement about an existing solution for
>> >> network-based
>> >> > mobility management (PMIPv6) to support advanced use cases.
>> >>
>> >> => Where is that PS?
>> >>
>> >> ? Not the problem of
>> >> > existing solutions for localized mobility, as RFC4830
>> does. I don't
>> >> > think NetExt aims at turning PMIPv6 into a host-based mobility
>> >> > protocol again.
>> >>
>> >> => I don't know what the goal is based on the BoF
>> discussion and this
>> >> discussion on the list. The reason I don't know that is
>> that no one
>> >> is
>> >> saying:
>> >> Here is the state of the art (including BOTH MIP and PMIP)
>> and here
>> >> is why they don't work, therefore we need to do something new.
>> >> That's what a PS should say. What's being said here is
>> "PMIP doesn't
>> >> support advanced cases therefore we need something new", which is
>> >> completely bogus because PMIP was not designed to support
>> those cases
>> >> because we already have something else for supporting those cases.
>> >> Hence my reference to 4830...
>> >>
>> >> I'm going to retire from the discussion till someone makes the
>> >> argument above. Because I feel that if there is no such
>> argument then
>> >> the discussion is not a good use of time.
>> >>
>> >>
>> >> >> => Yes, additional software like the existing MIP. I don't
>> >> understand
>> >> >> the motivation for creating something new. I've detailed
>> >> this in my
>> >> >> previous emails and the points remain unanswered.
>> >> >>
>> >> > Nobody talks about adding a piece of client mobility management
>> >> > software, such as a MIP client, to the mobile. That
>> seems to be a
>> >> > wrong interpretation of what NetExt wants to do.
>> >>
>> >> => You're missing the point. Why isn't anybody talking
>> about MIP???
>> >> That's what a PS should say.
>> >>
>> >> Hesham
>> >>
>> >> >
>> >> > marco
>> >> >
>> >> >
>> >> >> Hesham
>> >> >>
>> >> >>
>> >> >> and obviously also according to RFC4831. We should
>> >> >>
>> >> >>> distinguish modification for mobility management, which
>> >> is not what
>> >> >>> we want to do, and enabling local functions, such as
>> the use of
>> >> >>> multiple interfaces, where you have to add routes, configure
>> >> >>> interfaces etc. to enable the use case.
>> >> >>>
>> >> >>> marco
>> >> >>>
>> >> >>>
>> >> >>> Hesham Soliman schrieb:
>> >> >>>
>> >> >>>>
>> >> >>>>
>> >> >>>>>> => I think you're distinguishing between modified and
>> >> unmodified
>> >> >>>>>> based on whether the modification affects IETF
>> >> protocols or not.
>> >> >>>>>> That's fine, but for those that did not attend the BoF, our
>> >> >>>>>> conclusions were that you will either end up modifying
>> >> the host
>> >> >>>>>> (i.e. Adding new SW) and adding new signalling on
>> >> >>>>>> L2 to handle the multihoming cases, or you can
>> stick with MIP.
>> >> >>>>>> My opinion, and at least half the room's was that this
>> >> is not a
>> >> >>>>>> good way to
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> We can discuss what implies host changes and why
>> this is such a
>> >> >>>>> big deal anyway. But I don't think that half the room was in
>> >> >>>>> agreement as such. At least from the count of hands
>> >> raised for the
>> >> >>>>> question about whether we should work on multihoming
>> >> and intertech
>> >> >>>>> handovers it was about 18-9 (in favor).
>> >> >>>>>
>> >> >>>>>
>> >> >>>> => I think the question changed a few times :) The final
>> >> question
>> >> >>>> (which was specific to whether people wanted to work
>> >> with this or
>> >> >>>> not) showed a split room.
>> >> >>>> The host changes are not a big deal but they are
>> mentioned here
>> >> >>>> because they were one of the very few reasons for using
>> >> NETLMM in
>> >> >>>> the first place: Host changes (adding new SW to the host) and
>> >> >>>> signalling from the MN. You can see them in section 4 of
>> >> RFC 4830.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>>> go and that it's better to stick with MIP instead of
>> >> relying on a
>> >> >>>>>> solution that will:
>> >> >>>>>> - work on some L2s and not others,
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> We have no ability to specify changes to L2 anyway.
>> However if
>> >> >>>>> some L2s do have such capability, why would we not
>> specify how
>> >> >>>>> multihoming would work in such scenarios.
>> >> >>>>>
>> >> >>>>>
>> >> >>>> => Because we already have a solution that works in all L2s,
>> >> >>>> doesn't require
>> >> >>>> L2 changes that we don't control and doesn't cause
>> >> confusing host
>> >> >>>> config solutions.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>>> - Require additional SW and config on the host which
>> >> is not done
>> >> >>>>>> anywhere today, and
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> Why is there as much of a concern about additional SW
>> >> or config?
>> >> >>>>> After all everything (or most of it anyway) that we do
>> >> in the IETF
>> >> >>>>> requires configurations, protocol changes, changes to SW etc.
>> >> >>>>> There is nothing unique about this.
>> >> >>>>>
>> >> >>>>>
>> >> >>>> => Sure, but see above and see RFC 4830. These were the
>> >> reasons for
>> >> >>>> using PMIP in the first place. We can't have it both
>> >> ways, or can
>> >> >>>> we? :)
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>>> - Require L2 signalling which is out of our scope in IETF
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> Agree. We cannot do anything about L2s. But we could specify
>> >> >>>>> (informatively)
>> >> >>>>> what L2 capabilities would enable these features if
>> that is the
>> >> >>>>> conclusion that we arrive at.
>> >> >>>>>
>> >> >>>>>
>> >> >>>> => We can, but I don't know why we should do that when a
>> >> solution
>> >> >>>> already exists. Especially when the alternative is
>> inferior in
>> >> >>>> terms of its applicability.
>> >> >>>>
>> >> >>>> Hesham
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>> -Raj
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> This is why I think we should stick with the charter
>> >> that Jari sent.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Hesham
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> I share the same view with respect to all your other
>> >> comments.
>> >> >>>>>>> We need to seperate the cases of flow mobility vs
>> >> basic handoff
>> >> >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>> >> >>>>>>> mobility and not the basic handoff cases supported
>> >> today in 5213.
>> >> >>>>>>>
>> >> >>>>>>> Sri
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> _______________________________________________
>> >> >>>>>>> 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
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>>
>
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 7 Apr 2009 14:19:09 +0200
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

My point is that this is an issue *between different systems*. Those other SDOs are going to use PMIP for *inter-system* handovers, and since this goes beyond the scope of the single SDO, I think that IETF is a proper place to deal with this.

>From the discussion we're having it seems that the analysis document exploring the PMIPv6 in the context of the inter-access mobility seems like a worthwile effort. If PMIP6 in this context is found to be harmful to the general Internet, then IMO we should have an IETF document stating this.

domagoj

> -----Original Message-----
> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com] 
> Sent: 07. travanj 2009 13:27
> To: Domagoj Premec
> Cc: ext Hesham Soliman; Marco Liebsch; 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Keep missing the point .. Re: [Netext] next steps for netext
> 
> Folks,
> 
> What people keep missing is that 3GPP, 3GPP2, WiMax etc, are 
> all PROPRIETARY systems as far as the IETF is concerned. The 
> IETF is tasked with making sure that the Internet as a whole 
> holds together.
> The IETF should only standardise protocols/tools requested by 
> SDOs if they do not cause harm to the general Internet. This 
> is paramount for the long term sustainability of the Internet.
> 
> Independently from "architectural" viewpoints, it is 
> perfectly reasonable for a given SDO to decide to implement a 
> given technology (e.g., PMIP) in their CLOSED System. PMIP 
> for example can work in the context of 3GPP (as GTP did for 
> many years) since they define a vertical system, from PHY and 
> LINK layers, to Network and even Application layers. In that 
> case, they are free to, for example, implement whatever Link 
> Layer triggers are necessary to make PMIP work in their system.
> 
> It is another thing altogether, however, for the IETF to 
> standardise such a technology, when here we do not have 
> control over link layers.
> On the contrary what the IETF and the Internet are based on 
> is an explicit assumption that "any" link layer should work 
> with minimum requirements from the IP layer, all of which are 
> described in host requirements
> 
> What PMIP proponents have been asking the IETF to do is 
> define a technology that will break an RFC4294 host.
> This is simply not acceptable.
> 
> George
> 
> On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec 
> <domagoj.premec.ext at nsn.com> wrote:
> > Hi Hesham, all,
> >
> >> What's being said here is "PMIP
> >> doesn't support advanced cases therefore we need something new", 
> >> which is completely bogus because PMIP was not designed to support 
> >> those cases because we already have something else for supporting 
> >> those cases. Hence my reference to 4830...
> >>
> >
> > Both 3GPP and WiMAX adopted PMIP6 as means for inter-access 
> handover. 
> > Such large scale managed networks are the main consumers of 
> PMIP6 so 
> > we shouldn't be ignoring what they're doing. Saying to use MIP for 
> > inter-access handovers/multihoming is not helping as they 
> have really 
> > set their mind on using PMIP6 and they're already doing 
> this. Without 
> > going into the reasoning behind such a decision, the fact is that 
> > PMIP6, as defined in RFC 5213, has issues with inter-access 
> handovers. 
> > I think it is better to fix those PMIP6 issues in the IETF 
> then to let 
> > each SDO come up with their own way of dealing with this.
> >
> > domagoj
> >
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp 
> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Hesham 
> >> Soliman
> >> Sent: 07. travanj 2009 11:14
> >> To: Marco Liebsch
> >> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >> Subject: Re: [Netext] next steps for netext
> >>
> >>
> >> >> => We're discussing a problem statement for the BoF, so
> >> 4830 is quite
> >> >> appropriate as a reference for why people wanted PMIP in
> >> the first place.
> >> >>
> >> > Yes, a problem statement about an existing solution for
> >> network-based
> >> > mobility management (PMIPv6) to support advanced use cases.
> >>
> >> => Where is that PS?
> >>
> >>   Not the problem of
> >> > existing solutions for localized mobility, as RFC4830 
> does. I don't 
> >> > think NetExt aims at turning PMIPv6 into a host-based mobility 
> >> > protocol again.
> >>
> >> => I don't know what the goal is based on the BoF 
> discussion and this 
> >> discussion on the list. The reason I don't know that is 
> that no one 
> >> is
> >> saying:
> >> Here is the state of the art (including BOTH MIP and PMIP) 
> and here 
> >> is why they don't work, therefore we need to do something new.
> >> That's what a PS should say. What's being said here is 
> "PMIP doesn't 
> >> support advanced cases therefore we need something new", which is 
> >> completely bogus because PMIP was not designed to support 
> those cases 
> >> because we already have something else for supporting those cases. 
> >> Hence my reference to 4830...
> >>
> >> I'm going to retire from the discussion till someone makes the 
> >> argument above. Because I feel that if there is no such 
> argument then 
> >> the discussion is not a good use of time.
> >>
> >>
> >> >> => Yes, additional software like the existing MIP. I don't
> >> understand
> >> >> the motivation for creating something new. I've detailed
> >> this in my
> >> >> previous emails and the points remain unanswered.
> >> >>
> >> > Nobody talks about adding a piece of client mobility management 
> >> > software, such as a MIP client, to the mobile. That 
> seems to be a 
> >> > wrong interpretation of what NetExt wants to do.
> >>
> >> => You're missing the point. Why isn't anybody talking 
> about MIP??? 
> >> That's what a PS should say.
> >>
> >> Hesham
> >>
> >> >
> >> > marco
> >> >
> >> >
> >> >> Hesham
> >> >>
> >> >>
> >> >> and obviously also according to RFC4831. We should
> >> >>
> >> >>> distinguish modification for mobility management, which
> >> is not what
> >> >>> we want to do, and enabling local functions, such as 
> the use of 
> >> >>> multiple interfaces, where you have to add routes, configure 
> >> >>> interfaces etc. to enable the use case.
> >> >>>
> >> >>> marco
> >> >>>
> >> >>>
> >> >>> Hesham Soliman schrieb:
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>>>> => I think you're distinguishing between modified and
> >> unmodified
> >> >>>>>> based on whether the modification affects IETF
> >> protocols or not.
> >> >>>>>> That's fine, but for those that did not attend the BoF, our 
> >> >>>>>> conclusions were that you will either end up modifying
> >> the host
> >> >>>>>> (i.e. Adding new SW) and adding new signalling on
> >> >>>>>> L2 to handle the multihoming cases, or you can 
> stick with MIP.
> >> >>>>>> My opinion, and at least half the room's was that this
> >> is not a
> >> >>>>>> good way to
> >> >>>>>>
> >> >>>>>>
> >> >>>>> We can discuss what implies host changes and why 
> this is such a 
> >> >>>>> big deal anyway. But I don't think that half the room was in 
> >> >>>>> agreement as such. At least from the count of hands
> >> raised for the
> >> >>>>> question about whether we should work on multihoming
> >> and intertech
> >> >>>>> handovers it was about 18-9 (in favor).
> >> >>>>>
> >> >>>>>
> >> >>>> => I think the question changed a few times :) The final
> >> question
> >> >>>> (which was specific to whether people wanted to work
> >> with this or
> >> >>>> not) showed a split room.
> >> >>>> The host changes are not a big deal but they are 
> mentioned here 
> >> >>>> because they were one of the very few reasons for using
> >> NETLMM in
> >> >>>> the first place: Host changes (adding new SW to the host) and 
> >> >>>> signalling from the MN. You can see them in section 4 of
> >> RFC 4830.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>> go and that it's better to stick with MIP instead of
> >> relying on a
> >> >>>>>> solution that will:
> >> >>>>>> - work on some L2s and not others,
> >> >>>>>>
> >> >>>>>>
> >> >>>>> We have no ability to specify changes to L2 anyway. 
> However if 
> >> >>>>> some L2s do have such capability, why would we not 
> specify how 
> >> >>>>> multihoming would work in such scenarios.
> >> >>>>>
> >> >>>>>
> >> >>>> => Because we already have a solution that works in all L2s, 
> >> >>>> doesn't require
> >> >>>> L2 changes that we don't control and doesn't cause
> >> confusing host
> >> >>>> config solutions.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>> - Require additional SW and config on the host which
> >> is not done
> >> >>>>>> anywhere today, and
> >> >>>>>>
> >> >>>>>>
> >> >>>>> Why is there as much of a concern about additional SW
> >> or config?
> >> >>>>> After all everything (or most of it anyway) that we do
> >> in the IETF
> >> >>>>> requires configurations, protocol changes, changes to SW etc.
> >> >>>>> There is nothing unique about this.
> >> >>>>>
> >> >>>>>
> >> >>>> => Sure, but see above and see RFC 4830. These were the
> >> reasons for
> >> >>>> using PMIP in the first place. We can't have it both
> >> ways, or can
> >> >>>> we? :)
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>> - Require L2 signalling which is out of our scope in IETF
> >> >>>>>>
> >> >>>>>>
> >> >>>>> Agree. We cannot do anything about L2s. But we could specify
> >> >>>>> (informatively)
> >> >>>>> what L2 capabilities would enable these features if 
> that is the 
> >> >>>>> conclusion that we arrive at.
> >> >>>>>
> >> >>>>>
> >> >>>> => We can, but I don't know why we should do that when a
> >> solution
> >> >>>> already exists. Especially when the alternative is 
> inferior in 
> >> >>>> terms of its applicability.
> >> >>>>
> >> >>>> Hesham
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>> -Raj
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>> This is why I think we should stick with the charter
> >> that Jari sent.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Hesham
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> I share the same view with respect to all your other
> >> comments.
> >> >>>>>>> We need to seperate the cases of flow mobility vs
> >> basic handoff
> >> >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow 
> >> >>>>>>> mobility and not the basic handoff cases supported
> >> today in 5213.
> >> >>>>>>>
> >> >>>>>>> Sri
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> 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
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Tue, 7 Apr 2009 12:27:25 +0100
Subject: [Netext] Keep missing the point .. Re:  next steps for netext
Message-ID: <[email-masked]>

Folks,

What people keep missing is that 3GPP, 3GPP2, WiMax etc, are all
PROPRIETARY systems as far as the IETF is concerned. The IETF is
tasked with making sure that the Internet as a whole holds together.
The IETF should only standardise protocols/tools requested by SDOs if
they do not cause harm to the general Internet. This is paramount for
the long term sustainability of the Internet.

Independently from "architectural" viewpoints, it is perfectly
reasonable for a given SDO to decide to implement a given technology
(e.g., PMIP) in their CLOSED System. PMIP for example can work in the
context of 3GPP (as GTP did for many years) since they define a
vertical system, from PHY and LINK layers, to Network and even
Application layers. In that case, they are free to, for example,
implement whatever Link Layer triggers are necessary to make PMIP work
in their system.

It is another thing altogether, however, for the IETF to standardise
such a technology, when here we do not have control over link layers.
On the contrary what the IETF and the Internet are based on is an
explicit assumption that "any" link layer should work with minimum
requirements from the IP layer, all of which are described in host
requirements

What PMIP proponents have been asking the IETF to do is define a
technology that will break an RFC4294 host.
This is simply not acceptable.

George

On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec
<domagoj.premec.ext at nsn.com> wrote:
> Hi Hesham, all,
>
>> What's being said here is "PMIP
>> doesn't support advanced cases therefore we need something
>> new", which is completely bogus because PMIP was not designed
>> to support those cases because we already have something else
>> for supporting those cases. Hence my reference to 4830...
>>
>
> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. Such
> large scale managed networks are the main consumers of PMIP6 so we shouldn't
> be ignoring what they're doing. Saying to use MIP for inter-access
> handovers/multihoming is not helping as they have really set their mind on
> using PMIP6 and they're already doing this. Without going into the reasoning
> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
> issues with inter-access handovers. I think it is better to fix those PMIP6
> issues in the IETF then to let each SDO come up with their own way of
> dealing with this.
>
> domagoj
>
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>> Hesham Soliman
>> Sent: 07. travanj 2009 11:14
>> To: Marco Liebsch
>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] next steps for netext
>>
>>
>> >> => We're discussing a problem statement for the BoF, so
>> 4830 is quite
>> >> appropriate as a reference for why people wanted PMIP in
>> the first place.
>> >>
>> > Yes, a problem statement about an existing solution for
>> network-based
>> > mobility management (PMIPv6) to support advanced use cases.
>>
>> => Where is that PS?
>>
>> ? Not the problem of
>> > existing solutions for localized mobility, as RFC4830 does. I don't
>> > think NetExt aims at turning PMIPv6 into a host-based mobility
>> > protocol again.
>>
>> => I don't know what the goal is based on the BoF discussion
>> and this discussion on the list. The reason I don't know that
>> is that no one is
>> saying:
>> Here is the state of the art (including BOTH MIP and PMIP)
>> and here is why they don't work, therefore we need to do
>> something new.
>> That's what a PS should say. What's being said here is "PMIP
>> doesn't support advanced cases therefore we need something
>> new", which is completely bogus because PMIP was not designed
>> to support those cases because we already have something else
>> for supporting those cases. Hence my reference to 4830...
>>
>> I'm going to retire from the discussion till someone makes
>> the argument above. Because I feel that if there is no such
>> argument then the discussion is not a good use of time.
>>
>>
>> >> => Yes, additional software like the existing MIP. I don't
>> understand
>> >> the motivation for creating something new. I've detailed
>> this in my
>> >> previous emails and the points remain unanswered.
>> >>
>> > Nobody talks about adding a piece of client mobility management
>> > software, such as a MIP client, to the mobile. That seems to be a
>> > wrong interpretation of what NetExt wants to do.
>>
>> => You're missing the point. Why isn't anybody talking about
>> MIP??? That's what a PS should say.
>>
>> Hesham
>>
>> >
>> > marco
>> >
>> >
>> >> Hesham
>> >>
>> >>
>> >> and obviously also according to RFC4831. We should
>> >>
>> >>> distinguish modification for mobility management, which
>> is not what
>> >>> we want to do, and enabling local functions, such as the use of
>> >>> multiple interfaces, where you have to add routes, configure
>> >>> interfaces etc. to enable the use case.
>> >>>
>> >>> marco
>> >>>
>> >>>
>> >>> Hesham Soliman schrieb:
>> >>>
>> >>>>
>> >>>>
>> >>>>>> => I think you're distinguishing between modified and
>> unmodified
>> >>>>>> based on whether the modification affects IETF
>> protocols or not.
>> >>>>>> That's fine, but for those that did not attend the BoF, our
>> >>>>>> conclusions were that you will either end up modifying
>> the host
>> >>>>>> (i.e. Adding new SW) and adding new signalling on
>> >>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>> >>>>>> My opinion, and at least half the room's was that this
>> is not a
>> >>>>>> good way to
>> >>>>>>
>> >>>>>>
>> >>>>> We can discuss what implies host changes and why this is such a
>> >>>>> big deal anyway. But I don't think that half the room was in
>> >>>>> agreement as such. At least from the count of hands
>> raised for the
>> >>>>> question about whether we should work on multihoming
>> and intertech
>> >>>>> handovers it was about 18-9 (in favor).
>> >>>>>
>> >>>>>
>> >>>> => I think the question changed a few times :) The final
>> question
>> >>>> (which was specific to whether people wanted to work
>> with this or
>> >>>> not) showed a split room.
>> >>>> The host changes are not a big deal but they are mentioned here
>> >>>> because they were one of the very few reasons for using
>> NETLMM in
>> >>>> the first place: Host changes (adding new SW to the host) and
>> >>>> signalling from the MN. You can see them in section 4 of
>> RFC 4830.
>> >>>>
>> >>>>
>> >>>>
>> >>>>>> go and that it's better to stick with MIP instead of
>> relying on a
>> >>>>>> solution that will:
>> >>>>>> - work on some L2s and not others,
>> >>>>>>
>> >>>>>>
>> >>>>> We have no ability to specify changes to L2 anyway. However if
>> >>>>> some L2s do have such capability, why would we not specify how
>> >>>>> multihoming would work in such scenarios.
>> >>>>>
>> >>>>>
>> >>>> => Because we already have a solution that works in all L2s,
>> >>>> doesn't require
>> >>>> L2 changes that we don't control and doesn't cause
>> confusing host
>> >>>> config solutions.
>> >>>>
>> >>>>
>> >>>>
>> >>>>>> - Require additional SW and config on the host which
>> is not done
>> >>>>>> anywhere today, and
>> >>>>>>
>> >>>>>>
>> >>>>> Why is there as much of a concern about additional SW
>> or config?
>> >>>>> After all everything (or most of it anyway) that we do
>> in the IETF
>> >>>>> requires configurations, protocol changes, changes to SW etc.
>> >>>>> There is nothing unique about this.
>> >>>>>
>> >>>>>
>> >>>> => Sure, but see above and see RFC 4830. These were the
>> reasons for
>> >>>> using PMIP in the first place. We can't have it both
>> ways, or can
>> >>>> we? :)
>> >>>>
>> >>>>
>> >>>>
>> >>>>>> - Require L2 signalling which is out of our scope in IETF
>> >>>>>>
>> >>>>>>
>> >>>>> Agree. We cannot do anything about L2s. But we could specify
>> >>>>> (informatively)
>> >>>>> what L2 capabilities would enable these features if that is the
>> >>>>> conclusion that we arrive at.
>> >>>>>
>> >>>>>
>> >>>> => We can, but I don't know why we should do that when a
>> solution
>> >>>> already exists. Especially when the alternative is inferior in
>> >>>> terms of its applicability.
>> >>>>
>> >>>> Hesham
>> >>>>
>> >>>>
>> >>>>
>> >>>>> -Raj
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> This is why I think we should stick with the charter
>> that Jari sent.
>> >>>>>>
>> >>>>>>
>> >>>>>> Hesham
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> I share the same view with respect to all your other
>> comments.
>> >>>>>>> We need to seperate the cases of flow mobility vs
>> basic handoff
>> >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>> >>>>>>> mobility and not the basic handoff cases supported
>> today in 5213.
>> >>>>>>>
>> >>>>>>> Sri
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> _______________________________________________
>> 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
>

From: cjbc at it.uc3m.es (=?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?=)
Date: Tue, 7 Apr 2009 13:15:42 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari, all,

Regarding the NEMO topic, I don't know what Sri has in mind, but my
personal view on that is that it'd be nice to extend PMIPv6 to support
mobile networks. What I mean here is that it'd be nice to enable MAGs
to also move (like MRs, but without even supporting RFC3963), so an MR
would be able to move between fixed and mobile MAGs without changing
its IP address (same support RFC5213 gives now). There are some
interesting scenarios that could benefit from this.

What do others think? It is interesting to work on this?

Thanks,

Carlos

2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> Sri,
>
> Thanks for your input. Inline:
>
>> I've a concern with the planned charter. The list is too random and
>> cherry picked and I dont believe proper input from all the folks went into
>> this. There are many other items that are required for a reasonable
>> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
>> years, some of them that were left out in the base spec, some that we
>> realized as gaps when compared to other SDO protocols and some as
>> optimizations that we realized while implementing PMIP6, these items
>> should be in the initial scope.
>>
>> I understand the charter needs to be limited in scope, but just 3 or 4
>> random items, I'm not sure if this helps in short term PMIP6 requirements.
>> I've no issue with the currently listed items, but there are other items
>> that should get equal or higher priority.
>
> I have no problem with adding more. Even the charter says new things can be
> added.
>
> However, from a process perspective what I did was to take the proposal on
> the table, i.e., the full BOF scope and see what parts of that we already
> have an agreement on. I didn't include other things that were not discussed
> in the BOF. Maybe that would have been useful, but they were not on the
> table.
>
> We could add more items now, if there's general agreement that those things
> are useful. However, I do not want to declare an open season on doing
> everything. We pick a reasonable subset of all proposed work, based on
> priorities, community agreement that they are the right things to do,
> management reasons to ensure that we are not doing too much, etc.
>
>> For example, item #6, is absolutely required, from the perspective of
>> having a complete specification of 5213. There we allowed a mobile node to
>> perform handoff betweek two interfaces. We defined all the hooks on the
>> network side, but we did not provide how a terminal vendor can support
>> that. A simple informational draft on how some one move prefixes between
>> interfaces will greatly help. Some guidance on how to create a virtual
>> interface and also some related notes for each platform (Linux, BSD,
>> Android ..etc). This should not fall in the controversial discussion scope
>> of same address on two interfaces etc, thats a different problem, or about
>> the issue of enhancing mobile node's capabilities. This is just
>> informational work, required to leverage what 5213 already supports.
>
> I suspect this is about the scoping of the handoff work. Lets try to figure
> out what makes sense (I personally believe the above item makes sense, for
> instance) and what doesn't.
>
> The fact that these parts were not in the charter was not a declaration that
> we're dismissing them. Its just that we didn't finish the discussion, but I
> still wanted to let the other things move forward.
>
>> Item #2, is required. The multimob BOF raised some issues, we need to
>> show how multicast services can be enabled in PMIP network. May be this
>> wont require extensions, a simple draft covering those aspects will help.
>
> As you may recall, in the Multimob BOF we did not have an agreement on what
> exactly is needed, if anything. My own conclusion is that we probably need
> at least an informational document that explains how to use RFC 5213 for
> multicast. I think we discussed the possibility of doing this as some kind
> of AD sponsored document or in one of the relevant WGs, as a joint work
> between PMIP and multicast experts.
>
> I'm on the fence about adding this work to the charter right now, mainly
> because the BOF back then was very inconclusive. I'd be happier if I saw an
> actual well written draft from say you and some of the multicast experts.
> There's no problem moving good documents forward, even if they are not in
> the charter of some WG. Then again, I wouldn't necessarily mind a
> maintenance like item for this in one of the WG charters either.
>
>> I think, the charter should be bit more relaxed and more extensive. As I
>> see it, atleast the folks are interested in doing the work. We should add
>> atleast 4 or 5 more items to this list.
>
> Generally speaking IETF WG charters give specific work items that the WG
> should work on. I had hoped that the charter text:
>
> "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."
>
> gives an indication that we intend to do more! I am also personally very
> happy to add more items to the group's charter. All in all, I do know that
> the current charter is a bit on the thin side -- mostly because the
> multihoming/interaccess issue is under discussion.
>
> There's also the question of general maintenance items. Some IETF WGs have a
> general work item to fix problems and issue updates to existing
> specifications. I think we need to do that for Proxy Mobile IPv6 as well.
> But we have not decided whether that item should go to NETLMM or NETEXT WG
> yet. Please rest assured that the work will be possible regardless of this.
>
>> 1. Dynamic LMA Assignment
>>
>> In blade architecture systems or in a load balancer configuration, the
>> PDNGW
>> should have the ability to dynamically assign a LMA on the fly, along the
>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>> [RFC-4433].
>> Currently, GTP provides such semantics and this is a important requirement
>> for deployment. Here the goal is to
>>
>> a.) Expose a single IP address to the SGW
>> b.) The exposed IP address should not be in path once the assignment is
>> done.
>>
>>
>>
>> [LMA1]---
>> | |
>> [LMA2]--[LMA]==========[MAG]
>> | |
>> [LMA3]---
>>
>>
>> Along the lines of:
>>
>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>
> This is in the proposed NETEXT charter already.
>
>> 2. Multicast Support in Proxy Mobile IPv6
>>
>> We need an informational specification on how multicast support can be
>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>> analysis
>> on
>> this. This is required and critical for enabling any multicast services.
>> However,
>> Behcet may disagree with the scope of the work.
>
> See above.
>
>> 3. Bulk Registration Support
>>
>> This is a simple extension which helps in signaling optimization, along
>> the
>> lines of:
>>
>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>
> This is in the charter as well.
>
>> 4. Partial Failover Support
>>
>> We need a mechanism to notify the peer on revoke a partial set of
>> bindings.
>>
>>
>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
>> txt
>
> Hmm. Ok. This needs more discussion.
>
>> 5. Group Identifier Support for Proxy Mobile IPv6
>>
>> This provides a simple and a generic semantic for assigning a group
>> identifier
>> to a mobile node's binding. GTP has very similar semantics, Connexion Set
>> Id.
>> Both #3 and #4 can leverage this. Additionally, in load balancer systems
>> where
>> the load balancer is in path for all signaling messages, it can use this
>> as
>> a
>> tag for redirecting the message.
>>
>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
> Since the bulk registration work is in the charter, can't you do the
> sensible design (whatever it is) under that? There is no requirement that
> one charter item equals one document.
>
>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
>> handoffs:
>>
>>
>> RFC-5213 supports handoff between two interfaces. The ability to move
>> prefixes between interfaces. In other words address continuity is assured
>> with any IPv6 host on the planet and with absolutely no changes. This
>> meets
>> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>> not assured is the aspect of session continuity. Which requires a virtual
>> interface implementation on the host, by binding the address/prefix to a
>> virtual interface and by not exposing the physical interface or by hiding
>> the handoff events from the layer-3 stack.
>>
>> In essence, we need an informational specification which provides some
>> general guidance to how to leverage the feature support provided in
>> RFC-5213,
>> along the lines of:
>>
>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
> This is part of the discussion that we need to finish. But I plan to let the
> rest of the stuff move forward even before we have done that.
>
>
>> 7. Route Optimization for Proxy Mobile IPv6
>>
>> There were atleast 4 drafts in this area on Route Optimization. Marco
>> Liebsch
>> analyzed this exensively:
>>
>>
>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>>
>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
>> txt
>
> This is in the charter.
>
>> 8. Prefix Management in Proxy Mobile IPv6 support
>>
>> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
>> to a given mobile node's interface. It might be useful to specify how the
>> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
>> AAA to manage this aspect. Behcet has one draft on this.
>
> I'm not personally sold on this particular work. But again, this could be
> something to consider.
>
>> 9. Partial Handoff Support
>>
>> We are missing some semantics in 5213 for moving a subset of the prefixes
>> between interfaces as part of the inter-tech handoff. This is about
>> defining
>> a new handoff value. This allows partial flow management, but moving the
>> flows associated to a prefix, as a whole group.
>>
>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>
> A part of the topic we still need to discuss...
>
>> 10. CMIPv4/PMIP Interworking
>>
>> This is probably required to specify how an IPv4-only can move between
>> CMIP and PMIP environments.
>>
>>
>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
>> meghana-netlmm-pmipv6-mipv4-00.txt
>
> Client MIPv6 and Proxy MIPv6 interoperability is already in the NETLMM
> charter, but this work is presumably about interaction with MIPv4. Might be
> useful work, I wouldn't mind if this was done in NETEXT at some point. Is
> this crucial to be in the first revision of the WG's charter?
>
>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
> Can you expand on this?
>
> Jari
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: cjbc at it.uc3m.es (=?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?=)
Date: Tue, 7 Apr 2009 13:06:55 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Tele,

Comments below,

2009/4/6 MELIA TELEMACO <Telemaco.Melia at alcatel-lucent.com>:
> Hello,
>
> I think that at this point a pragmatic approach would probably help in solving some of the controversial issues.
> IETF specified 5213 and as such should also specify how hosts are supposed to behave in a PMIPv6 domain.
> This should include:
> - MN to MAG interface: we had, for instance, such a document in Netlmm. It seems that L2 and L3 solutions are being discussed again, we need to document them in an Informational document

Agree it would be useful to have an informational document explaining
what mechanisms are out there that could be useful for the MAG to
interact to the MN (this does not imply new protocols/changes on the
MN).

> - Multihoming in PMIPv6: it seems clear there are attractive scenarios people are willing to explore. Again let's capture all of this in an informational document.
>

Agree, I think there are some interesting scenarios involving
multi-interfaced MNs. I think work on multi-interfaced MNs should be
on the charter, but if people think it's to early to work on
solutions/the problem is not clear, we may start by documenting the
scenarios and related problems in an informational document.

Carlos
> Comments?
>
> telemaco
>
> -----Message d'origine-----
> De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Jari Arkko
> Envoy? : lundi 6 avril 2009 19:03
> ? : Vijay Devarapalli
> Cc : netext at mail.mobileip.jp
> Objet : Re: [Netext] next steps for netext
>
> Vijay ,
>
>> There was quite a bit of confusion on the "host changes" at the BoF. I
>> hope we are not taking decisions based on this confusion. That would
>> be very disappointing.
>>
>
> We are not making any decisions yet about the confused or controversial parts. I sent out the charter so that we can at least move forward with the rest. I'd be interested in hearing ideas on how to move forward with the inter-access and multihoming parts.
>
> Jari
>
> _______________________________________________
> 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
>

From: cjbc at it.uc3m.es (=?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?=)
Date: Tue, 7 Apr 2009 13:00:16 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Fully agree. Unless the enhancements we develop in netext disables
mobility support for legacy/unmodified nodes (where I mean here is all
the nodes that RFC5213 provides support now), it is worthwhile at
least analysing these solutions, IMHO.

Regards,

Carlos

2009/4/7 Marco Liebsch <marco.liebsch at nw.neclab.eu>:
> We should take RFC4831 as reference doc, which is the design goals document,
> not RFC4830, as it's the PS. It says what is acceptable, in my
> understanding. Referring
> to section 3.7, which is about Support for Unmodified Hosts, it first says
> 'Support' for
> unmodified hosts. That's what RFC5213 does. It does not exclude modified
> hosts.
> More important, the same section says: "Note that this goal does NOT mean
> that the
> mobile node has no software at all associated with mobility."... That looks
> pretty clear.
>
> In my opinion, important is that unmodified hosts are supported, which is a
> requirement
> we meet. To support enhanced use cases, some supporting software seems to be
> acceptable in my opinion and obviously also according to RFC4831. We should
> distinguish modification for mobility management, which is not what we want
> to do,
> and enabling local functions, such as the use of multiple interfaces, where
> you have
> to add routes, configure interfaces etc. to enable the use case.
>
> marco
>
>
> Hesham Soliman schrieb:
>>
>>
>>>>
>>>> => I think you're distinguishing between modified and unmodified based
>>>> on
>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>> for
>>>> those that did not attend the BoF, our conclusions were that you will
>>>> either
>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling
>>>> on
>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>> My opinion, and at least half the room's was that this is not a good way
>>>> to
>>>>
>>>
>>> We can discuss what implies host changes and why this is such a big deal
>>> anyway. But I don't think that half the room was in agreement as such. At
>>> least from the count of hands raised for the question about whether we
>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>> favor).
>>
>> => I think the question changed a few times :) The final question (which
>> was
>> specific to whether people wanted to work with this or not) showed a split
>> room. The host changes are not a big deal but they are mentioned here
>> because they
>> were one of the very few reasons for using NETLMM in the first place: Host
>> changes (adding new SW to the host) and signalling from the MN. You can
>> see
>> them in section 4 of RFC 4830.
>>
>>
>>>>
>>>> go and that it's better to stick with MIP instead of relying on a
>>>> solution
>>>> that will:
>>>> - work on some L2s and not others,
>>>>
>>>
>>> We have no ability to specify changes to L2 anyway. However if some L2s
>>> do
>>> have such capability, why would we not specify how multihoming would work
>>> in
>>> such scenarios.
>>>
>>
>> => Because we already have a solution that works in all L2s, doesn't
>> require
>> L2 changes that we don't control and doesn't cause confusing host config
>> solutions.
>>
>>>>
>>>> - Require additional SW and config on the host which is not done
>>>> anywhere
>>>> today, and
>>>>
>>>
>>> Why is there as much of a concern about additional SW or config? After
>>> all
>>> everything (or most of it anyway) that we do in the IETF requires
>>> configurations, protocol changes, changes to SW etc. There is nothing
>>> unique
>>> about this.
>>
>> => Sure, but see above and see RFC 4830. These were the reasons for using
>> PMIP in the first place. We can't have it both ways, or can we? :)
>>
>>
>>>>
>>>> - Require L2 signalling which is out of our scope in IETF
>>>>
>>>
>>> Agree. We cannot do anything about L2s. But we could specify
>>> (informatively)
>>> what L2 capabilities would enable these features if that is the
>>> conclusion
>>> that we arrive at.
>>>
>>
>> => We can, but I don't know why we should do that when a solution already
>> exists. Especially when the alternative is inferior in terms of its
>> applicability.
>>
>> Hesham
>>
>>
>>>
>>> -Raj
>>>
>>>
>>>>
>>>> This is why I think we should stick with the charter that Jari sent.
>>>>
>>>>
>>>> Hesham
>>>>
>>>>
>>>>>
>>>>> I share the same view with respect to all your other comments. We need
>>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>>> handoff cases supported today in 5213.
>>>>>
>>>>> Sri
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 7 Apr 2009 12:55:31 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Hesham, all,

> What's being said here is "PMIP 
> doesn't support advanced cases therefore we need something 
> new", which is completely bogus because PMIP was not designed 
> to support those cases because we already have something else 
> for supporting those cases. Hence my reference to 4830...
>

Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. Such
large scale managed networks are the main consumers of PMIP6 so we shouldn't
be ignoring what they're doing. Saying to use MIP for inter-access
handovers/multihoming is not helping as they have really set their mind on
using PMIP6 and they're already doing this. Without going into the reasoning
behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
issues with inter-access handovers. I think it is better to fix those PMIP6
issues in the IETF then to let each SDO come up with their own way of
dealing with this.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> Hesham Soliman
> Sent: 07. travanj 2009 11:14
> To: Marco Liebsch
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> >> => We're discussing a problem statement for the BoF, so 
> 4830 is quite 
> >> appropriate as a reference for why people wanted PMIP in 
> the first place.
> >>   
> > Yes, a problem statement about an existing solution for 
> network-based 
> > mobility management (PMIPv6) to support advanced use cases.
> 
> => Where is that PS?
> 
>   Not the problem of
> > existing solutions for localized mobility, as RFC4830 does. I don't 
> > think NetExt aims at turning PMIPv6 into a host-based mobility 
> > protocol again.
> 
> => I don't know what the goal is based on the BoF discussion 
> and this discussion on the list. The reason I don't know that 
> is that no one is
> saying:
> Here is the state of the art (including BOTH MIP and PMIP) 
> and here is why they don't work, therefore we need to do 
> something new.
> That's what a PS should say. What's being said here is "PMIP 
> doesn't support advanced cases therefore we need something 
> new", which is completely bogus because PMIP was not designed 
> to support those cases because we already have something else 
> for supporting those cases. Hence my reference to 4830...
> 
> I'm going to retire from the discussion till someone makes 
> the argument above. Because I feel that if there is no such 
> argument then the discussion is not a good use of time.
> 
> 
> >> => Yes, additional software like the existing MIP. I don't 
> understand 
> >> the motivation for creating something new. I've detailed 
> this in my 
> >> previous emails and the points remain unanswered.
> >>   
> > Nobody talks about adding a piece of client mobility management 
> > software, such as a MIP client, to the mobile. That seems to be a 
> > wrong interpretation of what NetExt wants to do.
> 
> => You're missing the point. Why isn't anybody talking about 
> MIP??? That's what a PS should say.
> 
> Hesham
> 
> > 
> > marco
> > 
> > 
> >> Hesham
> >> 
> >> 
> >> and obviously also according to RFC4831. We should
> >>   
> >>> distinguish modification for mobility management, which 
> is not what 
> >>> we want to do, and enabling local functions, such as the use of 
> >>> multiple interfaces, where you have to add routes, configure 
> >>> interfaces etc. to enable the use case.
> >>> 
> >>> marco
> >>>  
> >>> 
> >>> Hesham Soliman schrieb:
> >>>     
> >>>>   
> >>>>       
> >>>>>> => I think you're distinguishing between modified and 
> unmodified 
> >>>>>> based on whether the modification affects IETF 
> protocols or not. 
> >>>>>> That's fine, but for those that did not attend the BoF, our 
> >>>>>> conclusions were that you will either end up modifying 
> the host 
> >>>>>> (i.e. Adding new SW) and adding new signalling on
> >>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
> >>>>>> My opinion, and at least half the room's was that this 
> is not a 
> >>>>>> good way to
> >>>>>>       
> >>>>>>           
> >>>>> We can discuss what implies host changes and why this is such a 
> >>>>> big deal anyway. But I don't think that half the room was in 
> >>>>> agreement as such. At least from the count of hands 
> raised for the 
> >>>>> question about whether we should work on multihoming 
> and intertech 
> >>>>> handovers it was about 18-9 (in favor).
> >>>>>     
> >>>>>         
> >>>> => I think the question changed a few times :) The final 
> question 
> >>>> (which was specific to whether people wanted to work 
> with this or 
> >>>> not) showed a split room.
> >>>> The host changes are not a big deal but they are mentioned here 
> >>>> because they were one of the very few reasons for using 
> NETLMM in 
> >>>> the first place: Host changes (adding new SW to the host) and 
> >>>> signalling from the MN. You can see them in section 4 of 
> RFC 4830.
> >>>> 
> >>>>   
> >>>>       
> >>>>>> go and that it's better to stick with MIP instead of 
> relying on a 
> >>>>>> solution that will:
> >>>>>> - work on some L2s and not others,
> >>>>>>       
> >>>>>>           
> >>>>> We have no ability to specify changes to L2 anyway. However if 
> >>>>> some L2s do have such capability, why would we not specify how 
> >>>>> multihoming would work in such scenarios.
> >>>>>     
> >>>>>         
> >>>> => Because we already have a solution that works in all L2s, 
> >>>> doesn't require
> >>>> L2 changes that we don't control and doesn't cause 
> confusing host 
> >>>> config solutions.
> >>>> 
> >>>>   
> >>>>       
> >>>>>> - Require additional SW and config on the host which 
> is not done 
> >>>>>> anywhere today, and
> >>>>>>       
> >>>>>>           
> >>>>> Why is there as much of a concern about additional SW 
> or config? 
> >>>>> After all everything (or most of it anyway) that we do 
> in the IETF 
> >>>>> requires configurations, protocol changes, changes to SW etc. 
> >>>>> There is nothing unique about this.
> >>>>>     
> >>>>>         
> >>>> => Sure, but see above and see RFC 4830. These were the 
> reasons for 
> >>>> using PMIP in the first place. We can't have it both 
> ways, or can 
> >>>> we? :)
> >>>> 
> >>>>   
> >>>>       
> >>>>>> - Require L2 signalling which is out of our scope in IETF
> >>>>>>       
> >>>>>>           
> >>>>> Agree. We cannot do anything about L2s. But we could specify
> >>>>> (informatively)
> >>>>> what L2 capabilities would enable these features if that is the 
> >>>>> conclusion that we arrive at.
> >>>>>     
> >>>>>         
> >>>> => We can, but I don't know why we should do that when a 
> solution 
> >>>> already exists. Especially when the alternative is inferior in 
> >>>> terms of its applicability.
> >>>> 
> >>>> Hesham
> >>>> 
> >>>>   
> >>>>       
> >>>>> -Raj
> >>>>> 
> >>>>>     
> >>>>>         
> >>>>>> This is why I think we should stick with the charter 
> that Jari sent.
> >>>>>> 
> >>>>>> 
> >>>>>> Hesham
> >>>>>> 
> >>>>>>       
> >>>>>>           
> >>>>>>> I share the same view with respect to all your other 
> comments. 
> >>>>>>> We need to seperate the cases of flow mobility vs 
> basic handoff 
> >>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow 
> >>>>>>> mobility and not the basic handoff cases supported 
> today in 5213.
> >>>>>>> 
> >>>>>>> Sri
> >>>>>>> 
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>   
> >>>>       
> >>>     
> >> 
> >> 
> >>   
> > 
> > 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Tue, 7 Apr 2009 12:10:35 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7CA0D@ftrdmel1> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7CA37@ftrdmel1>

I had a more optimistic conclusion after reading :-)

> -----Message d'origine-----
> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Envoy??: mardi 7 avril 2009 11:04
> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
> jari.arkko at piuha.net; vijay at wichorus.com
> Cc?: netext at mail.mobileip.jp
> Objet?: Re: [Netext] next steps for netext
> 
> I haven't read draft-jeyatharan but draft-krishnan is basically saying
> "don't do that". So I'm not sure that you want to use it to argue for
> what's
> being proposed here...
> 
> Hesham
> 
> 
> On 7/04/09 8:46 PM, "pierrick.seite at orange-ftgroup.com"
> <pierrick.seite at orange-ftgroup.com> wrote:
> 
> >
> > Regarding PS, we can refer to draft-jeyatharan-netext-multihoming-ps-01
> and
> > draft-krishnan-netext-intertech-ps-00.
> >
> > Regards,
> > Pierrick
> >
> >> -----Message d'origine-----
> >> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
> >> Envoy??: mardi 7 avril 2009 10:18
> >> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
> >> jari.arkko at piuha.net; vijay at wichorus.com
> >> Cc?: netext at mail.mobileip.jp
> >> Objet?: Re: [Netext] next steps for netext
> >>
> >> There was a lot of interest in ATM many years ago, doesn't mean it's a
> >> good
> >> thing. Why can't people describe the reason for wanting to use PMIP for
> >> this
> >> sort of thing?? Is there a PS? If not, what are we talking about?
> >>
> >> Hesham
> >>
> >>
> >> On 7/04/09 8:13 PM, "pierrick.seite at orange-ftgroup.com"
> >> <pierrick.seite at orange-ftgroup.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> At least, this thread shows that there is a lot of interest for
> >>> Inter-technology handover and IP flow mobility with PMIP :-) My
> >> understanding
> >>> is that some interesting solutions are suggested (e.g. virtual
> interface)
> >> but
> >>> compliance with NetLMM basics needs clarification. So I definitely
> agree
> >> with
> >>> Telemaco; in a first step, a document giving an overview of solutions
> >> and
> >>> assessing host involvement, if any, would help.
> >>>
> >>> Regards,
> >>> Pierrick
> >>>
> >>>> -----Message d'origine-----
> >>>> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> >>>> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
> >>>> Envoy??: lundi 6 avril 2009 19:29
> >>>> ??: Jari Arkko; Vijay Devarapalli
> >>>> Cc?: netext at mail.mobileip.jp
> >>>> Objet?: Re: [Netext] next steps for netext
> >>>>
> >>>> Hello,
> >>>>
> >>>> I think that at this point a pragmatic approach would probably help
> in
> >>>> solving some of the controversial issues.
> >>>> IETF specified 5213 and as such should also specify how hosts are
> >> supposed
> >>>> to behave in a PMIPv6 domain.
> >>>> This should include:
> >>>> - MN to MAG interface: we had, for instance, such a document in
> Netlmm.
> >> It
> >>>> seems that L2 and L3 solutions are being discussed again, we need to
> >>>> document them in an Informational document
> >>>> - Multihoming in PMIPv6: it seems clear there are attractive
> scenarios
> >>>> people are willing to explore. Again let's capture all of this in an
> >>>> informational document.
> >>>>
> >>>> Comments?
> >>>>
> >>>> telemaco
> >>>>
> >>>> -----Message d'origine-----
> >>>> De : netext-bounces at mail.mobileip.jp [mailto:netext-
> >>>> bounces at mail.mobileip.jp] De la part de Jari Arkko
> >>>> Envoy? : lundi 6 avril 2009 19:03
> >>>> ? : Vijay Devarapalli
> >>>> Cc : netext at mail.mobileip.jp
> >>>> Objet : Re: [Netext] next steps for netext
> >>>>
> >>>> Vijay ,
> >>>>
> >>>>> There was quite a bit of confusion on the "host changes" at the BoF.
> I
> >>>>> hope we are not taking decisions based on this confusion. That would
> >>>>> be very disappointing.
> >>>>>
> >>>>
> >>>> We are not making any decisions yet about the confused or
> controversial
> >>>> parts. I sent out the charter so that we can at least move forward
> with
> >>>> the rest. I'd be interested in hearing ideas on how to move forward
> >> with
> >>>> the inter-access and multihoming parts.
> >>>>
> >>>> Jari
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> NetExt mailing list
> >>> NetExt at mail.mobileip.jp
> >>> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 07 Apr 2009 12:06:42 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Hesham,
please see inline.

Hesham Soliman schrieb:
>
> On 7/04/09 6:38 PM, "Marco Liebsch" <marco.liebsch at nw.neclab.eu> wrote:
>
>   
>> We should take RFC4831 as reference doc, which is the design goals document,
>> not RFC4830, as it's the PS.
>>     
>
> => We're discussing a problem statement for the BoF, so 4830 is quite
> appropriate as a reference for why people wanted PMIP in the first place.
>   
Yes, a problem statement about an existing solution for network-based 
mobility
management (PMIPv6) to support advanced use cases. Not the problem of
existing solutions for localized mobility, as RFC4830 does. I don't 
think NetExt
aims at turning PMIPv6 into a host-based mobility protocol again.

> It says what is acceptable, in my
>   
>> understanding. Referring
>> to section 3.7, which is about Support for Unmodified Hosts, it first
>> says 'Support' for
>> unmodified hosts. That's what RFC5213 does. It does not exclude modified
>> hosts.
>> More important, the same section says: "Note that this goal does NOT
>> mean that the
>> mobile node has no software at all associated with mobility."... That
>> looks pretty clear.
>>     
>
> => Did you read section 4? Here is an example:
> " 1) Interoperable IP-level protocols that require changes to the
>       mobile node's IP stack and handle localized mobility management as
>       a service provided to the mobile node by the access network.
>
>    2) Link specific or proprietary protocols that handle localized
>       mobility for any mobile node but only for a specific type of link
>       layer, for example, 802.11 [6].
>
>    The dedicated localized mobility management IETF protocols for
>    Solution 1 are not yet widely deployed, but work continues on
>    standardization.  Some Mobile IPv4 deployments use localized mobility
>    management.  For Solution 1, the following are specific problems:
>
>    1) The host stack software requirement limits broad usage even if the
>       modifications are small.  The success of WLAN switches indicates
>       that network operators and users prefer no host stack software
>       modifications.  This preference is independent of the lack of
>       widespread Mobile IPv4 deployment, since it is much easier to
>       deploy and use the network."
>   
Yes, that's a problem of existing host-based localized mobility 
management protocols.
I don't see how some software on a mobile to enable for example the use 
of two
interfaces in parallel, fits into the problem you refer to above.

>   
>> In my opinion, important is that unmodified hosts are supported, which
>> is a requirement
>> we meet. To support enhanced use cases, some supporting software seems to be
>> acceptable in my opinion
>>     
>
> => Yes, additional software like the existing MIP. I don't understand the
> motivation for creating something new. I've detailed this in my previous
> emails and the points remain unanswered.
>   
Nobody talks about adding a piece of client mobility management 
software, such as a
MIP client, to the mobile. That seems to be a wrong interpretation of 
what NetExt
wants to do.

marco

> Hesham
>
>
> and obviously also according to RFC4831. We should
>   
>> distinguish modification for mobility management, which is not what we
>> want to do,
>> and enabling local functions, such as the use of multiple interfaces,
>> where you have
>> to add routes, configure interfaces etc. to enable the use case.
>>
>> marco
>>  
>>
>> Hesham Soliman schrieb:
>>     
>>>   
>>>       
>>>>> => I think you're distinguishing between modified and unmodified based on
>>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>>> for
>>>>> those that did not attend the BoF, our conclusions were that you will
>>>>> either
>>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling on
>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>> My opinion, and at least half the room's was that this is not a good way to
>>>>>       
>>>>>           
>>>> We can discuss what implies host changes and why this is such a big deal
>>>> anyway. But I don't think that half the room was in agreement as such. At
>>>> least from the count of hands raised for the question about whether we
>>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>>> favor). 
>>>>     
>>>>         
>>> => I think the question changed a few times :) The final question (which was
>>> specific to whether people wanted to work with this or not) showed a split
>>> room. 
>>> The host changes are not a big deal but they are mentioned here because they
>>> were one of the very few reasons for using NETLMM in the first place: Host
>>> changes (adding new SW to the host) and signalling from the MN. You can see
>>> them in section 4 of RFC 4830.
>>>
>>>   
>>>       
>>>>> go and that it's better to stick with MIP instead of relying on a solution
>>>>> that will:
>>>>> - work on some L2s and not others,
>>>>>       
>>>>>           
>>>> We have no ability to specify changes to L2 anyway. However if some L2s do
>>>> have such capability, why would we not specify how multihoming would work in
>>>> such scenarios.
>>>>     
>>>>         
>>> => Because we already have a solution that works in all L2s, doesn't require
>>> L2 changes that we don't control and doesn't cause confusing host config
>>> solutions. 
>>>
>>>   
>>>       
>>>>> - Require additional SW and config on the host which is not done anywhere
>>>>> today, and
>>>>>       
>>>>>           
>>>> Why is there as much of a concern about additional SW or config? After all
>>>> everything (or most of it anyway) that we do in the IETF requires
>>>> configurations, protocol changes, changes to SW etc. There is nothing unique
>>>> about this. 
>>>>     
>>>>         
>>> => Sure, but see above and see RFC 4830. These were the reasons for using
>>> PMIP in the first place. We can't have it both ways, or can we? :)
>>>
>>>   
>>>       
>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>       
>>>>>           
>>>> Agree. We cannot do anything about L2s. But we could specify (informatively)
>>>> what L2 capabilities would enable these features if that is the conclusion
>>>> that we arrive at.
>>>>     
>>>>         
>>> => We can, but I don't know why we should do that when a solution already
>>> exists. Especially when the alternative is inferior in terms of its
>>> applicability.
>>>
>>> Hesham
>>>
>>>   
>>>       
>>>> -Raj
>>>>
>>>>     
>>>>         
>>>>> This is why I think we should stick with the charter that Jari sent.
>>>>>
>>>>>
>>>>> Hesham
>>>>>
>>>>>       
>>>>>           
>>>>>> I share the same view with respect to all your other comments. We need
>>>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>>>> handoff cases supported today in 5213.
>>>>>>
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>   
>>>       
>>     
>
>
>   

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 21:00:10 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 7/04/09 9:55 PM, "Domagoj Premec" <domagoj.premec.ext at nsn.com> wrote:

> Hi Hesham, all,
> 
>> What's being said here is "PMIP
>> doesn't support advanced cases therefore we need something
>> new", which is completely bogus because PMIP was not designed
>> to support those cases because we already have something else
>> for supporting those cases. Hence my reference to 4830...
>> 
> 
> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. Such
> large scale managed networks are the main consumers of PMIP6 so we shouldn't
> be ignoring what they're doing.

=> I'm not suggesting we ignore it, but at the same time we can't rubber
stamp things. There are two ways we can go about this. Either we can a clear
PS that we can discuss and decide on its merit whether we should provide
solutions for it or not, or we can let them solve it in their respective
organisations. This is not new, we've had several discussions before with
SDOs and the outcome was in many cases different from what was originally
proposed. I find it scarey that people are not open to even justify why this
is needed. This is not a recipe for producing good work.

Saying to use MIP for inter-access
> handovers/multihoming is not helping as they have really set their mind on
> using PMIP6 and they're already doing this.

=> Doesn't sound like a technical discussion to me. Politics usually produce
bad solutions in IETF.

Hesham

> 
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>> Hesham Soliman
>> Sent: 07. travanj 2009 11:14
>> To: Marco Liebsch
>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] next steps for netext
>> 
>> 
>>>> => We're discussing a problem statement for the BoF, so
>> 4830 is quite 
>>>> appropriate as a reference for why people wanted PMIP in
>> the first place.
>>>>   
>>> Yes, a problem statement about an existing solution for
>> network-based 
>>> mobility management (PMIPv6) to support advanced use cases.
>> 
>> => Where is that PS?
>> 
>>   Not the problem of
>>> existing solutions for localized mobility, as RFC4830 does. I don't
>>> think NetExt aims at turning PMIPv6 into a host-based mobility
>>> protocol again.
>> 
>> => I don't know what the goal is based on the BoF discussion
>> and this discussion on the list. The reason I don't know that
>> is that no one is
>> saying:
>> Here is the state of the art (including BOTH MIP and PMIP)
>> and here is why they don't work, therefore we need to do
>> something new.
>> That's what a PS should say. What's being said here is "PMIP
>> doesn't support advanced cases therefore we need something
>> new", which is completely bogus because PMIP was not designed
>> to support those cases because we already have something else
>> for supporting those cases. Hence my reference to 4830...
>> 
>> I'm going to retire from the discussion till someone makes
>> the argument above. Because I feel that if there is no such
>> argument then the discussion is not a good use of time.
>> 
>> 
>>>> => Yes, additional software like the existing MIP. I don't
>> understand 
>>>> the motivation for creating something new. I've detailed
>> this in my 
>>>> previous emails and the points remain unanswered.
>>>>   
>>> Nobody talks about adding a piece of client mobility management
>>> software, such as a MIP client, to the mobile. That seems to be a
>>> wrong interpretation of what NetExt wants to do.
>> 
>> => You're missing the point. Why isn't anybody talking about
>> MIP??? That's what a PS should say.
>> 
>> Hesham
>> 
>>> 
>>> marco
>>> 
>>> 
>>>> Hesham
>>>> 
>>>> 
>>>> and obviously also according to RFC4831. We should
>>>>   
>>>>> distinguish modification for mobility management, which
>> is not what 
>>>>> we want to do, and enabling local functions, such as the use of
>>>>> multiple interfaces, where you have to add routes, configure
>>>>> interfaces etc. to enable the use case.
>>>>> 
>>>>> marco
>>>>>  
>>>>> 
>>>>> Hesham Soliman schrieb:
>>>>>     
>>>>>>   
>>>>>>       
>>>>>>>> => I think you're distinguishing between modified and
>> unmodified 
>>>>>>>> based on whether the modification affects IETF
>> protocols or not.
>>>>>>>> That's fine, but for those that did not attend the BoF, our
>>>>>>>> conclusions were that you will either end up modifying
>> the host 
>>>>>>>> (i.e. Adding new SW) and adding new signalling on
>>>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>>>> My opinion, and at least half the room's was that this
>> is not a 
>>>>>>>> good way to
>>>>>>>>       
>>>>>>>>           
>>>>>>> We can discuss what implies host changes and why this is such a
>>>>>>> big deal anyway. But I don't think that half the room was in
>>>>>>> agreement as such. At least from the count of hands
>> raised for the 
>>>>>>> question about whether we should work on multihoming
>> and intertech 
>>>>>>> handovers it was about 18-9 (in favor).
>>>>>>>     
>>>>>>>         
>>>>>> => I think the question changed a few times :) The final
>> question 
>>>>>> (which was specific to whether people wanted to work
>> with this or 
>>>>>> not) showed a split room.
>>>>>> The host changes are not a big deal but they are mentioned here
>>>>>> because they were one of the very few reasons for using
>> NETLMM in 
>>>>>> the first place: Host changes (adding new SW to the host) and
>>>>>> signalling from the MN. You can see them in section 4 of
>> RFC 4830.
>>>>>> 
>>>>>>   
>>>>>>       
>>>>>>>> go and that it's better to stick with MIP instead of
>> relying on a 
>>>>>>>> solution that will:
>>>>>>>> - work on some L2s and not others,
>>>>>>>>       
>>>>>>>>           
>>>>>>> We have no ability to specify changes to L2 anyway. However if
>>>>>>> some L2s do have such capability, why would we not specify how
>>>>>>> multihoming would work in such scenarios.
>>>>>>>     
>>>>>>>         
>>>>>> => Because we already have a solution that works in all L2s,
>>>>>> doesn't require
>>>>>> L2 changes that we don't control and doesn't cause
>> confusing host 
>>>>>> config solutions.
>>>>>> 
>>>>>>   
>>>>>>       
>>>>>>>> - Require additional SW and config on the host which
>> is not done 
>>>>>>>> anywhere today, and
>>>>>>>>       
>>>>>>>>           
>>>>>>> Why is there as much of a concern about additional SW
>> or config? 
>>>>>>> After all everything (or most of it anyway) that we do
>> in the IETF 
>>>>>>> requires configurations, protocol changes, changes to SW etc.
>>>>>>> There is nothing unique about this.
>>>>>>>     
>>>>>>>         
>>>>>> => Sure, but see above and see RFC 4830. These were the
>> reasons for 
>>>>>> using PMIP in the first place. We can't have it both
>> ways, or can 
>>>>>> we? :)
>>>>>> 
>>>>>>   
>>>>>>       
>>>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>>>       
>>>>>>>>           
>>>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>>>> (informatively)
>>>>>>> what L2 capabilities would enable these features if that is the
>>>>>>> conclusion that we arrive at.
>>>>>>>     
>>>>>>>         
>>>>>> => We can, but I don't know why we should do that when a
>> solution 
>>>>>> already exists. Especially when the alternative is inferior in
>>>>>> terms of its applicability.
>>>>>> 
>>>>>> Hesham
>>>>>> 
>>>>>>   
>>>>>>       
>>>>>>> -Raj
>>>>>>> 
>>>>>>>     
>>>>>>>         
>>>>>>>> This is why I think we should stick with the charter
>> that Jari sent.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hesham
>>>>>>>> 
>>>>>>>>       
>>>>>>>>           
>>>>>>>>> I share the same view with respect to all your other
>> comments. 
>>>>>>>>> We need to seperate the cases of flow mobility vs
>> basic handoff 
>>>>>>>>> as allowed in 5213. In the BOF, we discussed mostly flow
>>>>>>>>> mobility and not the basic handoff cases supported
>> today in 5213.
>>>>>>>>> 
>>>>>>>>> Sri
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>   
>>>>>>       
>>>>>     
>>>> 
>>>> 
>>>>   
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>> 
> 

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Tue, 7 Apr 2009 11:46:20 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C9D3@ftrdmel1> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7CA0D@ftrdmel1>

Regarding PS, we can refer to draft-jeyatharan-netext-multihoming-ps-01 and draft-krishnan-netext-intertech-ps-00. 

Regards,
Pierrick

> -----Message d'origine-----
> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Envoy??: mardi 7 avril 2009 10:18
> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
> jari.arkko at piuha.net; vijay at wichorus.com
> Cc?: netext at mail.mobileip.jp
> Objet?: Re: [Netext] next steps for netext
> 
> There was a lot of interest in ATM many years ago, doesn't mean it's a
> good
> thing. Why can't people describe the reason for wanting to use PMIP for
> this
> sort of thing?? Is there a PS? If not, what are we talking about?
> 
> Hesham
> 
> 
> On 7/04/09 8:13 PM, "pierrick.seite at orange-ftgroup.com"
> <pierrick.seite at orange-ftgroup.com> wrote:
> 
> > Hi all,
> >
> > At least, this thread shows that there is a lot of interest for
> > Inter-technology handover and IP flow mobility with PMIP :-) My
> understanding
> > is that some interesting solutions are suggested (e.g. virtual interface)
> but
> > compliance with NetLMM basics needs clarification. So I definitely agree
> with
> > Telemaco; in a first step, a document giving an overview of solutions
> and
> > assessing host involvement, if any, would help.
> >
> > Regards,
> > Pierrick
> >
> >> -----Message d'origine-----
> >> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> >> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
> >> Envoy??: lundi 6 avril 2009 19:29
> >> ??: Jari Arkko; Vijay Devarapalli
> >> Cc?: netext at mail.mobileip.jp
> >> Objet?: Re: [Netext] next steps for netext
> >>
> >> Hello,
> >>
> >> I think that at this point a pragmatic approach would probably help in
> >> solving some of the controversial issues.
> >> IETF specified 5213 and as such should also specify how hosts are
> supposed
> >> to behave in a PMIPv6 domain.
> >> This should include:
> >> - MN to MAG interface: we had, for instance, such a document in Netlmm.
> It
> >> seems that L2 and L3 solutions are being discussed again, we need to
> >> document them in an Informational document
> >> - Multihoming in PMIPv6: it seems clear there are attractive scenarios
> >> people are willing to explore. Again let's capture all of this in an
> >> informational document.
> >>
> >> Comments?
> >>
> >> telemaco
> >>
> >> -----Message d'origine-----
> >> De : netext-bounces at mail.mobileip.jp [mailto:netext-
> >> bounces at mail.mobileip.jp] De la part de Jari Arkko
> >> Envoy? : lundi 6 avril 2009 19:03
> >> ? : Vijay Devarapalli
> >> Cc : netext at mail.mobileip.jp
> >> Objet : Re: [Netext] next steps for netext
> >>
> >> Vijay ,
> >>
> >>> There was quite a bit of confusion on the "host changes" at the BoF. I
> >>> hope we are not taking decisions based on this confusion. That would
> >>> be very disappointing.
> >>>
> >>
> >> We are not making any decisions yet about the confused or controversial
> >> parts. I sent out the charter so that we can at least move forward with
> >> the rest. I'd be interested in hearing ideas on how to move forward
> with
> >> the inter-access and multihoming parts.
> >>
> >> Jari
> >>
> >> _______________________________________________
> >> 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
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 20:15:09 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7CA37@ftrdmel1>
Message-ID: <[email-masked]>

You obviously were not in the BoF :)

On 7/04/09 9:10 PM, "pierrick.seite at orange-ftgroup.com"
<pierrick.seite at orange-ftgroup.com> wrote:

> 
> I had a more optimistic conclusion after reading :-)
> 
>> -----Message d'origine-----
>> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
>> Envoy??: mardi 7 avril 2009 11:04
>> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
>> jari.arkko at piuha.net; vijay at wichorus.com
>> Cc?: netext at mail.mobileip.jp
>> Objet?: Re: [Netext] next steps for netext
>> 
>> I haven't read draft-jeyatharan but draft-krishnan is basically saying
>> "don't do that". So I'm not sure that you want to use it to argue for
>> what's
>> being proposed here...
>> 
>> Hesham
>> 
>> 
>> On 7/04/09 8:46 PM, "pierrick.seite at orange-ftgroup.com"
>> <pierrick.seite at orange-ftgroup.com> wrote:
>> 
>>> 
>>> Regarding PS, we can refer to draft-jeyatharan-netext-multihoming-ps-01
>> and
>>> draft-krishnan-netext-intertech-ps-00.
>>> 
>>> Regards,
>>> Pierrick
>>> 
>>>> -----Message d'origine-----
>>>> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>> Envoy??: mardi 7 avril 2009 10:18
>>>> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
>>>> jari.arkko at piuha.net; vijay at wichorus.com
>>>> Cc?: netext at mail.mobileip.jp
>>>> Objet?: Re: [Netext] next steps for netext
>>>> 
>>>> There was a lot of interest in ATM many years ago, doesn't mean it's a
>>>> good
>>>> thing. Why can't people describe the reason for wanting to use PMIP for
>>>> this
>>>> sort of thing?? Is there a PS? If not, what are we talking about?
>>>> 
>>>> Hesham
>>>> 
>>>> 
>>>> On 7/04/09 8:13 PM, "pierrick.seite at orange-ftgroup.com"
>>>> <pierrick.seite at orange-ftgroup.com> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> At least, this thread shows that there is a lot of interest for
>>>>> Inter-technology handover and IP flow mobility with PMIP :-) My
>>>> understanding
>>>>> is that some interesting solutions are suggested (e.g. virtual
>> interface)
>>>> but
>>>>> compliance with NetLMM basics needs clarification. So I definitely
>> agree
>>>> with
>>>>> Telemaco; in a first step, a document giving an overview of solutions
>>>> and
>>>>> assessing host involvement, if any, would help.
>>>>> 
>>>>> Regards,
>>>>> Pierrick
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
>>>>>> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
>>>>>> Envoy??: lundi 6 avril 2009 19:29
>>>>>> ??: Jari Arkko; Vijay Devarapalli
>>>>>> Cc?: netext at mail.mobileip.jp
>>>>>> Objet?: Re: [Netext] next steps for netext
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I think that at this point a pragmatic approach would probably help
>> in
>>>>>> solving some of the controversial issues.
>>>>>> IETF specified 5213 and as such should also specify how hosts are
>>>> supposed
>>>>>> to behave in a PMIPv6 domain.
>>>>>> This should include:
>>>>>> - MN to MAG interface: we had, for instance, such a document in
>> Netlmm.
>>>> It
>>>>>> seems that L2 and L3 solutions are being discussed again, we need to
>>>>>> document them in an Informational document
>>>>>> - Multihoming in PMIPv6: it seems clear there are attractive
>> scenarios
>>>>>> people are willing to explore. Again let's capture all of this in an
>>>>>> informational document.
>>>>>> 
>>>>>> Comments?
>>>>>> 
>>>>>> telemaco
>>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : netext-bounces at mail.mobileip.jp [mailto:netext-
>>>>>> bounces at mail.mobileip.jp] De la part de Jari Arkko
>>>>>> Envoy? : lundi 6 avril 2009 19:03
>>>>>> ? : Vijay Devarapalli
>>>>>> Cc : netext at mail.mobileip.jp
>>>>>> Objet : Re: [Netext] next steps for netext
>>>>>> 
>>>>>> Vijay ,
>>>>>> 
>>>>>>> There was quite a bit of confusion on the "host changes" at the BoF.
>> I
>>>>>>> hope we are not taking decisions based on this confusion. That would
>>>>>>> be very disappointing.
>>>>>>> 
>>>>>> 
>>>>>> We are not making any decisions yet about the confused or
>> controversial
>>>>>> parts. I sent out the charter so that we can at least move forward
>> with
>>>>>> the rest. I'd be interested in hearing ideas on how to move forward
>>>> with
>>>>>> the inter-access and multihoming parts.
>>>>>> 
>>>>>> Jari
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>>>>> 
>>>>> _______________________________________________
>>>>> NetExt mailing list
>>>>> NetExt at mail.mobileip.jp
>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>> 
>>> 
>> 
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 20:13:59 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

>> => We're discussing a problem statement for the BoF, so 4830 is quite
>> appropriate as a reference for why people wanted PMIP in the first place.
>>   
> Yes, a problem statement about an existing solution for network-based
> mobility
> management (PMIPv6) to support advanced use cases.

=> Where is that PS?

  Not the problem of
> existing solutions for localized mobility, as RFC4830 does. I don't
> think NetExt
> aims at turning PMIPv6 into a host-based mobility protocol again.

=> I don't know what the goal is based on the BoF discussion and this
discussion on the list. The reason I don't know that is that no one is
saying:
Here is the state of the art (including BOTH MIP and PMIP) and here is why
they don't work, therefore we need to do something new.
That's what a PS should say. What's being said here is "PMIP doesn't support
advanced cases therefore we need something new", which is completely bogus
because PMIP was not designed to support those cases because we already have
something else for supporting those cases. Hence my reference to 4830...

I'm going to retire from the discussion till someone makes the argument
above. Because I feel that if there is no such argument then the discussion
is not a good use of time.

>> => Yes, additional software like the existing MIP. I don't understand the
>> motivation for creating something new. I've detailed this in my previous
>> emails and the points remain unanswered.
>>   
> Nobody talks about adding a piece of client mobility management
> software, such as a
> MIP client, to the mobile. That seems to be a wrong interpretation of
> what NetExt
> wants to do.

=> You're missing the point. Why isn't anybody talking about MIP??? That's
what a PS should say.

Hesham

> 
> marco
> 
> 
>> Hesham
>> 
>> 
>> and obviously also according to RFC4831. We should
>>   
>>> distinguish modification for mobility management, which is not what we
>>> want to do,
>>> and enabling local functions, such as the use of multiple interfaces,
>>> where you have
>>> to add routes, configure interfaces etc. to enable the use case.
>>> 
>>> marco
>>>  
>>> 
>>> Hesham Soliman schrieb:
>>>     
>>>>   
>>>>       
>>>>>> => I think you're distinguishing between modified and unmodified based on
>>>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>>>> for
>>>>>> those that did not attend the BoF, our conclusions were that you will
>>>>>> either
>>>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling
>>>>>> on
>>>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>>>> My opinion, and at least half the room's was that this is not a good way
>>>>>> to
>>>>>>       
>>>>>>           
>>>>> We can discuss what implies host changes and why this is such a big deal
>>>>> anyway. But I don't think that half the room was in agreement as such. At
>>>>> least from the count of hands raised for the question about whether we
>>>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>>>> favor). 
>>>>>     
>>>>>         
>>>> => I think the question changed a few times :) The final question (which
>>>> was
>>>> specific to whether people wanted to work with this or not) showed a split
>>>> room. 
>>>> The host changes are not a big deal but they are mentioned here because
>>>> they
>>>> were one of the very few reasons for using NETLMM in the first place: Host
>>>> changes (adding new SW to the host) and signalling from the MN. You can see
>>>> them in section 4 of RFC 4830.
>>>> 
>>>>   
>>>>       
>>>>>> go and that it's better to stick with MIP instead of relying on a
>>>>>> solution
>>>>>> that will:
>>>>>> - work on some L2s and not others,
>>>>>>       
>>>>>>           
>>>>> We have no ability to specify changes to L2 anyway. However if some L2s do
>>>>> have such capability, why would we not specify how multihoming would work
>>>>> in
>>>>> such scenarios.
>>>>>     
>>>>>         
>>>> => Because we already have a solution that works in all L2s, doesn't
>>>> require
>>>> L2 changes that we don't control and doesn't cause confusing host config
>>>> solutions. 
>>>> 
>>>>   
>>>>       
>>>>>> - Require additional SW and config on the host which is not done anywhere
>>>>>> today, and
>>>>>>       
>>>>>>           
>>>>> Why is there as much of a concern about additional SW or config? After all
>>>>> everything (or most of it anyway) that we do in the IETF requires
>>>>> configurations, protocol changes, changes to SW etc. There is nothing
>>>>> unique
>>>>> about this. 
>>>>>     
>>>>>         
>>>> => Sure, but see above and see RFC 4830. These were the reasons for using
>>>> PMIP in the first place. We can't have it both ways, or can we? :)
>>>> 
>>>>   
>>>>       
>>>>>> - Require L2 signalling which is out of our scope in IETF
>>>>>>       
>>>>>>           
>>>>> Agree. We cannot do anything about L2s. But we could specify
>>>>> (informatively)
>>>>> what L2 capabilities would enable these features if that is the conclusion
>>>>> that we arrive at.
>>>>>     
>>>>>         
>>>> => We can, but I don't know why we should do that when a solution already
>>>> exists. Especially when the alternative is inferior in terms of its
>>>> applicability.
>>>> 
>>>> Hesham
>>>> 
>>>>   
>>>>       
>>>>> -Raj
>>>>> 
>>>>>     
>>>>>         
>>>>>> This is why I think we should stick with the charter that Jari sent.
>>>>>> 
>>>>>> 
>>>>>> Hesham
>>>>>> 
>>>>>>       
>>>>>>           
>>>>>>> I share the same view with respect to all your other comments. We need
>>>>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>>>>> handoff cases supported today in 5213.
>>>>>>> 
>>>>>>> Sri
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>   
>>>>       
>>>     
>> 
>> 
>>   
> 
> 

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Tue, 7 Apr 2009 11:13:02 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C9D3@ftrdmel1>

Hi all,

At least, this thread shows that there is a lot of interest for Inter-technology handover and IP flow mobility with PMIP :-) My understanding is that some interesting solutions are suggested (e.g. virtual interface) but compliance with NetLMM basics needs clarification. So I definitely agree with Telemaco; in a first step, a document giving an overview of solutions and assessing host involvement, if any, would help.

Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
> Envoy??: lundi 6 avril 2009 19:29
> ??: Jari Arkko; Vijay Devarapalli
> Cc?: netext at mail.mobileip.jp
> Objet?: Re: [Netext] next steps for netext
> 
> Hello,
> 
> I think that at this point a pragmatic approach would probably help in
> solving some of the controversial issues.
> IETF specified 5213 and as such should also specify how hosts are supposed
> to behave in a PMIPv6 domain.
> This should include:
> - MN to MAG interface: we had, for instance, such a document in Netlmm. It
> seems that L2 and L3 solutions are being discussed again, we need to
> document them in an Informational document
> - Multihoming in PMIPv6: it seems clear there are attractive scenarios
> people are willing to explore. Again let's capture all of this in an
> informational document.
> 
> Comments?
> 
> telemaco
> 
> -----Message d'origine-----
> De : netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de Jari Arkko
> Envoy? : lundi 6 avril 2009 19:03
> ? : Vijay Devarapalli
> Cc : netext at mail.mobileip.jp
> Objet : Re: [Netext] next steps for netext
> 
> Vijay ,
> 
> > There was quite a bit of confusion on the "host changes" at the BoF. I
> > hope we are not taking decisions based on this confusion. That would
> > be very disappointing.
> >
> 
> We are not making any decisions yet about the confused or controversial
> parts. I sent out the charter so that we can at least move forward with
> the rest. I'd be interested in hearing ideas on how to move forward with
> the inter-access and multihoming parts.
> 
> Jari
> 
> _______________________________________________
> 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

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 20:03:39 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7CA0D@ftrdmel1>
Message-ID: <[email-masked]>

I haven't read draft-jeyatharan but draft-krishnan is basically saying
"don't do that". So I'm not sure that you want to use it to argue for what's
being proposed here...

Hesham

On 7/04/09 8:46 PM, "pierrick.seite at orange-ftgroup.com"
<pierrick.seite at orange-ftgroup.com> wrote:

> 
> Regarding PS, we can refer to draft-jeyatharan-netext-multihoming-ps-01 and
> draft-krishnan-netext-intertech-ps-00.
> 
> Regards,
> Pierrick
> 
>> -----Message d'origine-----
>> De?: Hesham Soliman [mailto:hesham at elevatemobile.com]
>> Envoy??: mardi 7 avril 2009 10:18
>> ??: SEITE Pierrick RD-RESA-REN; Telemaco.Melia at alcatel-lucent.com;
>> jari.arkko at piuha.net; vijay at wichorus.com
>> Cc?: netext at mail.mobileip.jp
>> Objet?: Re: [Netext] next steps for netext
>> 
>> There was a lot of interest in ATM many years ago, doesn't mean it's a
>> good
>> thing. Why can't people describe the reason for wanting to use PMIP for
>> this
>> sort of thing?? Is there a PS? If not, what are we talking about?
>> 
>> Hesham
>> 
>> 
>> On 7/04/09 8:13 PM, "pierrick.seite at orange-ftgroup.com"
>> <pierrick.seite at orange-ftgroup.com> wrote:
>> 
>>> Hi all,
>>> 
>>> At least, this thread shows that there is a lot of interest for
>>> Inter-technology handover and IP flow mobility with PMIP :-) My
>> understanding
>>> is that some interesting solutions are suggested (e.g. virtual interface)
>> but
>>> compliance with NetLMM basics needs clarification. So I definitely agree
>> with
>>> Telemaco; in a first step, a document giving an overview of solutions
>> and
>>> assessing host involvement, if any, would help.
>>> 
>>> Regards,
>>> Pierrick
>>> 
>>>> -----Message d'origine-----
>>>> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
>>>> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
>>>> Envoy??: lundi 6 avril 2009 19:29
>>>> ??: Jari Arkko; Vijay Devarapalli
>>>> Cc?: netext at mail.mobileip.jp
>>>> Objet?: Re: [Netext] next steps for netext
>>>> 
>>>> Hello,
>>>> 
>>>> I think that at this point a pragmatic approach would probably help in
>>>> solving some of the controversial issues.
>>>> IETF specified 5213 and as such should also specify how hosts are
>> supposed
>>>> to behave in a PMIPv6 domain.
>>>> This should include:
>>>> - MN to MAG interface: we had, for instance, such a document in Netlmm.
>> It
>>>> seems that L2 and L3 solutions are being discussed again, we need to
>>>> document them in an Informational document
>>>> - Multihoming in PMIPv6: it seems clear there are attractive scenarios
>>>> people are willing to explore. Again let's capture all of this in an
>>>> informational document.
>>>> 
>>>> Comments?
>>>> 
>>>> telemaco
>>>> 
>>>> -----Message d'origine-----
>>>> De : netext-bounces at mail.mobileip.jp [mailto:netext-
>>>> bounces at mail.mobileip.jp] De la part de Jari Arkko
>>>> Envoy? : lundi 6 avril 2009 19:03
>>>> ? : Vijay Devarapalli
>>>> Cc : netext at mail.mobileip.jp
>>>> Objet : Re: [Netext] next steps for netext
>>>> 
>>>> Vijay ,
>>>> 
>>>>> There was quite a bit of confusion on the "host changes" at the BoF. I
>>>>> hope we are not taking decisions based on this confusion. That would
>>>>> be very disappointing.
>>>>> 
>>>> 
>>>> We are not making any decisions yet about the confused or controversial
>>>> parts. I sent out the charter so that we can at least move forward with
>>>> the rest. I'd be interested in hearing ideas on how to move forward
>> with
>>>> the inter-access and multihoming parts.
>>>> 
>>>> Jari
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>> 
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 19:17:39 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C9D3@ftrdmel1>
Message-ID: <[email-masked]>

There was a lot of interest in ATM many years ago, doesn't mean it's a good
thing. Why can't people describe the reason for wanting to use PMIP for this
sort of thing?? Is there a PS? If not, what are we talking about?

Hesham

On 7/04/09 8:13 PM, "pierrick.seite at orange-ftgroup.com"
<pierrick.seite at orange-ftgroup.com> wrote:

> Hi all,
> 
> At least, this thread shows that there is a lot of interest for
> Inter-technology handover and IP flow mobility with PMIP :-) My understanding
> is that some interesting solutions are suggested (e.g. virtual interface) but
> compliance with NetLMM basics needs clarification. So I definitely agree with
> Telemaco; in a first step, a document giving an overview of solutions and
> assessing host involvement, if any, would help.
> 
> Regards,
> Pierrick
> 
>> -----Message d'origine-----
>> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
>> Envoy??: lundi 6 avril 2009 19:29
>> ??: Jari Arkko; Vijay Devarapalli
>> Cc?: netext at mail.mobileip.jp
>> Objet?: Re: [Netext] next steps for netext
>> 
>> Hello,
>> 
>> I think that at this point a pragmatic approach would probably help in
>> solving some of the controversial issues.
>> IETF specified 5213 and as such should also specify how hosts are supposed
>> to behave in a PMIPv6 domain.
>> This should include:
>> - MN to MAG interface: we had, for instance, such a document in Netlmm. It
>> seems that L2 and L3 solutions are being discussed again, we need to
>> document them in an Informational document
>> - Multihoming in PMIPv6: it seems clear there are attractive scenarios
>> people are willing to explore. Again let's capture all of this in an
>> informational document.
>> 
>> Comments?
>> 
>> telemaco
>> 
>> -----Message d'origine-----
>> De : netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] De la part de Jari Arkko
>> Envoy? : lundi 6 avril 2009 19:03
>> ? : Vijay Devarapalli
>> Cc : netext at mail.mobileip.jp
>> Objet : Re: [Netext] next steps for netext
>> 
>> Vijay ,
>> 
>>> There was quite a bit of confusion on the "host changes" at the BoF. I
>>> hope we are not taking decisions based on this confusion. That would
>>> be very disappointing.
>>> 
>> 
>> We are not making any decisions yet about the confused or controversial
>> parts. I sent out the charter so that we can at least move forward with
>> the rest. I'd be interested in hearing ideas on how to move forward with
>> the inter-access and multihoming parts.
>> 
>> Jari
>> 
>> _______________________________________________
>> 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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 19:15:39 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 7/04/09 6:38 PM, "Marco Liebsch" <marco.liebsch at nw.neclab.eu> wrote:

> We should take RFC4831 as reference doc, which is the design goals document,
> not RFC4830, as it's the PS.

=> We're discussing a problem statement for the BoF, so 4830 is quite
appropriate as a reference for why people wanted PMIP in the first place.

It says what is acceptable, in my
> understanding. Referring
> to section 3.7, which is about Support for Unmodified Hosts, it first
> says 'Support' for
> unmodified hosts. That's what RFC5213 does. It does not exclude modified
> hosts.
> More important, the same section says: "Note that this goal does NOT
> mean that the
> mobile node has no software at all associated with mobility."... That
> looks pretty clear.

=> Did you read section 4? Here is an example:
" 1) Interoperable IP-level protocols that require changes to the
      mobile node's IP stack and handle localized mobility management as
      a service provided to the mobile node by the access network.

   2) Link specific or proprietary protocols that handle localized
      mobility for any mobile node but only for a specific type of link
      layer, for example, 802.11 [6].

   The dedicated localized mobility management IETF protocols for
   Solution 1 are not yet widely deployed, but work continues on
   standardization.  Some Mobile IPv4 deployments use localized mobility
   management.  For Solution 1, the following are specific problems:

   1) The host stack software requirement limits broad usage even if the
      modifications are small.  The success of WLAN switches indicates
      that network operators and users prefer no host stack software
      modifications.  This preference is independent of the lack of
      widespread Mobile IPv4 deployment, since it is much easier to
      deploy and use the network."

> 
> In my opinion, important is that unmodified hosts are supported, which
> is a requirement
> we meet. To support enhanced use cases, some supporting software seems to be
> acceptable in my opinion

=> Yes, additional software like the existing MIP. I don't understand the
motivation for creating something new. I've detailed this in my previous
emails and the points remain unanswered.

Hesham

and obviously also according to RFC4831. We should
> distinguish modification for mobility management, which is not what we
> want to do,
> and enabling local functions, such as the use of multiple interfaces,
> where you have
> to add routes, configure interfaces etc. to enable the use case.
> 
> marco
>  
> 
> Hesham Soliman schrieb:
>>   
>>>> => I think you're distinguishing between modified and unmodified based on
>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>> for
>>>> those that did not attend the BoF, our conclusions were that you will
>>>> either
>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling on
>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>> My opinion, and at least half the room's was that this is not a good way to
>>>>       
>>> We can discuss what implies host changes and why this is such a big deal
>>> anyway. But I don't think that half the room was in agreement as such. At
>>> least from the count of hands raised for the question about whether we
>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>> favor). 
>>>     
>> 
>> => I think the question changed a few times :) The final question (which was
>> specific to whether people wanted to work with this or not) showed a split
>> room. 
>> The host changes are not a big deal but they are mentioned here because they
>> were one of the very few reasons for using NETLMM in the first place: Host
>> changes (adding new SW to the host) and signalling from the MN. You can see
>> them in section 4 of RFC 4830.
>> 
>>   
>>>> go and that it's better to stick with MIP instead of relying on a solution
>>>> that will:
>>>> - work on some L2s and not others,
>>>>       
>>> We have no ability to specify changes to L2 anyway. However if some L2s do
>>> have such capability, why would we not specify how multihoming would work in
>>> such scenarios.
>>>     
>> 
>> => Because we already have a solution that works in all L2s, doesn't require
>> L2 changes that we don't control and doesn't cause confusing host config
>> solutions. 
>> 
>>   
>>>> - Require additional SW and config on the host which is not done anywhere
>>>> today, and
>>>>       
>>> Why is there as much of a concern about additional SW or config? After all
>>> everything (or most of it anyway) that we do in the IETF requires
>>> configurations, protocol changes, changes to SW etc. There is nothing unique
>>> about this. 
>>>     
>> 
>> => Sure, but see above and see RFC 4830. These were the reasons for using
>> PMIP in the first place. We can't have it both ways, or can we? :)
>> 
>>   
>>>> - Require L2 signalling which is out of our scope in IETF
>>>>       
>>> Agree. We cannot do anything about L2s. But we could specify (informatively)
>>> what L2 capabilities would enable these features if that is the conclusion
>>> that we arrive at.
>>>     
>> 
>> => We can, but I don't know why we should do that when a solution already
>> exists. Especially when the alternative is inferior in terms of its
>> applicability.
>> 
>> Hesham
>> 
>>   
>>> -Raj
>>> 
>>>     
>>>> This is why I think we should stick with the charter that Jari sent.
>>>> 
>>>> 
>>>> Hesham
>>>> 
>>>>       
>>>>> I share the same view with respect to all your other comments. We need
>>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>>> handoff cases supported today in 5213.
>>>>> 
>>>>> Sri
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>   
> 
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 07 Apr 2009 09:38:20 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

We should take RFC4831 as reference doc, which is the design goals document,
not RFC4830, as it's the PS. It says what is acceptable, in my 
understanding. Referring
to section 3.7, which is about Support for Unmodified Hosts, it first 
says 'Support' for
unmodified hosts. That's what RFC5213 does. It does not exclude modified 
hosts.
More important, the same section says: "Note that this goal does NOT 
mean that the
mobile node has no software at all associated with mobility."... That 
looks pretty clear.

In my opinion, important is that unmodified hosts are supported, which 
is a requirement
we meet. To support enhanced use cases, some supporting software seems to be
acceptable in my opinion and obviously also according to RFC4831. We should
distinguish modification for mobility management, which is not what we 
want to do,
and enabling local functions, such as the use of multiple interfaces, 
where you have
to add routes, configure interfaces etc. to enable the use case.

marco

Hesham Soliman schrieb:
>   
>>> => I think you're distinguishing between modified and unmodified based on
>>> whether the modification affects IETF protocols or not. That's fine, but for
>>> those that did not attend the BoF, our conclusions were that you will either
>>> end up modifying the host (i.e. Adding new SW) and adding new signalling on
>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>> My opinion, and at least half the room's was that this is not a good way to
>>>       
>> We can discuss what implies host changes and why this is such a big deal
>> anyway. But I don't think that half the room was in agreement as such. At
>> least from the count of hands raised for the question about whether we
>> should work on multihoming and intertech handovers it was about 18-9 (in
>> favor). 
>>     
>
> => I think the question changed a few times :) The final question (which was
> specific to whether people wanted to work with this or not) showed a split
> room. 
> The host changes are not a big deal but they are mentioned here because they
> were one of the very few reasons for using NETLMM in the first place: Host
> changes (adding new SW to the host) and signalling from the MN. You can see
> them in section 4 of RFC 4830.
>
>   
>>> go and that it's better to stick with MIP instead of relying on a solution
>>> that will:
>>> - work on some L2s and not others,
>>>       
>> We have no ability to specify changes to L2 anyway. However if some L2s do
>> have such capability, why would we not specify how multihoming would work in
>> such scenarios.
>>     
>
> => Because we already have a solution that works in all L2s, doesn't require
> L2 changes that we don't control and doesn't cause confusing host config
> solutions. 
>
>   
>>> - Require additional SW and config on the host which is not done anywhere
>>> today, and
>>>       
>> Why is there as much of a concern about additional SW or config? After all
>> everything (or most of it anyway) that we do in the IETF requires
>> configurations, protocol changes, changes to SW etc. There is nothing unique
>> about this. 
>>     
>
> => Sure, but see above and see RFC 4830. These were the reasons for using
> PMIP in the first place. We can't have it both ways, or can we? :)
>
>   
>>> - Require L2 signalling which is out of our scope in IETF
>>>       
>> Agree. We cannot do anything about L2s. But we could specify (informatively)
>> what L2 capabilities would enable these features if that is the conclusion
>> that we arrive at.
>>     
>
> => We can, but I don't know why we should do that when a solution already
> exists. Especially when the alternative is inferior in terms of its
> applicability.
>
> Hesham
>
>   
>> -Raj
>>
>>     
>>> This is why I think we should stick with the charter that Jari sent.
>>>
>>>
>>> Hesham
>>>
>>>       
>>>> I share the same view with respect to all your other comments. We need
>>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>>> handoff cases supported today in 5213.
>>>>
>>>> Sri
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>   

From: Xiangsong.Cui at huawei.com (Xiangsong Cui)
Date: Tue, 07 Apr 2009 13:02:01 +0800
Subject: [Netext] next steps for netext
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

OK, I see.
Thanks a lot.

Xiangsong

????????  

??????????????? ???518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
????????????????????????????????????????
????????????????????????????????????????
???????????????????????????????????
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

  ----- Original Message ----- 
  From: Jari Arkko 
  To: Xiangsong Cui 
  Cc: netext at mail.mobileip.jp 
  Sent: Tuesday, April 07, 2009 12:44 PM
  Subject: Re: [Netext] next steps for netext

  > Do you mean that the "IETF scope" covers RFCs and WG drafts,
  > but not covers individual draft which has not been submitted
  > to IETF?
  >  

  Yes. There are some Internet Drafts that just exist as drafts and are 
  not being submitted by their authors for consideration as a WG document, 
  AD sponsored document, etc. Documents in or proposed to be included to 
  WGs, AD sponsosoring, and so on are within the current IETF scope.

  In the particular case of PMIP4, the authors have not asked IETF to 
  progress their specification. At the time that the draft was brought up, 
  it had already been implemented, and it was unlikely that there'd be any 
  changes, even if based on IETF review some might have been needed. So 
  after some discussion the authors simply requested the RFC Editor to 
  publish their document on the so called "Independent Submission" RFC 
  series. Its basically documenting vendors' and individuals' 
  specifications as-is.

  Jari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/baee7082/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outlook_huawei_logo_cn.jpg
Type: image/jpeg
Size: 6737 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/baee7082/attachment-0001.jpg>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Tue, 07 Apr 2009 07:44:09 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Do you mean that the "IETF scope" covers RFCs and WG drafts,
> but not covers individual draft which has not been submitted
> to IETF?
>  

Yes. There are some Internet Drafts that just exist as drafts and are 
not being submitted by their authors for consideration as a WG document, 
AD sponsored document, etc. Documents in or proposed to be included to 
WGs, AD sponsosoring, and so on are within the current IETF scope.

In the particular case of PMIP4, the authors have not asked IETF to 
progress their specification. At the time that the draft was brought up, 
it had already been implemented, and it was unlikely that there'd be any 
changes, even if based on IETF review some might have been needed. So 
after some discussion the authors simply requested the RFC Editor to 
publish their document on the so called "Independent Submission" RFC 
series. Its basically documenting vendors' and individuals' 
specifications as-is.

Jari

From: w52006 at huawei.com (Yungui Wang)
Date: Tue, 07 Apr 2009 11:44:50 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello 

Here are two comments.

1, Basically, I agree with Rajeev's view there may need a requirement
document/section for 'modified host' if it happens (or is needed). In my
mind, RFC5213 refered mobile node is a general IP node, which is JUST not
required to participate in any IP mobility related signaling for achieving
mobility. It means two things:
i) we should avoid to define special mobile signalling on PMIPv6 mobile
node;
ii) we do not exclude that PMIPv6 solution is using PMIPv6 mobile node's
general L2/L3 signalling or its extension(, although which may lead to some
modifications on host). In fact, RFC5213 has implicitly used such
signalling, for example, value of Handoff Indicator Option is coming from
attach type in 3GPP/WiMAX.

2, Further, following node's capability enhancement, there reflects some
limitations in basis RFC5213 spec for multihoming support, such as absence
of flow mobility, only per-interface-prefix model supported, etc.
Fortunately, some drafts/guys are focusing on that. In this instance, I
think, it is valuable to catch them into the scope of Netext charter.

Regards.  
Yungui

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> Sent: Tuesday, April 07, 2009 1:24 AM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
>  
> I tend to agree that host configurations cannot be ruled out. 
> Case in point: if IPv6 is disabled by default, does enabling 
> it count as host change here? It should not be. Similarly, if 
> folks use a particular technique (e.g., virtual i/f support) 
> provided by host OS, that should be acceptable. If the 
> mechanism is not supported, the feature will not be 
> available, and this can be stated in a 'Requirement' section 
> of the appropriate document.
>  
> -Rajeev
>  
> 
> ________________________________
> 
> From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
> Sent: Mon 4/6/2009 10:11 AM
> To: teemu.savolainen at nokia.com
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> 
> Hi Teemu,
> 
> 
> On Mon, 6 Apr 2009, teemu.savolainen at nokia.com wrote:
> 
> > Hi Sri,
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp
> >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
> >> Gundavelli
> >> Sent: 06 April, 2009 19:11
> >> "unmodified host" can leverage that feature. As we discussed
> >> earlier, we have a major terminology problem, on what is
> >> "modified" vs "un modified". If I use Windows SDK and
> >> implement a virtual interface, no one can claim the host is
> >> now modified. Its an application, or a configuration such as
> >> using bridge ctl utuility in Linux. Its not changing any of
> >
> > At least in my vocabulary that counts as modified host - 
> things are changed in a host to make it behave differently.
> 
> Perfectly fine, if that is the definition of "modified host". I'd
> ask, show me a reference implementation of a host, which tells
> me what is the basic software that is standard and beyond which
> is considered a modified host. Where is that sacred host stack
> definition.
> 
> When I install a OS on my PC, I will install 20 other applications and
> this action is not resulting in my host not inter-operating with any
> other host. That should be our interest and not on what applications I
> install.
> 
> Also, if this is indeed the definition, 5213 already requires 
> this change
> on the host and we have to live with it.
> 
> Regards
> Sri
> 
> _______________________________________________
> 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
> 

From: Xiangsong.Cui at huawei.com (Xiangsong Cui)
Date: Tue, 07 Apr 2009 10:44:24 +0800
Subject: [Netext] next steps for netext
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thank you for your response. I think I get the answer and
I want to confirm it clearly.

Do you mean that the "IETF scope" covers RFCs and WG drafts, 
but not covers individual draft which has not been submitted 
to IETF?

Xiangsong

????????  

??????????????? ???518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
????????????????????????????????????????
????????????????????????????????????????
???????????????????????????????????
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

  ----- Original Message ----- 
  From: Jari Arkko 
  To: Xiangsong Cui 
  Cc: netext at mail.mobileip.jp ; Rajeev Koodli ; Basavaraj Patil 
  Sent: Tuesday, April 07, 2009 1:29 AM
  Subject: Re: [Netext] next steps for netext

  Xiangsong,

  > In my mind the BoF covers both the extensions on PMIP6 and
  > the extension on PMIP4, and also the interworking between
  > them, is it ?
  > After I read the charter, I was impressed that the extensions
  > are only on PMIP6, because the charter mentioned RFC5213 and
  > MEXT WG, but without any information about PMIP4.

  This effort is focused on Proxy Mobile IPv6 and its extensions only 
  (including, of course IPv4 support via 
  draft-ietf-netlmm-pmipv6-ipv4-support).

  Work on PMIP4, i.e., draft-leung-mip4-proxy-mode is currently not in 
  IETF scope; that draft is a non-IETF submission via the RFC editor. This 
  could change, of course, but we did not see any proposals in the BOF on 
  this topic. I suspect it might be a separate effort, if we wanted to do 
  something about it.

  Jari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/1df2bfe2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outlook_huawei_logo_cn.jpg
Type: image/jpeg
Size: 6737 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/1df2bfe2/attachment.jpg>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 7 Apr 2009 08:31:36 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi All,

I perfectly agree with all what Raj has mentioned.I think PMIPv6 is not
only considered for hosts that do not want host chnages but some
operators prefer it because of tight operator controls (packet
inspection filtering....) and as a result 3GPP recomends it for 3G/LTE
access. I agree host changes should be extreme minimal, but real
deployments are not too worried about host changes and why are we here
in IETF so conerned about it. Is there a technical reason?

Inter technology handoff is already specifed in 3GPP sepcifications and
L2 trigger with "H" flag is sent to target MAG to achieve this. So, the
host is chnaged at L2 and people are not too worried about it. Here we
have PMIPv6 which is recommended for 3G and non-3G and the way forward
is to find out how to make it work to support advanced inter technology
handoff and multihoming with minor chnages to the host. If we don't work
on a protocol here, probably 3GPP specs may have their own mechnaism of
doing this. I agree our work should focus on protocol extension in the
MAG to LMA part, but small host implementations should be allowed.

So, my question is, why are we not working on these items here in IETF.
IETF protocols are readily accepted by other SDOs if availble. So it is
better for us to specify these. 

Anyway another point is why are we discussing about inter technology
handoff? RFC 5213 already supports this and ideally we should not
discuss this.

Thanks.

BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Basavaraj.Patil at nokia.com
> Sent: Monday, April 06, 2009 11:49 PM
> To: jari.arkko at piuha.net; netext at mail.mobileip.jp;
rajeev.koodli at gmail.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> Hi Jari,
> 
> I think the discussion (or argument as you put it) at the BoF was
useful.
> It
> highlighted the fact that there is a good amount of misunderstanding
on
> what
> can be done w.r.t multihoming or inter-technology handovers.
> There are some aspects of multihoming that can be clearly separated,
i.e
> the
> flow mobility vs the ability of having a host attached via multiple
> interfaces to the same LMA or dynamically establishing additional
> moobility
> sessions. We could narrow down aspects of multihoming which could fit
into
> the scope of the charter.
> There has been some discussion (online and offline) about the
> inter-technology handovers. The intent of the work item within Netext
is
> to
> clarify host behavior to support such handovers.
> There is obviously quite a strong view of making host changes to
support
> any
> of the features (multihoming or intertechnology handovers). I believe
that
> there will be a class of hosts which will have the capability to
support
> multihoming and support inter-technology handovers. As long as we do
not
> break the PMIP6 RFC (5213), I think it makes sense to specify these
> features. For unmodiified hosts, we can agree that they will not be
able
> to
> perform inter-tech handovers or be support any of the multihoming
> scenarios.
> But to categorically avoid specifying these features within Netext (or
> IETF)
> will only result in non-standard implementations.
> 
> The proposed charter below is a start. But I do believe that we need
to
> include the multihoming and inter-tech handover features as well with
the
> caveat that they should not break backwards compatibility with RFC5213
and
> are applicable only for hosts which "MAY" have certain implementations
> that
> are viewed by some as being modified IP hosts. FWIW we did say that
Netext
> does not mandate "no changes to the host" but will make all efforts to
> limit
> them and try to find solutions that are network centric.
> 
> -Raj
> 
> 
> On 4/3/09 2:31 AM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:
> 
> > In the meeting we ended up having a big argument about the
multihoming
> > and handover parts. I don't know what to do about that yet, but I
would
> > still like to suggest that the other parts should move forward. I
edited
> > the charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > 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.
Hosts
> > are not affected, as they still send and receive their packets via
the
> MAG.
> >
> > 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, and is complementary to the initial LMA discovery work in
the
> > NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009             WG chartered
> > July 2009              Initial WG draft on Bulk Refresh
> > 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 2009       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
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Mon, 06 Apr 2009 14:18:21 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Giaretta, Gerardo wrote:
> Hi Vijay,
> 
> As mentioned I wanted only to highlight that there is not any official dependency on any draft regarding to flow mobility in PMIPv6 and there is not any official decision that 3GPP will standardize anything on this topic (as this is still a study item). Also there are two solutions studied currently in 3GPP for PMIPv6 and no one refers to any I-D - solutions are based on 3GPP private extensions of PMIPv6 already agreed as part of Release 8 (i.e. PCO) or on the Policy Architecture.

Nobody claimed that 3GPP wants a particular internet draft related to 
flow mobility for PMIPv6 to be standardized in the IETF.

> I wanted just to provide the correct information as it would be bad that we take a decision as if there was pressure from other SDOs. Again, this is just to provide the 3GPP status and not to discuss on the merit of any solution.

Its good to have the correct information. What we know for a fact is 
that 3GPP is looking at flow mobility for a system that uses PMIPv6. I 
know it is a study item currently. But folks who want to develop a 
system where PMIPv6 is used and flow mobility is supported as a feature 
would like to see an IETF solution used rather than something that was 
developed outside the IETF.

> Gerardo
> 
> PS: the rapporteur's role is also to track the completion status, to trigger when the study can be considered finished and to serve as a point of contact for tracking the overall status of the work in the workplan discussion, including the percentage of completion of the work (i.e. it is similar to an IETF chair work) - but I don't want to be tedious on this in an IETF mailing list, just make sure you know the definitions before stating them :-)

Sorry, if it sounded like I was trivializing the role of a rapporteur. 
It is hard work.

Vijay

> 
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
>> Sent: Monday, April 06, 2009 10:03 AM
>> To: Giaretta, Gerardo; Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev
>> Koodli; Basavaraj Patil
>> Subject: RE: [Netext] next steps for netext
>>
>> Gerardo,
>>
>> AFAIK, a rapporteur's role in 3GPP is to merely edit the approved
>> contributions and add it to a document. What you say below is right,
>> that there is no 3GPP-IETF dependency currently on any of the internet
>> drafts proposed for netext. But that is completely irrelevant. You have
>> made it sound it as if 3GPP does not want to work on flow mobility for
>> PMIPv6.
>>
>> FWIW, 3GPP TR 23.861 already has sections on flow mobility solutions
>> when PMIPv6 is used. We can either have 3GPP develop solutions for these
>> sections or have IETF develop them. I prefer the second option. :)
>>
>> I think Frank was referring to the fact that a solution is required to
>> address flow mobility with PMIPv6. He wasn't saying 3GPP needs a
>> particular IETF document.
>>
>> Vijay
>>
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
>>> Giaretta, Gerardo
>>> Sent: Monday, April 06, 2009 9:17 AM
>>> To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev
>>> Koodli; Basavaraj Patil
>>> Subject: Re: [Netext] next steps for netext
>>>
>>> Without going into the technical discussion on the merit of
>>> any solution, as rapporteur of 3GPP TR 23.861, I want just to
>>> clarify that this is a wrong piece of information.
>>>
>>> There is no official (or unofficial) reference to any Netext
>>> work on flow mobility for PMIPv6 in any 3GPP document.
>>>
>>> Best Regards
>>> Gerardo
>>>
>>>> -----Original Message-----
>>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp]
>>>> On Behalf Of Frank Xia
>>>> Sent: Monday, April 06, 2009 9:11 AM
>>>> To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli;
>>> Basavaraj Patil
>>>> Subject: Re: [Netext] next steps for netext
>>>>
>>>> Hi Jari
>>>>
>>>> IMHO,  we should prioritize flow mobility which
>>>> is required by both 3GPP and 3GPP2.
>>>>
>>>> BR
>>>> Frank
>>>>
>>>> ----- Original Message -----
>>>> From: "Jari Arkko" <jari.arkko at piuha.net>
>>>> To: <netext at mail.mobileip.jp>; "Rajeev Koodli"
>>> <rajeev.koodli at gmail.com>;
>>>> "Basavaraj Patil" <basavaraj.patil at nokia.com>
>>>> Sent: Friday, April 03, 2009 2:31 AM
>>>> Subject: [Netext] next steps for netext
>>>>
>>>>
>>>>> In the meeting we ended up having a big argument about
>>> the multihoming and
>>>>> handover parts. I don't know what to do about that yet,
>>> but I would still
>>>>> like to suggest that the other parts should move forward.
>>> I edited the
>>>>> charter from the web site. Comments appreciated:
>>>>>
>>>>> -------
>>>>>
>>>>> Network-Based Mobility Extensions (NETEXT)
>>>>>
>>>>> Last Modified: 2009-04-03
>>>>>
>>>>> 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. Hosts are not
>>> affected, as
>>>>> they still send and receive their packets via the MAG.
>>>>>
>>>>> 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,
>>>>> and is complementary to the initial LMA discovery work in
>>> the NETLMM WG.
>>>>> 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.
>>>>>
>>>>> Milestones
>>>>>
>>>>> May 2009             WG chartered
>>>>> July 2009              Initial WG draft on Bulk Refresh
>>>>> 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 2009       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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Mon, 6 Apr 2009 13:30:26 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Yes, all TRs are result of a Study Item. I gave that for granted - sorry if this was imprecise. Usually a TR studies the possible alternative solution and selects one; then if there is enough interest to go for normative work, a TS will document that solution.

Cheers
Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Koodli, Rajeev
> Sent: Monday, April 06, 2009 1:29 PM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
> 
> Hi Gerardo,
> 
> Thanks for sharing this.
> 
> Perhaps we should also point out that this is a study item at this stage
> (?).
> When the TR does move to TS, we would like to see the solutions to be
> aligned with IETF protocols.
> 
> Regards,
> 
> -Rajeev
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > Giaretta, Gerardo
> > Sent: Monday, April 06, 2009 1:10 PM
> > To: Vijay Devarapalli; Frank Xia; Jari Arkko;
> > netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> > Subject: Re: [Netext] next steps for netext
> >
> > Hi Vijay,
> >
> > As mentioned I wanted only to highlight that there is not any
> > official dependency on any draft regarding to flow mobility
> > in PMIPv6 and there is not any official decision that 3GPP
> > will standardize anything on this topic (as this is still a
> > study item). Also there are two solutions studied currently
> > in 3GPP for PMIPv6 and no one refers to any I-D - solutions
> > are based on 3GPP private extensions of PMIPv6 already agreed
> > as part of Release 8 (i.e. PCO) or on the Policy Architecture.
> >
> > I wanted just to provide the correct information as it would
> > be bad that we take a decision as if there was pressure from
> > other SDOs. Again, this is just to provide the 3GPP status
> > and not to discuss on the merit of any solution.
> >
> > Gerardo
> >
> > PS: the rapporteur's role is also to track the completion
> > status, to trigger when the study can be considered finished
> > and to serve as a point of contact for tracking the overall
> > status of the work in the workplan discussion, including the
> > percentage of completion of the work (i.e. it is similar to
> > an IETF chair work) - but I don't want to be tedious on this
> > in an IETF mailing list, just make sure you know the
> > definitions before stating them :-)
> >
> > > -----Original Message-----
> > > From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> > > Sent: Monday, April 06, 2009 10:03 AM
> > > To: Giaretta, Gerardo; Frank Xia; Jari Arkko;
> > netext at mail.mobileip.jp;
> > > Rajeev Koodli; Basavaraj Patil
> > > Subject: RE: [Netext] next steps for netext
> > >
> > > Gerardo,
> > >
> > > AFAIK, a rapporteur's role in 3GPP is to merely edit the approved
> > > contributions and add it to a document. What you say below
> > is right,
> > > that there is no 3GPP-IETF dependency currently on any of
> > the internet
> > > drafts proposed for netext. But that is completely irrelevant. You
> > > have made it sound it as if 3GPP does not want to work on flow
> > > mobility for PMIPv6.
> > >
> > > FWIW, 3GPP TR 23.861 already has sections on flow mobility
> > solutions
> > > when PMIPv6 is used. We can either have 3GPP develop solutions for
> > > these sections or have IETF develop them. I prefer the
> > second option.
> > > :)
> > >
> > > I think Frank was referring to the fact that a solution is
> > required to
> > > address flow mobility with PMIPv6. He wasn't saying 3GPP needs a
> > > particular IETF document.
> > >
> > > Vijay
> > >
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp
> > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Giaretta,
> > > > Gerardo
> > > > Sent: Monday, April 06, 2009 9:17 AM
> > > > To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp;
> > Rajeev Koodli;
> > > > Basavaraj Patil
> > > > Subject: Re: [Netext] next steps for netext
> > > >
> > > > Without going into the technical discussion on the merit of any
> > > > solution, as rapporteur of 3GPP TR 23.861, I want just to clarify
> > > > that this is a wrong piece of information.
> > > >
> > > > There is no official (or unofficial) reference to any
> > Netext work on
> > > > flow mobility for PMIPv6 in any 3GPP document.
> > > >
> > > > Best Regards
> > > > Gerardo
> > > >
> > > > > -----Original Message-----
> > > > > From: netext-bounces at mail.mobileip.jp
> > > > [mailto:netext-bounces at mail.mobileip.jp]
> > > > > On Behalf Of Frank Xia
> > > > > Sent: Monday, April 06, 2009 9:11 AM
> > > > > To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli;
> > > > Basavaraj Patil
> > > > > Subject: Re: [Netext] next steps for netext
> > > > >
> > > > > Hi Jari
> > > > >
> > > > > IMHO,  we should prioritize flow mobility which is required by
> > > > > both 3GPP and 3GPP2.
> > > > >
> > > > > BR
> > > > > Frank
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Jari Arkko" <jari.arkko at piuha.net>
> > > > > To: <netext at mail.mobileip.jp>; "Rajeev Koodli"
> > > > <rajeev.koodli at gmail.com>;
> > > > > "Basavaraj Patil" <basavaraj.patil at nokia.com>
> > > > > Sent: Friday, April 03, 2009 2:31 AM
> > > > > Subject: [Netext] next steps for netext
> > > > >
> > > > >
> > > > > > In the meeting we ended up having a big argument about
> > > > the multihoming and
> > > > > > handover parts. I don't know what to do about that yet,
> > > > but I would still
> > > > > > like to suggest that the other parts should move forward.
> > > > I edited the
> > > > > > charter from the web site. Comments appreciated:
> > > > > >
> > > > > > -------
> > > > > >
> > > > > > Network-Based Mobility Extensions (NETEXT)
> > > > > >
> > > > > > Last Modified: 2009-04-03
> > > > > >
> > > > > > 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. Hosts are not
> > > > affected, as
> > > > > > they still send and receive their packets via the MAG.
> > > > > >
> > > > > > 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,
> > > > > > and is complementary to the initial LMA discovery work in
> > > > the NETLMM WG.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Milestones
> > > > > >
> > > > > > May 2009             WG chartered
> > > > > > July 2009              Initial WG draft on Bulk Refresh
> > > > > > 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 2009       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
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> >
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Mon, 6 Apr 2009 16:28:58 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

Thanks for sharing this.

Perhaps we should also point out that this is a study item at this stage
(?).
When the TR does move to TS, we would like to see the solutions to be
aligned with IETF protocols.

Regards,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Giaretta, Gerardo
> Sent: Monday, April 06, 2009 1:10 PM
> To: Vijay Devarapalli; Frank Xia; Jari Arkko; 
> netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Subject: Re: [Netext] next steps for netext
> 
> Hi Vijay,
> 
> As mentioned I wanted only to highlight that there is not any 
> official dependency on any draft regarding to flow mobility 
> in PMIPv6 and there is not any official decision that 3GPP 
> will standardize anything on this topic (as this is still a 
> study item). Also there are two solutions studied currently 
> in 3GPP for PMIPv6 and no one refers to any I-D - solutions 
> are based on 3GPP private extensions of PMIPv6 already agreed 
> as part of Release 8 (i.e. PCO) or on the Policy Architecture.
> 
> I wanted just to provide the correct information as it would 
> be bad that we take a decision as if there was pressure from 
> other SDOs. Again, this is just to provide the 3GPP status 
> and not to discuss on the merit of any solution.
> 
> Gerardo
> 
> PS: the rapporteur's role is also to track the completion 
> status, to trigger when the study can be considered finished 
> and to serve as a point of contact for tracking the overall 
> status of the work in the workplan discussion, including the 
> percentage of completion of the work (i.e. it is similar to 
> an IETF chair work) - but I don't want to be tedious on this 
> in an IETF mailing list, just make sure you know the 
> definitions before stating them :-)
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> > Sent: Monday, April 06, 2009 10:03 AM
> > To: Giaretta, Gerardo; Frank Xia; Jari Arkko; 
> netext at mail.mobileip.jp; 
> > Rajeev Koodli; Basavaraj Patil
> > Subject: RE: [Netext] next steps for netext
> > 
> > Gerardo,
> > 
> > AFAIK, a rapporteur's role in 3GPP is to merely edit the approved 
> > contributions and add it to a document. What you say below 
> is right, 
> > that there is no 3GPP-IETF dependency currently on any of 
> the internet 
> > drafts proposed for netext. But that is completely irrelevant. You 
> > have made it sound it as if 3GPP does not want to work on flow 
> > mobility for PMIPv6.
> > 
> > FWIW, 3GPP TR 23.861 already has sections on flow mobility 
> solutions 
> > when PMIPv6 is used. We can either have 3GPP develop solutions for 
> > these sections or have IETF develop them. I prefer the 
> second option. 
> > :)
> > 
> > I think Frank was referring to the fact that a solution is 
> required to 
> > address flow mobility with PMIPv6. He wasn't saying 3GPP needs a 
> > particular IETF document.
> > 
> > Vijay
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Giaretta, 
> > > Gerardo
> > > Sent: Monday, April 06, 2009 9:17 AM
> > > To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp; 
> Rajeev Koodli; 
> > > Basavaraj Patil
> > > Subject: Re: [Netext] next steps for netext
> > >
> > > Without going into the technical discussion on the merit of any 
> > > solution, as rapporteur of 3GPP TR 23.861, I want just to clarify 
> > > that this is a wrong piece of information.
> > >
> > > There is no official (or unofficial) reference to any 
> Netext work on 
> > > flow mobility for PMIPv6 in any 3GPP document.
> > >
> > > Best Regards
> > > Gerardo
> > >
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp
> > > [mailto:netext-bounces at mail.mobileip.jp]
> > > > On Behalf Of Frank Xia
> > > > Sent: Monday, April 06, 2009 9:11 AM
> > > > To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli;
> > > Basavaraj Patil
> > > > Subject: Re: [Netext] next steps for netext
> > > >
> > > > Hi Jari
> > > >
> > > > IMHO,  we should prioritize flow mobility which is required by 
> > > > both 3GPP and 3GPP2.
> > > >
> > > > BR
> > > > Frank
> > > >
> > > > ----- Original Message -----
> > > > From: "Jari Arkko" <jari.arkko at piuha.net>
> > > > To: <netext at mail.mobileip.jp>; "Rajeev Koodli"
> > > <rajeev.koodli at gmail.com>;
> > > > "Basavaraj Patil" <basavaraj.patil at nokia.com>
> > > > Sent: Friday, April 03, 2009 2:31 AM
> > > > Subject: [Netext] next steps for netext
> > > >
> > > >
> > > > > In the meeting we ended up having a big argument about
> > > the multihoming and
> > > > > handover parts. I don't know what to do about that yet,
> > > but I would still
> > > > > like to suggest that the other parts should move forward.
> > > I edited the
> > > > > charter from the web site. Comments appreciated:
> > > > >
> > > > > -------
> > > > >
> > > > > Network-Based Mobility Extensions (NETEXT)
> > > > >
> > > > > Last Modified: 2009-04-03
> > > > >
> > > > > 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. Hosts are not
> > > affected, as
> > > > > they still send and receive their packets via the MAG.
> > > > >
> > > > > 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,
> > > > > and is complementary to the initial LMA discovery work in
> > > the NETLMM WG.
> > > > >
> > > > > 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.
> > > > >
> > > > > Milestones
> > > > >
> > > > > May 2009             WG chartered
> > > > > July 2009              Initial WG draft on Bulk Refresh
> > > > > 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 2009       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
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > >
> > > _______________________________________________
> > > 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
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Mon, 6 Apr 2009 13:10:25 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Vijay,

As mentioned I wanted only to highlight that there is not any official dependency on any draft regarding to flow mobility in PMIPv6 and there is not any official decision that 3GPP will standardize anything on this topic (as this is still a study item). Also there are two solutions studied currently in 3GPP for PMIPv6 and no one refers to any I-D - solutions are based on 3GPP private extensions of PMIPv6 already agreed as part of Release 8 (i.e. PCO) or on the Policy Architecture.

I wanted just to provide the correct information as it would be bad that we take a decision as if there was pressure from other SDOs. Again, this is just to provide the 3GPP status and not to discuss on the merit of any solution.

Gerardo

PS: the rapporteur's role is also to track the completion status, to trigger when the study can be considered finished and to serve as a point of contact for tracking the overall status of the work in the workplan discussion, including the percentage of completion of the work (i.e. it is similar to an IETF chair work) - but I don't want to be tedious on this in an IETF mailing list, just make sure you know the definitions before stating them :-)

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> Sent: Monday, April 06, 2009 10:03 AM
> To: Giaretta, Gerardo; Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev
> Koodli; Basavaraj Patil
> Subject: RE: [Netext] next steps for netext
> 
> Gerardo,
> 
> AFAIK, a rapporteur's role in 3GPP is to merely edit the approved
> contributions and add it to a document. What you say below is right,
> that there is no 3GPP-IETF dependency currently on any of the internet
> drafts proposed for netext. But that is completely irrelevant. You have
> made it sound it as if 3GPP does not want to work on flow mobility for
> PMIPv6.
> 
> FWIW, 3GPP TR 23.861 already has sections on flow mobility solutions
> when PMIPv6 is used. We can either have 3GPP develop solutions for these
> sections or have IETF develop them. I prefer the second option. :)
> 
> I think Frank was referring to the fact that a solution is required to
> address flow mobility with PMIPv6. He wasn't saying 3GPP needs a
> particular IETF document.
> 
> Vijay
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > Giaretta, Gerardo
> > Sent: Monday, April 06, 2009 9:17 AM
> > To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev
> > Koodli; Basavaraj Patil
> > Subject: Re: [Netext] next steps for netext
> >
> > Without going into the technical discussion on the merit of
> > any solution, as rapporteur of 3GPP TR 23.861, I want just to
> > clarify that this is a wrong piece of information.
> >
> > There is no official (or unofficial) reference to any Netext
> > work on flow mobility for PMIPv6 in any 3GPP document.
> >
> > Best Regards
> > Gerardo
> >
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp]
> > > On Behalf Of Frank Xia
> > > Sent: Monday, April 06, 2009 9:11 AM
> > > To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli;
> > Basavaraj Patil
> > > Subject: Re: [Netext] next steps for netext
> > >
> > > Hi Jari
> > >
> > > IMHO,  we should prioritize flow mobility which
> > > is required by both 3GPP and 3GPP2.
> > >
> > > BR
> > > Frank
> > >
> > > ----- Original Message -----
> > > From: "Jari Arkko" <jari.arkko at piuha.net>
> > > To: <netext at mail.mobileip.jp>; "Rajeev Koodli"
> > <rajeev.koodli at gmail.com>;
> > > "Basavaraj Patil" <basavaraj.patil at nokia.com>
> > > Sent: Friday, April 03, 2009 2:31 AM
> > > Subject: [Netext] next steps for netext
> > >
> > >
> > > > In the meeting we ended up having a big argument about
> > the multihoming and
> > > > handover parts. I don't know what to do about that yet,
> > but I would still
> > > > like to suggest that the other parts should move forward.
> > I edited the
> > > > charter from the web site. Comments appreciated:
> > > >
> > > > -------
> > > >
> > > > Network-Based Mobility Extensions (NETEXT)
> > > >
> > > > Last Modified: 2009-04-03
> > > >
> > > > 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. Hosts are not
> > affected, as
> > > > they still send and receive their packets via the MAG.
> > > >
> > > > 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,
> > > > and is complementary to the initial LMA discovery work in
> > the NETLMM WG.
> > > >
> > > > 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.
> > > >
> > > > Milestones
> > > >
> > > > May 2009             WG chartered
> > > > July 2009              Initial WG draft on Bulk Refresh
> > > > 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 2009       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
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >

From: teemu.savolainen at nokia.com (teemu.savolainen at nokia.com)
Date: Mon, 6 Apr 2009 21:46:15 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri, 

>-----Original Message-----
>From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
>> At least in my vocabulary that counts as modified host - 
>things are changed in a host to make it behave differently.
>
>Perfectly fine, if that is the definition of "modified host". 
>I'd ask, show me a reference implementation of a host, which 
>tells me what is the basic software that is standard and 
>beyond which is considered a modified host. Where is that 
>sacred host stack definition.

There's no such thing as reference host implementation as far as I know. That is exactly the reason why I consider also all "configuration tricks" as host changes - those place assumptions on hosts' capabilities. On some OS'es virtual interfaces can perhaps be configured with few magical commands or scripts, but on some OS'es the same thing requires implementation of new C-code. Thus the claim that with PMIP it is possible to do inter-access mobility is just not true, as it requires *some* changes in at least on some Oses (or alternatively hiding everything below L2). If the PMIP would already support inter-access mobility, it would not require *any* changes. If the inter-access mobility can be realized with a virtual interface, then we could just acknowledge that some host changes are needed, document what they are, and say that realizing those means less effort on some OSes than on others.

Best regards,

	Teemu

From: ryuji.wakikawa at gmail.com (Ryuji Wakikawa)
Date: Mon, 6 Apr 2009 14:52:39 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The virtual interface is not new.
All operating system should have one, that is loopback interface.

regards,
ryuji

On 2009/04/06, at 12:40, <Basavaraj.Patil at nokia.com> <Basavaraj.Patil at nokia.com 
 > wrote:

>
> Hi Sri,
>
> Obviously everyone has a different view on what constitutes a host  
> change.
> Creating a virtual interface on a host may be supported on some  
> platforms
> and not on others. I don't think there is a debate about whether  
> such an
> interface can be created to handle handovers. But more importantly,  
> does
> such an interface imply that the host is unmodified.
> IMO, the term "Unmodified host" is too vague to have any real value  
> in this
> discussion. You could have a host which is designed for a network  
> which has
> PMIP6 based mobility support and hence implements a virtual  
> interface as a
> default to support intertechnology handovers. Is this not an  
> unmodified
> host? Does "Unmodified host" always imply a Windows or Mac host as  
> shipped
> from the manufacturers in IETF terminology?
> I strongly believe that there are different classes of hosts which  
> have
> different capabilities and default characteristics. We can spend a  
> lot of
> time on trying to define what constitutes an unmodified host in the  
> IETF
> context. But this is not going to really help in any way.
>
> If we can instead agree that in order to support multihoming or
> inter-technology handovers there may be some implications to the  
> host, we
> would make more progress. We are not proposing defining a new  
> protocol per
> se that is needed on the MN to enable handovers or multihoming  
> support.
>
> -Raj
>
>
> On 4/6/09 11:10 AM, "Sri Gundavelli" <sgundave at cisco.com> wrote:
>
>> Hi Raj:
>>
>> Just one comment.
>>
>>
>>
>> On Mon, 6 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>
>>>
>>> Hi Jari,
>>>
>>> I think the discussion (or argument as you put it) at the BoF was  
>>> useful. It
>>> highlighted the fact that there is a good amount of  
>>> misunderstanding on what
>>> can be done w.r.t multihoming or inter-technology handovers.
>>> There are some aspects of multihoming that can be clearly  
>>> separated, i.e the
>>> flow mobility vs the ability of having a host attached via multiple
>>> interfaces to the same LMA or dynamically establishing additional  
>>> moobility
>>> sessions. We could narrow down aspects of multihoming which could  
>>> fit into
>>> the scope of the charter.
>>> There has been some discussion (online and offline) about the
>>> inter-technology handovers. The intent of the work item within  
>>> Netext is to
>>> clarify host behavior to support such handovers.
>>> There is obviously quite a strong view of making host changes to  
>>> support any
>>> of the features (multihoming or intertechnology handovers). I  
>>> believe that
>>> there will be a class of hosts which will have the capability to  
>>> support
>>> multihoming and support inter-technology handovers. As long as we  
>>> do not
>>> break the PMIP6 RFC (5213), I think it makes sense to specify these
>>> features.
>>
>>> For unmodiified hosts, we can agree that they will not be able to
>>> perform inter-tech handovers or be support any of the multihoming  
>>> scenarios.
>>
>> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
>> host" can leverage that feature. As we discussed earlier, we have a  
>> major
>> terminology problem, on what is "modified" vs "un modified". If I use
>> Windows SDK and implement a virtual interface, no one can claim the  
>> host
>> is now modified. Its an application, or a configuration such as using
>> bridge ctl utuility in Linux. Its not changing any of the IETF
>> specifications. We also need to revisit this in the context of  
>> connection
>> mgr requirements in both client-based and network-based mobility  
>> models,
>> which is a common requirement, or other intefaces such as MIF, for
>> flow template push to the terminal.
>>
>> I share the same view with respect to all your other comments. We  
>> need
>> to seperate the cases of flow mobility vs basic handoff as allowed in
>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>> handoff cases supported today in 5213.
>>
>> Sri
>>
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 06 Apr 2009 21:19:07 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri, Rajeev,

>> FYI: these items are not "cherry-picked" nor or they random!
>>
>> Folks have spent time on this over months (since Dublin meeting).
>>
>> Of course you are free to propose other items, but please go back and 
>> read the archives and past meeting materials before expressing 
>> comments on topics which you may not be fully aware of :-)
>>
>
> Ok. Fair enough. I may have missed the discussions. Or, since it was a 
> BOF
> ML, not many folks may have had the chance to provide input. In any case,
> no offense here. But, since the WG is now formally getting approved, it
> might be better to get feedback from the list on the items that should be
> in the list, before the charter is formally fixed.

We do accept -- in fact we highly encourage -- other people from outside 
the core BOF constituency to provide feedback on what a new WG should 
and should not work on. In that sense Sri's input is very welcome, 
particularly given his close involvement in Proxy Mobile IPv6 
technology. So it is fine to suggest more work items, or comment on the 
existing ones. However, Rajeev is right in the sense that we have a 
process through which all of this is being developed. Proposal for new 
work comes from some set of people, and is refined through discussion on 
the list and in the meeting, AD/IESG review, etc. In particular, the 
proposals on the table in the BOF are in a far easier place to enter the 
final charter, because we had an opportunity for the community to review 
and comment on those proposals. We can add items, and small things can 
be added very easily. For larger things we might need more discussion...

Jari

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 06 Apr 2009 21:04:13 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sri,

Thanks for your input. Inline:

> I've a concern with the planned charter. The list is too random and
> cherry picked and I dont believe proper input from all the folks went 
> into
> this. There are many other items that are required for a reasonable
> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
> years, some of them that were left out in the base spec, some that we
> realized as gaps when compared to other SDO protocols and some as
> optimizations that we realized while implementing PMIP6, these items
> should be in the initial scope.
>
> I understand the charter needs to be limited in scope, but just 3 or 4
> random items, I'm not sure if this helps in short term PMIP6 
> requirements.
> I've no issue with the currently listed items, but there are other items
> that should get equal or higher priority.

I have no problem with adding more. Even the charter says new things can 
be added.

However, from a process perspective what I did was to take the proposal 
on the table, i.e., the full BOF scope and see what parts of that we 
already have an agreement on. I didn't include other things that were 
not discussed in the BOF. Maybe that would have been useful, but they 
were not on the table.

We could add more items now, if there's general agreement that those 
things are useful. However, I do not want to declare an open season on 
doing everything. We pick a reasonable subset of all proposed work, 
based on priorities, community agreement that they are the right things 
to do, management reasons to ensure that we are not doing too much, etc.

> For example, item #6, is absolutely required, from the perspective of
> having a complete specification of 5213. There we allowed a mobile 
> node to
> perform handoff betweek two interfaces. We defined all the hooks on the
> network side, but we did not provide how a terminal vendor can support
> that. A simple informational draft on how some one move prefixes between
> interfaces will greatly help. Some guidance on how to create a virtual
> interface and also some related notes for each platform (Linux, BSD,
> Android ..etc). This should not fall in the controversial discussion 
> scope
> of same address on two interfaces etc, thats a different problem, or 
> about
> the issue of enhancing mobile node's capabilities. This is just
> informational work, required to leverage what 5213 already supports.

I suspect this is about the scoping of the handoff work. Lets try to 
figure out what makes sense (I personally believe the above item makes 
sense, for instance) and what doesn't.

The fact that these parts were not in the charter was not a declaration 
that we're dismissing them. Its just that we didn't finish the 
discussion, but I still wanted to let the other things move forward.

> Item #2, is required. The multimob BOF raised some issues, we need to
> show how multicast services can be enabled in PMIP network. May be this
> wont require extensions, a simple draft covering those aspects will help.

As you may recall, in the Multimob BOF we did not have an agreement on 
what exactly is needed, if anything. My own conclusion is that we 
probably need at least an informational document that explains how to 
use RFC 5213 for multicast. I think we discussed the possibility of 
doing this as some kind of AD sponsored document or in one of the 
relevant WGs, as a joint work between PMIP and multicast experts.

I'm on the fence about adding this work to the charter right now, mainly 
because the BOF back then was very inconclusive. I'd be happier if I saw 
an actual well written draft from say you and some of the multicast 
experts. There's no problem moving good documents forward, even if they 
are not in the charter of some WG. Then again, I wouldn't necessarily 
mind a maintenance like item for this in one of the WG charters either.

> I think, the charter should be bit more relaxed and more extensive. As I
> see it, atleast the folks are interested in doing the work. We should add
> atleast 4 or 5 more items to this list.

Generally speaking IETF WG charters give specific work items that the WG 
should work on. I had hoped that the charter text:

"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."

gives an indication that we intend to do more! I am also personally very 
happy to add more items to the group's charter. All in all, I do know 
that the current charter is a bit on the thin side -- mostly because the 
multihoming/interaccess issue is under discussion.

There's also the question of general maintenance items. Some IETF WGs 
have a general work item to fix problems and issue updates to existing 
specifications. I think we need to do that for Proxy Mobile IPv6 as 
well. But we have not decided whether that item should go to NETLMM or 
NETEXT WG yet. Please rest assured that the work will be possible 
regardless of this.

> 1. Dynamic LMA Assignment
>
> In blade architecture systems or in a load balancer configuration, the 
> PDNGW
> should have the ability to dynamically assign a LMA on the fly, along the
> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> [RFC-4433].
> Currently, GTP provides such semantics and this is a important 
> requirement
> for deployment. Here the goal is to
>
> a.) Expose a single IP address to the SGW
> b.) The exposed IP address should not be in path once the assignment is
> done.
>
>
>
> [LMA1]---
> | |
> [LMA2]--[LMA]==========[MAG]
> | |
> [LMA3]---
>
>
> Along the lines of:
>
> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01

This is in the proposed NETEXT charter already.

> 2. Multicast Support in Proxy Mobile IPv6
>
> We need an informational specification on how multicast support can be
> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive 
> analysis
> on
> this. This is required and critical for enabling any multicast services.
> However,
> Behcet may disagree with the scope of the work.

See above.

> 3. Bulk Registration Support
>
> This is a simple extension which helps in signaling optimization, 
> along the
> lines of:
>
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02

This is in the charter as well.

> 4. Partial Failover Support
>
> We need a mechanism to notify the peer on revoke a partial set of 
> bindings.
>
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00. 
>
> txt

Hmm. Ok. This needs more discussion.

> 5. Group Identifier Support for Proxy Mobile IPv6
>
> This provides a simple and a generic semantic for assigning a group
> identifier
> to a mobile node's binding. GTP has very similar semantics, Connexion Set
> Id.
> Both #3 and #4 can leverage this. Additionally, in load balancer systems
> where
> the load balancer is in path for all signaling messages, it can use 
> this as
> a
> tag for redirecting the message.
>
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

Since the bulk registration work is in the charter, can't you do the 
sensible design (whatever it is) under that? There is no requirement 
that one charter item equals one document.

> 6. Virtual-Interface Support on IP host for supporting Inter-tech 
> handoffs:
>
>
> RFC-5213 supports handoff between two interfaces. The ability to move
> prefixes between interfaces. In other words address continuity is assured
> with any IPv6 host on the planet and with absolutely no changes. This 
> meets
> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
> not assured is the aspect of session continuity. Which requires a virtual
> interface implementation on the host, by binding the address/prefix to a
> virtual interface and by not exposing the physical interface or by hiding
> the handoff events from the layer-3 stack.
>
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
>
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00

This is part of the discussion that we need to finish. But I plan to let 
the rest of the stuff move forward even before we have done that.

> 7. Route Optimization for Proxy Mobile IPv6
>
> There were atleast 4 drafts in this area on Route Optimization. Marco
> Liebsch
> analyzed this exensively:
>
>
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00. 
>
> txt

This is in the charter.

> 8. Prefix Management in Proxy Mobile IPv6 support
>
> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
> to a given mobile node's interface. It might be useful to specify how the
> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
> AAA to manage this aspect. Behcet has one draft on this.

I'm not personally sold on this particular work. But again, this could 
be something to consider.

> 9. Partial Handoff Support
>
> We are missing some semantics in 5213 for moving a subset of the prefixes
> between interfaces as part of the inter-tech handoff. This is about 
> defining
> a new handoff value. This allows partial flow management, but moving the
> flows associated to a prefix, as a whole group.
>
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00 
>

A part of the topic we still need to discuss...

> 10. CMIPv4/PMIP Interworking
>
> This is probably required to specify how an IPv4-only can move between
> CMIP and PMIP environments.
>
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft- 
>
> meghana-netlmm-pmipv6-mipv4-00.txt

Client MIPv6 and Proxy MIPv6 interoperability is already in the NETLMM 
charter, but this work is presumably about interaction with MIPv4. Might 
be useful work, I wouldn't mind if this was done in NETEXT at some 
point. Is this crucial to be in the first revision of the WG's charter?

> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6

Can you expand on this?

Jari

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 06 Apr 2009 20:29:49 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Xiangsong,

> In my mind the BoF covers both the extensions on PMIP6 and
> the extension on PMIP4, and also the interworking between
> them, is it ?
> After I read the charter, I was impressed that the extensions
> are only on PMIP6, because the charter mentioned RFC5213 and
> MEXT WG, but without any information about PMIP4.

This effort is focused on Proxy Mobile IPv6 and its extensions only 
(including, of course IPv4 support via 
draft-ietf-netlmm-pmipv6-ipv4-support).

Work on PMIP4, i.e., draft-leung-mip4-proxy-mode is currently not in 
IETF scope; that draft is a non-IETF submission via the RFC editor. This 
could change, of course, but we did not see any proposals in the BOF on 
this topic. I suspect it might be a separate effort, if we wanted to do 
something about it.

Jari

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Mon, 6 Apr 2009 19:28:58 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I think that at this point a pragmatic approach would probably help in solving some of the controversial issues.
IETF specified 5213 and as such should also specify how hosts are supposed to behave in a PMIPv6 domain.
This should include:
- MN to MAG interface: we had, for instance, such a document in Netlmm. It seems that L2 and L3 solutions are being discussed again, we need to document them in an Informational document
- Multihoming in PMIPv6: it seems clear there are attractive scenarios people are willing to explore. Again let's capture all of this in an informational document.

Comments?

telemaco

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Jari Arkko
Envoy? : lundi 6 avril 2009 19:03
? : Vijay Devarapalli
Cc : netext at mail.mobileip.jp
Objet : Re: [Netext] next steps for netext

Vijay ,

> There was quite a bit of confusion on the "host changes" at the BoF. I 
> hope we are not taking decisions based on this confusion. That would 
> be very disappointing.
>   

We are not making any decisions yet about the confused or controversial parts. I sent out the charter so that we can at least move forward with the rest. I'd be interested in hearing ideas on how to move forward with the inter-access and multihoming parts.

Jari

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

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 06 Apr 2009 20:26:17 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ahmad,

> The proposed charter looks good to me. However, one comment below. I
> probably should have made this comment when the topic of Bulk refresh
> was discussed.
> Such a proposed change, although, it is useful, but could introduce some
> unwanted scenarios and race conditions. From the scenarios that come to
> mind the following:
>   

This is a valid concern. I hope the guys working on this have figured 
out a way to avoid the problem...

However, I do believe that we can leave the explicit requirement to 
avoid race conditions out of the charter text. It is one of a number of 
technical things the group must get right in order to have a document 
that can move forward.

Jari

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Mon, 6 Apr 2009 13:24:27 -0400
Subject: [Netext] next steps for netext
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I tend to agree that host configurations cannot be ruled out. Case in point: if IPv6 is disabled by default, does enabling it count as host change here? It should not be. Similarly, if folks use a particular technique (e.g., virtual i/f support) provided by host OS, that should be acceptable. If the mechanism is not supported, the feature will not be available, and this can be stated in a 'Requirement' section of the appropriate document.
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
Sent: Mon 4/6/2009 10:11 AM
To: teemu.savolainen at nokia.com
Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: Re: [Netext] next steps for netext

Hi Teemu,

On Mon, 6 Apr 2009, teemu.savolainen at nokia.com wrote:

> Hi Sri,
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>> Gundavelli
>> Sent: 06 April, 2009 19:11
>> "unmodified host" can leverage that feature. As we discussed
>> earlier, we have a major terminology problem, on what is
>> "modified" vs "un modified". If I use Windows SDK and
>> implement a virtual interface, no one can claim the host is
>> now modified. Its an application, or a configuration such as
>> using bridge ctl utuility in Linux. Its not changing any of
>
> At least in my vocabulary that counts as modified host - things are changed in a host to make it behave differently.

Perfectly fine, if that is the definition of "modified host". I'd
ask, show me a reference implementation of a host, which tells
me what is the basic software that is standard and beyond which
is considered a modified host. Where is that sacred host stack
definition.

When I install a OS on my PC, I will install 20 other applications and
this action is not resulting in my host not inter-operating with any
other host. That should be our interest and not on what applications I
install.

Also, if this is indeed the definition, 5213 already requires this change
on the host and we have to live with it.

Regards
Sri

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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 6 Apr 2009 10:11:10 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Teemu,

On Mon, 6 Apr 2009, teemu.savolainen at nokia.com wrote:

> Hi Sri,
>
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri
>> Gundavelli
>> Sent: 06 April, 2009 19:11
>> "unmodified host" can leverage that feature. As we discussed
>> earlier, we have a major terminology problem, on what is
>> "modified" vs "un modified". If I use Windows SDK and
>> implement a virtual interface, no one can claim the host is
>> now modified. Its an application, or a configuration such as
>> using bridge ctl utuility in Linux. Its not changing any of
>
> At least in my vocabulary that counts as modified host - things are changed in a host to make it behave differently.

Perfectly fine, if that is the definition of "modified host". I'd
ask, show me a reference implementation of a host, which tells
me what is the basic software that is standard and beyond which
is considered a modified host. Where is that sacred host stack
definition.

When I install a OS on my PC, I will install 20 other applications and
this action is not resulting in my host not inter-operating with any
other host. That should be our interest and not on what applications I
install.

Also, if this is indeed the definition, 5213 already requires this change
on the host and we have to live with it.

Regards
Sri

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 6 Apr 2009 10:05:26 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 7 Apr 2009, Hesham Soliman wrote:

>
>>
>> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
>> host" can leverage that feature. As we discussed earlier, we have a major
>> terminology problem, on what is "modified" vs "un modified". If I use
>> Windows SDK and implement a virtual interface, no one can claim the host
>> is now modified. Its an application, or a configuration such as using
>> bridge ctl utuility in Linux. Its not changing any of the IETF
>> specifications. We also need to revisit this in the context of connection
>> mgr requirements in both client-based and network-based mobility models,
>> which is a common requirement, or other intefaces such as MIF, for
>> flow template push to the terminal.
>
> => I think you're distinguishing between modified and unmodified based on
> whether the modification affects IETF protocols or not. That's fine, but for

Yes. And the reason: There is no such sacred host stack which tells
me what applications I should expect in a "unmodified" host. There
is no such reference. If I install Fedora, XP, Mac OS/X, each of these
hosts come with a different tool set and drivers. But, they all comply
to IETF specs and thats what we should ensure. So, the distinction is
based on what specs our protocol extensions can potentially modify or
if its involved in mobility signaling.

Regards
Sri

> those that did not attend the BoF, our conclusions were that you will either
> end up modifying the host (i.e. Adding new SW) and adding new signalling on
> L2 to handle the multihoming cases, or you can stick with MIP.
> My opinion, and at least half the room's was that this is not a good way to
> go and that it's better to stick with MIP instead of relying on a solution
> that will:
> - work on some L2s and not others,
> - Require additional SW and config on the host which is not done anywhere
> today, and
> - Require L2 signalling which is out of our scope in IETF
>
> This is why I think we should stick with the charter that Jari sent.
>
>
> Hesham
>
>>
>> I share the same view with respect to all your other comments. We need
>> to seperate the cases of flow mobility vs basic handoff as allowed in
>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>> handoff cases supported today in 5213.
>>
>> Sri
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>
>
>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 06 Apr 2009 20:03:04 +0300
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Vijay ,

> There was quite a bit of confusion on the "host changes" at the BoF. I
> hope we are not taking decisions based on this confusion. That would be
> very disappointing.
>   

We are not making any decisions yet about the confused or controversial 
parts. I sent out the charter so that we can at least move forward with 
the rest. I'd be interested in hearing ideas on how to move forward with 
the inter-access and multihoming parts.

Jari

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Mon, 6 Apr 2009 13:02:56 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Gerardo,

AFAIK, a rapporteur's role in 3GPP is to merely edit the approved
contributions and add it to a document. What you say below is right,
that there is no 3GPP-IETF dependency currently on any of the internet
drafts proposed for netext. But that is completely irrelevant. You have
made it sound it as if 3GPP does not want to work on flow mobility for
PMIPv6.

FWIW, 3GPP TR 23.861 already has sections on flow mobility solutions
when PMIPv6 is used. We can either have 3GPP develop solutions for these
sections or have IETF develop them. I prefer the second option. :)

I think Frank was referring to the fact that a solution is required to
address flow mobility with PMIPv6. He wasn't saying 3GPP needs a
particular IETF document.

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Giaretta, Gerardo
> Sent: Monday, April 06, 2009 9:17 AM
> To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev 
> Koodli; Basavaraj Patil
> Subject: Re: [Netext] next steps for netext
> 
> Without going into the technical discussion on the merit of 
> any solution, as rapporteur of 3GPP TR 23.861, I want just to 
> clarify that this is a wrong piece of information. 
> 
> There is no official (or unofficial) reference to any Netext 
> work on flow mobility for PMIPv6 in any 3GPP document.
> 
> Best Regards
> Gerardo
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp]
> > On Behalf Of Frank Xia
> > Sent: Monday, April 06, 2009 9:11 AM
> > To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli; 
> Basavaraj Patil
> > Subject: Re: [Netext] next steps for netext
> > 
> > Hi Jari
> > 
> > IMHO,  we should prioritize flow mobility which
> > is required by both 3GPP and 3GPP2.
> > 
> > BR
> > Frank
> > 
> > ----- Original Message -----
> > From: "Jari Arkko" <jari.arkko at piuha.net>
> > To: <netext at mail.mobileip.jp>; "Rajeev Koodli" 
> <rajeev.koodli at gmail.com>;
> > "Basavaraj Patil" <basavaraj.patil at nokia.com>
> > Sent: Friday, April 03, 2009 2:31 AM
> > Subject: [Netext] next steps for netext
> > 
> > 
> > > In the meeting we ended up having a big argument about 
> the multihoming and
> > > handover parts. I don't know what to do about that yet, 
> but I would still
> > > like to suggest that the other parts should move forward. 
> I edited the
> > > charter from the web site. Comments appreciated:
> > >
> > > -------
> > >
> > > Network-Based Mobility Extensions (NETEXT)
> > >
> > > Last Modified: 2009-04-03
> > >
> > > 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. Hosts are not 
> affected, as
> > > they still send and receive their packets via the MAG.
> > >
> > > 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,
> > > and is complementary to the initial LMA discovery work in 
> the NETLMM WG.
> > >
> > > 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.
> > >
> > > Milestones
> > >
> > > May 2009             WG chartered
> > > July 2009              Initial WG draft on Bulk Refresh
> > > 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 2009       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
> > >
> > > _______________________________________________
> > > 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
> 
> _______________________________________________
> 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: Mon, 6 Apr 2009 19:02:08 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Hesham,

On 4/6/09 10:37 AM, "ext Hesham Soliman" <hesham at elevatemobile.com> wrote:

> 
> 
>> 
>> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
>> host" can leverage that feature. As we discussed earlier, we have a major
>> terminology problem, on what is "modified" vs "un modified". If I use
>> Windows SDK and implement a virtual interface, no one can claim the host
>> is now modified. Its an application, or a configuration such as using
>> bridge ctl utuility in Linux. Its not changing any of the IETF
>> specifications. We also need to revisit this in the context of connection
>> mgr requirements in both client-based and network-based mobility models,
>> which is a common requirement, or other intefaces such as MIF, for
>> flow template push to the terminal.
> 
> => I think you're distinguishing between modified and unmodified based on
> whether the modification affects IETF protocols or not. That's fine, but for
> those that did not attend the BoF, our conclusions were that you will either
> end up modifying the host (i.e. Adding new SW) and adding new signalling on
> L2 to handle the multihoming cases, or you can stick with MIP.
> My opinion, and at least half the room's was that this is not a good way to

We can discuss what implies host changes and why this is such a big deal
anyway. But I don't think that half the room was in agreement as such. At
least from the count of hands raised for the question about whether we
should work on multihoming and intertech handovers it was about 18-9 (in
favor). 

> go and that it's better to stick with MIP instead of relying on a solution
> that will:
> - work on some L2s and not others,

We have no ability to specify changes to L2 anyway. However if some L2s do
have such capability, why would we not specify how multihoming would work in
such scenarios.

> - Require additional SW and config on the host which is not done anywhere
> today, and

Why is there as much of a concern about additional SW or config? After all
everything (or most of it anyway) that we do in the IETF requires
configurations, protocol changes, changes to SW etc. There is nothing unique
about this. 

> - Require L2 signalling which is out of our scope in IETF

Agree. We cannot do anything about L2s. But we could specify (informatively)
what L2 capabilities would enable these features if that is the conclusion
that we arrive at.

-Raj

> 
> This is why I think we should stick with the charter that Jari sent.
> 
> 
> Hesham
> 
>> 
>> I share the same view with respect to all your other comments. We need
>> to seperate the cases of flow mobility vs basic handoff as allowed in
>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>> handoff cases supported today in 5213.
>> 
>> Sri
>> 
>> 
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 

From: vijay at wichorus.com (Vijay Devarapalli)
Date: Mon, 6 Apr 2009 12:56:17 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

There was quite a bit of confusion on the "host changes" at the BoF. I
hope we are not taking decisions based on this confusion. That would be
very disappointing.

What we have in reality is that PMIPv6 is used for inter-access
technology handovers. RFC 5213 already supports using PMIPv6 for
handovers across two interfaces (it does not matter if the two
interfaces are of the same or different access technologies). However,
RFC 5213 stays quite on the exact changes needed on the host to support
this handover. On some Operating Systems, it is very easy to do this. In
some planned deployments, the two interfaces are hidden from the IP
stack. I think we should document the host changes as an Informational
document. IMHO, that's the responsible thing to do.

On the other multiple interface support scenarios, I think we need to
look at them separately instead of saying they all require hosts changes
and so we shouldn't work on them. For example setting up additional
mobility sessions (the first scenario I presented) does not require any
support from the host. The scenario on more deterministic behavior on
the MAG for setting the Handover Initiate flag can be addressed by using
PFMIPv6 (draft-ietf-mipshop-pfmipv6-03.txt). PFMIPv6 is a standards
track document in the MIPSHOP WG and does not require any involvement
from the host.

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Jari Arkko
> Sent: Friday, April 03, 2009 12:32 AM
> To: netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Subject: [Netext] next steps for netext
> 
> In the meeting we ended up having a big argument about the 
> multihoming 
> and handover parts. I don't know what to do about that yet, 
> but I would 
> still like to suggest that the other parts should move 
> forward. I edited 
> the charter from the web site. Comments appreciated:
> 
> -------
> 
> Network-Based Mobility Extensions (NETEXT)
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts 
> are not affected, as they still send and receive their 
> packets via the MAG.
> 
> 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, and is complementary to the initial LMA discovery 
> work in the 
> NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: xiayangsong at huawei.com (Frank Xia)
Date: Mon, 06 Apr 2009 11:43:46 -0500
Subject: [Netext] next steps for netext
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo

I can send you another email attached
with 3GPP2 ongoing discussing requirement if you like.

As a common researcher of Huawei, I think it is necessary for
Netext to work on this real business requirement.

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
To: "Frank Xia" <xiayangsong at huawei.com>; "Jari Arkko" 
<jari.arkko at piuha.net>; <netext at mail.mobileip.jp>; "Rajeev Koodli" 
<rajeev.koodli at gmail.com>; "Basavaraj Patil" <basavaraj.patil at nokia.com>
Sent: Monday, April 06, 2009 11:17 AM
Subject: RE: [Netext] next steps for netext

Without going into the technical discussion on the merit of any solution, as 
rapporteur of 3GPP TR 23.861, I want just to clarify that this is a wrong 
piece of information.

There is no official (or unofficial) reference to any Netext work on flow 
mobility for PMIPv6 in any 3GPP document.

Best Regards
Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Frank Xia
> Sent: Monday, April 06, 2009 9:11 AM
> To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Subject: Re: [Netext] next steps for netext
>
> Hi Jari
>
> IMHO,  we should prioritize flow mobility which
> is required by both 3GPP and 3GPP2.
>
> BR
> Frank
>
> ----- Original Message -----
> From: "Jari Arkko" <jari.arkko at piuha.net>
> To: <netext at mail.mobileip.jp>; "Rajeev Koodli" <rajeev.koodli at gmail.com>;
> "Basavaraj Patil" <basavaraj.patil at nokia.com>
> Sent: Friday, April 03, 2009 2:31 AM
> Subject: [Netext] next steps for netext
>
>
> > In the meeting we ended up having a big argument about the multihoming 
> > and
> > handover parts. I don't know what to do about that yet, but I would 
> > still
> > like to suggest that the other parts should move forward. I edited the
> > charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts are not affected, as
> > they still send and receive their packets via the MAG.
> >
> > 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,
> > and is complementary to the initial LMA discovery work in the NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009             WG chartered
> > July 2009              Initial WG draft on Bulk Refresh
> > 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 2009       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
> >
> > _______________________________________________
> > 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 

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 6 Apr 2009 18:40:34 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,

Obviously everyone has a different view on what constitutes a host change.
Creating a virtual interface on a host may be supported on some platforms
and not on others. I don't think there is a debate about whether such an
interface can be created to handle handovers. But more importantly, does
such an interface imply that the host is unmodified.
IMO, the term "Unmodified host" is too vague to have any real value in this
discussion. You could have a host which is designed for a network which has
PMIP6 based mobility support and hence implements a virtual interface as a
default to support intertechnology handovers. Is this not an unmodified
host? Does "Unmodified host" always imply a Windows or Mac host as shipped
from the manufacturers in IETF terminology?
I strongly believe that there are different classes of hosts which have
different capabilities and default characteristics. We can spend a lot of
time on trying to define what constitutes an unmodified host in the IETF
context. But this is not going to really help in any way.

If we can instead agree that in order to support multihoming or
inter-technology handovers there may be some implications to the host, we
would make more progress. We are not proposing defining a new protocol per
se that is needed on the MN to enable handovers or multihoming support.

-Raj  

On 4/6/09 11:10 AM, "Sri Gundavelli" <sgundave at cisco.com> wrote:

> Hi Raj:
> 
> Just one comment.
> 
> 
> 
> On Mon, 6 Apr 2009, Basavaraj.Patil at nokia.com wrote:
> 
>> 
>> Hi Jari,
>> 
>> I think the discussion (or argument as you put it) at the BoF was useful. It
>> highlighted the fact that there is a good amount of misunderstanding on what
>> can be done w.r.t multihoming or inter-technology handovers.
>> There are some aspects of multihoming that can be clearly separated, i.e the
>> flow mobility vs the ability of having a host attached via multiple
>> interfaces to the same LMA or dynamically establishing additional moobility
>> sessions. We could narrow down aspects of multihoming which could fit into
>> the scope of the charter.
>> There has been some discussion (online and offline) about the
>> inter-technology handovers. The intent of the work item within Netext is to
>> clarify host behavior to support such handovers.
>> There is obviously quite a strong view of making host changes to support any
>> of the features (multihoming or intertechnology handovers). I believe that
>> there will be a class of hosts which will have the capability to support
>> multihoming and support inter-technology handovers. As long as we do not
>> break the PMIP6 RFC (5213), I think it makes sense to specify these
>> features.
> 
>> For unmodiified hosts, we can agree that they will not be able to
>> perform inter-tech handovers or be support any of the multihoming scenarios.
> 
> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
> host" can leverage that feature. As we discussed earlier, we have a major
> terminology problem, on what is "modified" vs "un modified". If I use
> Windows SDK and implement a virtual interface, no one can claim the host
> is now modified. Its an application, or a configuration such as using
> bridge ctl utuility in Linux. Its not changing any of the IETF
> specifications. We also need to revisit this in the context of connection
> mgr requirements in both client-based and network-based mobility models,
> which is a common requirement, or other intefaces such as MIF, for
> flow template push to the terminal.
> 
> I share the same view with respect to all your other comments. We need
> to seperate the cases of flow mobility vs basic handoff as allowed in
> 5213. In the BOF, we discussed mostly flow mobility and not the basic
> handoff cases supported today in 5213.
> 
> Sri
> 
> 

From: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 03:38:24 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

>> 
>> => I think you're distinguishing between modified and unmodified based on
>> whether the modification affects IETF protocols or not. That's fine, but for
>> those that did not attend the BoF, our conclusions were that you will either
>> end up modifying the host (i.e. Adding new SW) and adding new signalling on
>> L2 to handle the multihoming cases, or you can stick with MIP.
>> My opinion, and at least half the room's was that this is not a good way to
> 
> We can discuss what implies host changes and why this is such a big deal
> anyway. But I don't think that half the room was in agreement as such. At
> least from the count of hands raised for the question about whether we
> should work on multihoming and intertech handovers it was about 18-9 (in
> favor). 

=> I think the question changed a few times :) The final question (which was
specific to whether people wanted to work with this or not) showed a split
room. 
The host changes are not a big deal but they are mentioned here because they
were one of the very few reasons for using NETLMM in the first place: Host
changes (adding new SW to the host) and signalling from the MN. You can see
them in section 4 of RFC 4830.

> 
>> go and that it's better to stick with MIP instead of relying on a solution
>> that will:
>> - work on some L2s and not others,
> 
> We have no ability to specify changes to L2 anyway. However if some L2s do
> have such capability, why would we not specify how multihoming would work in
> such scenarios.

=> Because we already have a solution that works in all L2s, doesn't require
L2 changes that we don't control and doesn't cause confusing host config
solutions. 

> 
>> - Require additional SW and config on the host which is not done anywhere
>> today, and
> 
> Why is there as much of a concern about additional SW or config? After all
> everything (or most of it anyway) that we do in the IETF requires
> configurations, protocol changes, changes to SW etc. There is nothing unique
> about this. 

=> Sure, but see above and see RFC 4830. These were the reasons for using
PMIP in the first place. We can't have it both ways, or can we? :)

> 
>> - Require L2 signalling which is out of our scope in IETF
> 
> Agree. We cannot do anything about L2s. But we could specify (informatively)
> what L2 capabilities would enable these features if that is the conclusion
> that we arrive at.

=> We can, but I don't know why we should do that when a solution already
exists. Especially when the alternative is inferior in terms of its
applicability.

Hesham

> 
> -Raj
> 
>> 
>> This is why I think we should stick with the charter that Jari sent.
>> 
>> 
>> Hesham
>> 
>>> 
>>> I share the same view with respect to all your other comments. We need
>>> to seperate the cases of flow mobility vs basic handoff as allowed in
>>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>>> handoff cases supported today in 5213.
>>> 
>>> Sri
>>> 
>>> 
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>> 
>> 
> 

From: tsirtsis at googlemail.com (George Tsirtsis)
Date: Mon, 6 Apr 2009 17:29:28 +0100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Jari et.al.,

I think this is a reasonable charter given the discussion in the BOF.
During the BOF there was significant concern and opposition regarding
PMIP work on multihoming and inter-technology.

Some comments in this thread are attempting to down-play these
concerns suggesting that they were focused to flow mobility and other
such more advanced features, which is of course not true. The concerns
had to do with any form of further work on inter-technology and
multihoming support for PMIP.

Regards
George

On Fri, Apr 3, 2009 at 8:31 AM, Jari Arkko <jari.arkko at piuha.net> wrote:
> In the meeting we ended up having a big argument about the multihoming and
> handover parts. I don't know what to do about that yet, but I would still
> like to suggest that the other parts should move forward. I edited the
> charter from the web site. Comments appreciated:
>
> -------
>
> Network-Based Mobility Extensions (NETEXT)
>
> Last Modified: 2009-04-03
>
> 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. Hosts are not affected, as they still send
> and receive their packets via the MAG.
>
> 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,
> and is complementary to the initial LMA discovery work in the NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009 ? ? ? ? ? ? WG chartered
> July 2009 ? ? ? ? ? ? ?Initial WG draft on Bulk Refresh
> 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 2009 ? ? ? 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
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: teemu.savolainen at nokia.com (teemu.savolainen at nokia.com)
Date: Mon, 6 Apr 2009 18:21:52 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,  

>-----Original Message-----
>From: netext-bounces at mail.mobileip.jp 
>[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Sri 
>Gundavelli
>Sent: 06 April, 2009 19:11
>"unmodified host" can leverage that feature. As we discussed 
>earlier, we have a major terminology problem, on what is 
>"modified" vs "un modified". If I use Windows SDK and 
>implement a virtual interface, no one can claim the host is 
>now modified. Its an application, or a configuration such as 
>using bridge ctl utuility in Linux. Its not changing any of 

At least in my vocabulary that counts as modified host - things are changed in a host to make it behave differently. 

Best regards,

	Teemu

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Mon, 6 Apr 2009 09:17:20 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Without going into the technical discussion on the merit of any solution, as rapporteur of 3GPP TR 23.861, I want just to clarify that this is a wrong piece of information. 

There is no official (or unofficial) reference to any Netext work on flow mobility for PMIPv6 in any 3GPP document.

Best Regards
Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Frank Xia
> Sent: Monday, April 06, 2009 9:11 AM
> To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Subject: Re: [Netext] next steps for netext
> 
> Hi Jari
> 
> IMHO,  we should prioritize flow mobility which
> is required by both 3GPP and 3GPP2.
> 
> BR
> Frank
> 
> ----- Original Message -----
> From: "Jari Arkko" <jari.arkko at piuha.net>
> To: <netext at mail.mobileip.jp>; "Rajeev Koodli" <rajeev.koodli at gmail.com>;
> "Basavaraj Patil" <basavaraj.patil at nokia.com>
> Sent: Friday, April 03, 2009 2:31 AM
> Subject: [Netext] next steps for netext
> 
> 
> > In the meeting we ended up having a big argument about the multihoming and
> > handover parts. I don't know what to do about that yet, but I would still
> > like to suggest that the other parts should move forward. I edited the
> > charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts are not affected, as
> > they still send and receive their packets via the MAG.
> >
> > 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,
> > and is complementary to the initial LMA discovery work in the NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009             WG chartered
> > July 2009              Initial WG draft on Bulk Refresh
> > 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 2009       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
> >
> > _______________________________________________
> > 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

From: xiayangsong at huawei.com (Frank Xia)
Date: Mon, 06 Apr 2009 11:11:02 -0500
Subject: [Netext] next steps for netext
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari

IMHO,  we should prioritize flow mobility which
is required by both 3GPP and 3GPP2.

BR
Frank

----- Original Message ----- 
From: "Jari Arkko" <jari.arkko at piuha.net>
To: <netext at mail.mobileip.jp>; "Rajeev Koodli" <rajeev.koodli at gmail.com>; 
"Basavaraj Patil" <basavaraj.patil at nokia.com>
Sent: Friday, April 03, 2009 2:31 AM
Subject: [Netext] next steps for netext

> In the meeting we ended up having a big argument about the multihoming and 
> handover parts. I don't know what to do about that yet, but I would still 
> like to suggest that the other parts should move forward. I edited the 
> charter from the web site. Comments appreciated:
>
> -------
>
> Network-Based Mobility Extensions (NETEXT)
>
> Last Modified: 2009-04-03
>
> 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. Hosts are not affected, as 
> they still send and receive their packets via the MAG.
>
> 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, 
> and is complementary to the initial LMA discovery work in the NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 6 Apr 2009 09:10:58 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj:

Just one comment.

On Mon, 6 Apr 2009, Basavaraj.Patil at nokia.com wrote:

>
> Hi Jari,
>
> I think the discussion (or argument as you put it) at the BoF was useful. It
> highlighted the fact that there is a good amount of misunderstanding on what
> can be done w.r.t multihoming or inter-technology handovers.
> There are some aspects of multihoming that can be clearly separated, i.e the
> flow mobility vs the ability of having a host attached via multiple
> interfaces to the same LMA or dynamically establishing additional moobility
> sessions. We could narrow down aspects of multihoming which could fit into
> the scope of the charter.
> There has been some discussion (online and offline) about the
> inter-technology handovers. The intent of the work item within Netext is to
> clarify host behavior to support such handovers.
> There is obviously quite a strong view of making host changes to support any
> of the features (multihoming or intertechnology handovers). I believe that
> there will be a class of hosts which will have the capability to support
> multihoming and support inter-technology handovers. As long as we do not
> break the PMIP6 RFC (5213), I think it makes sense to specify these
> features.

> For unmodiified hosts, we can agree that they will not be able to
> perform inter-tech handovers or be support any of the multihoming scenarios.

No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
host" can leverage that feature. As we discussed earlier, we have a major
terminology problem, on what is "modified" vs "un modified". If I use
Windows SDK and implement a virtual interface, no one can claim the host
is now modified. Its an application, or a configuration such as using
bridge ctl utuility in Linux. Its not changing any of the IETF
specifications. We also need to revisit this in the context of connection
mgr requirements in both client-based and network-based mobility models,
which is a common requirement, or other intefaces such as MIF, for
flow template push to the terminal.

I share the same view with respect to all your other comments. We need
to seperate the cases of flow mobility vs basic handoff as allowed in
5213. In the BOF, we discussed mostly flow mobility and not the basic
handoff cases supported today in 5213.

Sri

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 6 Apr 2009 17:49:06 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

I think the discussion (or argument as you put it) at the BoF was useful. It
highlighted the fact that there is a good amount of misunderstanding on what
can be done w.r.t multihoming or inter-technology handovers.
There are some aspects of multihoming that can be clearly separated, i.e the
flow mobility vs the ability of having a host attached via multiple
interfaces to the same LMA or dynamically establishing additional moobility
sessions. We could narrow down aspects of multihoming which could fit into
the scope of the charter.
There has been some discussion (online and offline) about the
inter-technology handovers. The intent of the work item within Netext is to
clarify host behavior to support such handovers.
There is obviously quite a strong view of making host changes to support any
of the features (multihoming or intertechnology handovers). I believe that
there will be a class of hosts which will have the capability to support
multihoming and support inter-technology handovers. As long as we do not
break the PMIP6 RFC (5213), I think it makes sense to specify these
features. For unmodiified hosts, we can agree that they will not be able to
perform inter-tech handovers or be support any of the multihoming scenarios.
But to categorically avoid specifying these features within Netext (or IETF)
will only result in non-standard implementations.

The proposed charter below is a start. But I do believe that we need to
include the multihoming and inter-tech handover features as well with the
caveat that they should not break backwards compatibility with RFC5213 and
are applicable only for hosts which "MAY" have certain implementations that
are viewed by some as being modified IP hosts. FWIW we did say that Netext
does not mandate "no changes to the host" but will make all efforts to limit
them and try to find solutions that are network centric.

-Raj

On 4/3/09 2:31 AM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:

> In the meeting we ended up having a big argument about the multihoming
> and handover parts. I don't know what to do about that yet, but I would
> still like to suggest that the other parts should move forward. I edited
> the charter from the web site. Comments appreciated:
> 
> -------
> 
> Network-Based Mobility Extensions (NETEXT)
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts
> are not affected, as they still send and receive their packets via the MAG.
> 
> 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, and is complementary to the initial LMA discovery work in the
> NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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: hesham at elevatemobile.com (Hesham Soliman)
Date: Tue, 07 Apr 2009 02:37:29 +1100
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
> host" can leverage that feature. As we discussed earlier, we have a major
> terminology problem, on what is "modified" vs "un modified". If I use
> Windows SDK and implement a virtual interface, no one can claim the host
> is now modified. Its an application, or a configuration such as using
> bridge ctl utuility in Linux. Its not changing any of the IETF
> specifications. We also need to revisit this in the context of connection
> mgr requirements in both client-based and network-based mobility models,
> which is a common requirement, or other intefaces such as MIF, for
> flow template push to the terminal.

=> I think you're distinguishing between modified and unmodified based on
whether the modification affects IETF protocols or not. That's fine, but for
those that did not attend the BoF, our conclusions were that you will either
end up modifying the host (i.e. Adding new SW) and adding new signalling on
L2 to handle the multihoming cases, or you can stick with MIP.
My opinion, and at least half the room's was that this is not a good way to
go and that it's better to stick with MIP instead of relying on a solution
that will:
- work on some L2s and not others,
- Require additional SW and config on the host which is not done anywhere
today, and
- Require L2 signalling which is out of our scope in IETF

This is why I think we should stick with the charter that Jari sent.

Hesham

> 
> I share the same view with respect to all your other comments. We need
> to seperate the cases of flow mobility vs basic handoff as allowed in
> 5213. In the BOF, we discussed mostly flow mobility and not the basic
> handoff cases supported today in 5213.
> 
> Sri
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: amuhanna at nortel.com (Ahmad Muhanna)
Date: Mon, 6 Apr 2009 10:13:42 -0500
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

The proposed charter looks good to me. However, one comment below. I
probably should have made this comment when the topic of Bulk refresh
was discussed. Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Jari Arkko
> Sent: Friday, April 03, 2009 2:32 AM
> To: netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Subject: [Netext] next steps for netext
> 
> In the meeting we ended up having a big argument about the 
> multihoming and handover parts. I don't know what to do about 
> that yet, but I would still like to suggest that the other 
> parts should move forward. I edited the charter from the web 
> site. Comments appreciated:
> 
> -------
> 
> Network-Based Mobility Extensions (NETEXT)
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts are not affected, as they still send and 
> receive their packets via the MAG.
> 
> 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.

[Ahmad]
My concern here is the following:

Such a proposed change, although, it is useful, but could introduce some
unwanted scenarios and race conditions. From the scenarios that come to
mind the following:

1. LMA receives a Bulk refresh and at the same time another PBU from
another MAG due to handover, handover is received before the refresh
PBU.
2. MAG sends a Bulk refresh and then one or more MN released session and
MAG sends PBU with lifetime zero. What happened if de-registration
arrived before bulk registration.
3. Although, we may be trying to avoid a storm of re-registration PBU
BUT on the other hand, we may be creating a huge capacity impact on the
LMA. Let us assumes that there is a 50k sessions that the LMA needs to
refresh their lifetime with MAG1 because of a single refresh message. Is
not that a lot? What happened if more than one MAG sends a bulk refresh
at the same time. IMO, we could run into a situation that is worse than
what we are trying to solve.

May be the original text already covers my concern but just in case, I
would suggest adding some note about these cases, to the end of the
original text as follows:

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 without negatively impact the base
protocol, introducing unwanted race conditions, or capacity spikes on
the LMA.

Regards,
Ahmad

> 
> 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, and is complementary to the 
> initial LMA discovery work in the NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
> 
> _______________________________________________
> 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: Sat, 4 Apr 2009 10:15:26 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

First of all, thanks for proposing the charter.

However, it was a bit of a shock when some items that are mere
extensions to PMIPv6 are not considered.
 One such item is Partial handoff support in PMIP. This item is item
number 9
in the list below.

This is about some optimization for RFC 5213. RFC 5213 already supports
vertical handoff and this is a mere extension to it without any new
protcol extensions in the MN-AR interface. I hope this can be 
added into the charter. Because Netext is about extensions to PMIPv6 and
why should we restrict extensions 
and target only some type of extensions. 

Thanks.

BR,
Mohana

>9. Partial Handoff Support
> 
> We are missing some semantics in 5213 for moving a subset of 
> the prefixes
> between interfaces as part of the inter-tech handoff. This is about 
> defining
> a new handoff value. This allows partial flow management, but 
> moving the
> flows associated to a prefix, as a whole group.
> 
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partia
> l-handoff-00

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Sri Gundavelli
> Sent: Friday, April 03, 2009 10:53 PM
> To: Jari Arkko
> Cc: netext at mail.mobileip.jp; Rajeev Koodli
> Subject: Re: [Netext] next steps for netext
> 
> Hi Jari,
> 
> I've a concern with the planned charter. The list is too 
> random and cherry picked and I dont believe proper input from 
> all the folks went into this. There are many other items that 
> are required for a reasonable deployment of Proxy Mobile 
> IPv6. Many items were proposed over the last 2 years, some of 
> them that were left out in the base spec, some that we 
> realized as gaps when compared to other SDO protocols and 
> some as optimizations that we realized while implementing 
> PMIP6, these items should be in the initial scope.
> 
> I understand the charter needs to be limited in scope, but 
> just 3 or 4 random items, I'm not sure if this helps in short 
> term PMIP6 requirements.
> I've no issue with the currently listed items, but there are 
> other items that should get equal or higher priority.
> 
> For example, item #6, is absolutely required, from the 
> perspective of having a complete specification of 5213. There 
> we allowed a mobile node to perform handoff betweek two 
> interfaces. We defined all the hooks on the network side, but 
> we did not provide how a terminal vendor can support that. A 
> simple informational draft on how some one move prefixes 
> between interfaces will greatly help. Some guidance on how to 
> create a virtual interface and also some related notes for 
> each platform (Linux, BSD, Android ..etc). This should not 
> fall in the controversial discussion scope of same address on 
> two interfaces etc, thats a different problem, or about the 
> issue of enhancing mobile node's capabilities. This is just 
> informational work, required to leverage what 5213 already supports.
> 
> Item #2, is required. The multimob BOF raised some issues, we 
> need to show how multicast services can be enabled in PMIP 
> network. May be this wont require extensions, a simple draft 
> covering those aspects will help.
> 
> I think, the charter should be bit more relaxed and more 
> extensive. As I see it, atleast the folks are interested in 
> doing the work. We should add atleast 4 or 5 more items to 
> this list. I've identified some of the potential work items below.
> 
> Regards
> Sri
> 
> 
> 
> --------------------------------------------------------------------
> 
> 1. Dynamic LMA Assignment
> 
> In blade architecture systems or in a load balancer 
> configuration, the PDNGW should have the ability to 
> dynamically assign a LMA on the fly, along the lines of 
> Mobile IPv4 Dynamic Home Agent Address Assignment support [RFC-4433].
> Currently, GTP provides such semantics and this is a 
> important requirement for deployment. Here the goal is to
> 
> a.) Expose a single IP address to the SGW
> b.) The exposed IP address should not be in path once the 
> assignment is done.
> 
> 
> 
> [LMA1]---
>    |      |
> [LMA2]--[LMA]==========[MAG]
>    |      |
> [LMA3]---
> 
> 
> Along the lines of:
> 
> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> 
> 
> 
> 2. Multicast Support in Proxy Mobile IPv6
> 
> We need an informational specification on how multicast 
> support can be enabled in Proxy Mobile IPv6 environment. 
> Behcet has done extensive analysis on this. This is required 
> and critical for enabling any multicast services.
> However,
> Behcet may disagree with the scope of the work.
> 
> 
> 
> 
> 3. Bulk Registration Support
> 
> This is a simple extension which helps in signaling 
> optimization, along 
> the
> lines of:
> 
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> 
> 
> 
> 
> 4. Partial Failover Support
> 
> We need a mechanism to notify the peer on revoke a partial set of 
> bindings.
> 
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-
> management-00.
> txt
> 
> 
> 
> 
> 
> 5. Group Identifier Support for Proxy Mobile IPv6
> 
> This provides a simple and a generic semantic for assigning a group
> identifier
> to a mobile node's binding. GTP has very similar semantics, 
> Connexion Set
> Id.
> Both #3 and #4 can leverage this. Additionally, in load 
> balancer systems
> where
> the load balancer is in path for all signaling messages, it 
> can use this 
> as
> a
> tag for redirecting the message.
> 
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-
> option-00
> 
> 
> 
> 
> 6. Virtual-Interface Support on IP host for supporting Inter-tech 
> handoffs:
> 
> 
> RFC-5213 supports handoff between two interfaces. The ability to move
> prefixes between interfaces. In other words address 
> continuity is assured
> with any IPv6 host on the planet and with absolutely no changes. This 
> meets
> even Dave's comment, that "no changes to any IETF RFC's.". 
> Now, what is
> not assured is the aspect of session continuity. Which 
> requires a virtual
> interface implementation on the host, by binding the 
> address/prefix to a
> virtual interface and by not exposing the physical interface 
> or by hiding
> the handoff events from the layer-3 stack.
> 
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
> 
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-
> support-00
> 
> 
> 
> 7. Route Optimization for Proxy Mobile IPv6
> 
> There were atleast 4 drafts in this area on Route Optimization. Marco
> Liebsch
> analyzed this exensively:
> 
> 
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-
> forwarding-00.
> txt
> 
> 
> 
> 
> 8. Prefix Management in Proxy Mobile IPv6 support
> 
> Proxy Mobile IPv6 allows the assignment of multiple home 
> network prefixes
> to a given mobile node's interface. It might be useful to 
> specify how the
> LMA manages this aspects. It can potentially use DHCP PD, 
> Local Pools or
> AAA to manage this aspect. Behcet has one draft on this.
> 
> 
> 
> 9. Partial Handoff Support
> 
> We are missing some semantics in 5213 for moving a subset of 
> the prefixes
> between interfaces as part of the inter-tech handoff. This is about 
> defining
> a new handoff value. This allows partial flow management, but 
> moving the
> flows associated to a prefix, as a whole group.
> 
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partia
> l-handoff-00
> 
> 
> 
> 
> 10. CMIPv4/PMIP Interworking
> 
> This is probably required to specify how an IPv4-only can move between
> CMIP and PMIP environments.
> 
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet
> -drafts/draft-
> meghana-netlmm-pmipv6-mipv4-00.txt
> 
> 
> 
> 
> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> 
> 
> 
> 
> 
> 
> 
> On Fri, 3 Apr 2009, Jari Arkko wrote:
> 
> > In the meeting we ended up having a big argument about the 
> multihoming and 
> > handover parts. I don't know what to do about that yet, but 
> I would still 
> > like to suggest that the other parts should move forward. I 
> edited the 
> > charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts are not affected, 
> as they still send 
> > and receive their packets via the MAG.
> >
> > 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, and 
> > is complementary to the initial LMA discovery work in the NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009             WG chartered
> > July 2009              Initial WG draft on Bulk Refresh
> > 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 2009       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
> >
> > _______________________________________________
> > 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
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Sat, 4 Apr 2009 09:41:09 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

RFC 5213 already supports intertechnology handoffs.
As you mentioned, perhaps we could document some host implementations that needs to be done
and look into further optimizations and extensions we have to perform to insert
Multihoming cabilities and vertical handoff optimizations for PMIPv6. 

When operators deploy PMIPv6 they would probably need such extensions and why should we
limit this capability for PMIPv6? We need to start some work in IETF here as well.

BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Rajeev Koodli
> Sent: Friday, April 03, 2009 10:50 PM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
> Hi Jari,
> 
> thanks for the start on the charter.
> 
> Regarding multiple interface support and inter-access 
> handovers: the primary issue is the ability to use the same 
> address across interfaces. This can be considered a 
> functionality that needs to be turned on, e.g., through the 
> use of virtual interfaces. This is not a "host change" per 
> se, at least we can be clear about it in the charter. As 
> Ryuji pointed out, IPv6 is (still?) disabled by default on 
> Windows OS. Does enabling it constitute a "host change"?
> 
> I think we need to consider problems which need to be solved 
> (in addition to the good debate which may sometime turn here 
> and there :-) ).
> 
> Regards,
> 
> -Rajeev
> 
> 
> On Fri, Apr 3, 2009 at 12:31 AM, Jari Arkko 
> <jari.arkko at piuha.net> wrote:
> > In the meeting we ended up having a big argument about the 
> multihoming 
> > and handover parts. I don't know what to do about that yet, but I 
> > would still like to suggest that the other parts should 
> move forward. 
> > I edited the charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > 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. Hosts 
> > are not affected, as they still send and receive their 
> packets via the MAG.
> >
> > 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, and is complementary to the initial LMA 
> discovery work in the NETLMM WG.
> >
> > 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.
> >
> > Milestones
> >
> > May 2009 ? ? ? ? ? ? WG chartered
> > July 2009 ? ? ? ? ? ? ?Initial WG draft on Bulk Refresh 
> 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 2009 ? ? ? 
> 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
> >
> >
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 3 Apr 2009 09:36:09 -0700 (PDT)
Subject: [Netext] Charter Scope and Work Items
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A3BF11@ftrdmel1>
References: <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A3BF11@ftrdmel1>
Message-ID: <[email-masked]>

Hi Pierrick,

On Tue, 31 Mar 2009, pierrick.seite at orange-ftgroup.com wrote:

> Hi Sri,
>
> I agree with items you are proposing. However the virtual interface may not be the only solution to support inter-technology handover. I don't think we should restrict the solution space at this stage.
>

Sure, there may be other ways to solve this. Virtual interface is one such 
standard approach.

Sri

> Regards,
> Pierrick
>
>> -----Message d'origine-----
>> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] De la part de Sri Gundavelli
>> Envoy??: vendredi 27 mars 2009 06:43
>> ??: netext at mail.mobileip.jp
>> Objet?: [Netext] Charter Scope and Work Items
>>
>> IMHO, there are number of extensions to Proxy Mobile IPv6 that we need for
>> successful deployment of the protocol in any system architecture. To most
>> part these are minor extensions that we need them for addressing a
>> deployment
>> problem, alignment with other protocols such as GTP, add a minor missing
>> feature useful in optimizations, or some thing that helps in
>> implementations.
>>
>> I've identified some work items, that we discussed in the past. This is
>> just
>> my opinion. Welcome to dispute. Also, Where ever we do this work, netext,
>> netlmm,
>> mext or mipshop, is not my interest, but we need these extensions. Thats
>> the
>> only part I care. If this was discussed in the past, fine, but this is my
>> list as I see it, bear with me.
>>
>> All the items listed here do not require host stack changes, except the
>> following immediate list which may in some cases:
>>
>> - Multi-homing Support, when sharing the same address on two interfaces
>> - Handoff triggers from the mobile node
>> - Flow Management, when not moved as a group associated to a prefix
>> - Prefix coloring via RA extensions
>>
>> I really hope the charter will consider most of the work items listed
>> below.
>>
>>
>>
>> 1. Dynamic LMA Assignment
>>
>> In blade architecture systems or in a load balancer configuration, the
>> PDNGW
>> should have the ability to dynamically assign a LMA on the fly, along the
>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
>> [RFC-4433].
>> Currently, GTP provides such semantics and this is a important requirement
>> for deployment. Here the goal is to
>>
>> a.) Expose a single IP address to the SGW
>> b.) The exposed IP address should not be in path once the assignment is
>> done.
>>
>>
>>
>> [LMA1]---
>>   |      |
>> [LMA2]--[LMA]==========[MAG]
>>   |      |
>> [LMA3]---
>>
>>
>> Along the lines of:
>>
>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>>
>>
>>
>> 2. Multicast Support in Proxy Mobile IPv6
>>
>> We need an informational specification on how multicast support can be
>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
>> analysis
>> on
>> this. This is required and critical for enabling any multicast services.
>> However,
>> Behcet may disagree with the scope of the work.
>>
>>
>>
>>
>> 3. Bulk Registration Support
>>
>> This is a simple extension which helps in signaling optimization, along
>> the
>> lines of:
>>
>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>>
>>
>>
>>
>> 4. Partial Failover Support
>>
>> We need a mechanism to notify the peer on revoke a partial set of bindings.
>>
>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-
>> 00.
>> txt
>>
>>
>>
>>
>>
>> 5. Group Identifier Support for Proxy Mobile IPv6
>>
>> This provides a simple and a generic semantic for assigning a group
>> identifier
>> to a mobile node's binding. GTP has very similar semantics, Connexion Set
>> Id.
>> Both #3 and #4 can leverage this. Additionally, in load balancer systems
>> where
>> the load balancer is in path for all signaling messages, it can use this
>> as
>> a
>> tag for redirecting the message.
>>
>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>>
>>
>>
>> 6. Virtual-Interface Support on IP host for supporting Inter-tech handoffs:
>>
>>
>> RFC-5213 supports handoff between two interfaces. The ability to move
>> prefixes between interfaces. In other words address continuity is assured
>> with any IPv6 host on the planet and with absolutely no changes. This
>> meets
>> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>> not assured is the aspect of session continuity. Which requires a virtual
>> interface implementation on the host, by binding the address/prefix to a
>> virtual interface and by not exposing the physical interface or by hiding
>> the handoff events from the layer-3 stack.
>>
>> In essence, we need an informational specification which provides some
>> general guidance to how to leverage the feature support provided in
>> RFC-5213,
>> along the lines of:
>>
>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>>
>>
>>
>> 7. Route Optimization for Proxy Mobile IPv6
>>
>> There were atleast 4 drafts in this area on Route Optimization. Marco
>> Liebsch
>> analyzed this exensively:
>>
>>
>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-
>> 00.
>> txt
>>
>>
>>
>>
>>
>> 8. Prefix Management in Proxy Mobile IPv6 support
>>
>> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
>> to a given mobile node's interface. It might be useful to specify how the
>> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
>> AAA to manage this aspect. Behcet has one draft on this.
>>
>>
>>
>> 9. Partial Handoff Support
>>
>> We are missing some semantics in 5213 for moving a subset of the prefixes
>> between interfaces as part of the inter-tech handoff. This is about
>> defining
>> a new handoff value. This allows partial flow management, but moving the
>> flows associated to a prefix, as a whole group.
>>
>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>>
>>
>>
>>
>> 10. CMIPv4/PMIP Interworking
>>
>> This is probably required to specify how an IPv4-only can move between
>> CMIP and PMIP environments.
>>
>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-
>> drafts/draft-
>> meghana-netlmm-pmipv6-mipv4-00.txt
>>
>>
>>
>>
>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>>
>>
>>
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 3 Apr 2009 09:31:31 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

On Fri, 3 Apr 2009, Koodli, Rajeev wrote:

>
> Hi Sri,
>
> FYI: these items are not "cherry-picked" nor or they random!
>
> Folks have spent time on this over months (since Dublin meeting).
>
> Of course you are free to propose other items, but please go back and read the archives and past meeting materials before expressing comments on topics which you may not be fully aware of :-)
>

Ok. Fair enough. I may have missed the discussions. Or, since it was a BOF
ML, not many folks may have had the chance to provide input. In any case,
no offense here. But, since the WG is now formally getting approved, it
might be better to get feedback from the list on the items that should be
in the list, before the charter is formally fixed.

Sri

> Thanks,
>
> -Rajeev
>
>
> ________________________________
>
> From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
> Sent: Fri 4/3/2009 7:53 AM
> To: Jari Arkko
> Cc: netext at mail.mobileip.jp; Rajeev Koodli
> Subject: Re: [Netext] next steps for netext
>
>
>
> Hi Jari,
>
> I've a concern with the planned charter. The list is too random and
> cherry picked and I dont believe proper input from all the folks went into
> this. There are many other items that are required for a reasonable
> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
> years, some of them that were left out in the base spec, some that we
> realized as gaps when compared to other SDO protocols and some as
> optimizations that we realized while implementing PMIP6, these items
> should be in the initial scope.
>
> I understand the charter needs to be limited in scope, but just 3 or 4
> random items, I'm not sure if this helps in short term PMIP6 requirements.
> I've no issue with the currently listed items, but there are other items
> that should get equal or higher priority.
>
> For example, item #6, is absolutely required, from the perspective of
> having a complete specification of 5213. There we allowed a mobile node to
> perform handoff betweek two interfaces. We defined all the hooks on the
> network side, but we did not provide how a terminal vendor can support
> that. A simple informational draft on how some one move prefixes between
> interfaces will greatly help. Some guidance on how to create a virtual
> interface and also some related notes for each platform (Linux, BSD,
> Android ..etc). This should not fall in the controversial discussion scope
> of same address on two interfaces etc, thats a different problem, or about
> the issue of enhancing mobile node's capabilities. This is just
> informational work, required to leverage what 5213 already supports.
>
> Item #2, is required. The multimob BOF raised some issues, we need to
> show how multicast services can be enabled in PMIP network. May be this
> wont require extensions, a simple draft covering those aspects will help.
>
> I think, the charter should be bit more relaxed and more extensive. As I
> see it, atleast the folks are interested in doing the work. We should add
> atleast 4 or 5 more items to this list. I've identified some of the
> potential work items below.
>
> Regards
> Sri
>
>
>
> --------------------------------------------------------------------
>
> 1. Dynamic LMA Assignment
>
> In blade architecture systems or in a load balancer configuration, the
> PDNGW
> should have the ability to dynamically assign a LMA on the fly, along the
> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> [RFC-4433].
> Currently, GTP provides such semantics and this is a important requirement
> for deployment. Here the goal is to
>
> a.) Expose a single IP address to the SGW
> b.) The exposed IP address should not be in path once the assignment is
> done.
>
>
>
> [LMA1]---
>   |      |
> [LMA2]--[LMA]==========[MAG]
>   |      |
> [LMA3]---
>
>
> Along the lines of:
>
> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>
>
>
> 2. Multicast Support in Proxy Mobile IPv6
>
> We need an informational specification on how multicast support can be
> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> analysis
> on
> this. This is required and critical for enabling any multicast services.
> However,
> Behcet may disagree with the scope of the work.
>
>
>
>
> 3. Bulk Registration Support
>
> This is a simple extension which helps in signaling optimization, along
> the
> lines of:
>
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>
>
>
>
> 4. Partial Failover Support
>
> We need a mechanism to notify the peer on revoke a partial set of
> bindings.
>
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
> txt
>
>
>
>
>
> 5. Group Identifier Support for Proxy Mobile IPv6
>
> This provides a simple and a generic semantic for assigning a group
> identifier
> to a mobile node's binding. GTP has very similar semantics, Connexion Set
> Id.
> Both #3 and #4 can leverage this. Additionally, in load balancer systems
> where
> the load balancer is in path for all signaling messages, it can use this
> as
> a
> tag for redirecting the message.
>
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
>
>
>
> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> handoffs:
>
>
> RFC-5213 supports handoff between two interfaces. The ability to move
> prefixes between interfaces. In other words address continuity is assured
> with any IPv6 host on the planet and with absolutely no changes. This
> meets
> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
> not assured is the aspect of session continuity. Which requires a virtual
> interface implementation on the host, by binding the address/prefix to a
> virtual interface and by not exposing the physical interface or by hiding
> the handoff events from the layer-3 stack.
>
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
>
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
>
>
> 7. Route Optimization for Proxy Mobile IPv6
>
> There were atleast 4 drafts in this area on Route Optimization. Marco
> Liebsch
> analyzed this exensively:
>
>
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
> txt
>
>
>
>
> 8. Prefix Management in Proxy Mobile IPv6 support
>
> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
> to a given mobile node's interface. It might be useful to specify how the
> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
> AAA to manage this aspect. Behcet has one draft on this.
>
>
>
> 9. Partial Handoff Support
>
> We are missing some semantics in 5213 for moving a subset of the prefixes
> between interfaces as part of the inter-tech handoff. This is about
> defining
> a new handoff value. This allows partial flow management, but moving the
> flows associated to a prefix, as a whole group.
>
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>
>
>
>
> 10. CMIPv4/PMIP Interworking
>
> This is probably required to specify how an IPv4-only can move between
> CMIP and PMIP environments.
>
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> meghana-netlmm-pmipv6-mipv4-00.txt
>
>
>
>
> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
>
>
>
>
>
>
> On Fri, 3 Apr 2009, Jari Arkko wrote:
>
>> In the meeting we ended up having a big argument about the multihoming and
>> handover parts. I don't know what to do about that yet, but I would still
>> like to suggest that the other parts should move forward. I edited the
>> charter from the web site. Comments appreciated:
>>
>> -------
>>
>> Network-Based Mobility Extensions (NETEXT)
>>
>> Last Modified: 2009-04-03
>>
>> 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. Hosts are not affected, as they still send
>> and receive their packets via the MAG.
>>
>> 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, and
>> is complementary to the initial LMA discovery work in the NETLMM WG.
>>
>> 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.
>>
>> Milestones
>>
>> May 2009             WG chartered
>> July 2009              Initial WG draft on Bulk Refresh
>> 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 2009       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
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Fri, 3 Apr 2009 08:14:51 -0700 (PDT)
Subject: [Netext] [netlmm] FW: next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,
? I agree with and support this charter proposal.
As some people indicate there are many other things out there but they have not been discussed in the BoF and we don't know the consensus issue.
? Regards,

Behcet

________________________________
From: Jari Arkko <jari.arkko at piuha.net>
To: "netlmm at ietf.org" <netlmm at ietf.org>
Sent: Friday, April 3, 2009 2:57:23 AM
Subject: [netlmm] FW: next steps for netext

FYI -- comments appreciated:

Jari Arkko wrote:
> In the meeting we ended up having a big argument about the multihoming and handover parts. I don't know what to do about that yet, but I would still like to suggest that the other parts should move forward. I edited the charter from the web site. Comments appreciated:
> 
> -------
> 
> Network-Based Mobility Extensions (NETEXT)
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts are not affected, as they still send and receive their packets via the MAG.
> 
> 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, and is complementary to the initial LMA discovery work in the NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009? ? ? ? ? ? WG chartered
> July 2009? ? ? ? ? ? ? Initial WG draft on Bulk Refresh
> 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 2009? ? ? 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
> 
> 

_______________________________________________
netlmm mailing list
netlmm at ietf.org
https://www.ietf.org/mailman/listinfo/netlmm

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090403/e291ec2e/attachment-0001.html>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Fri, 3 Apr 2009 11:06:38 -0400
Subject: [Netext] next steps for netext
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri,
 
FYI: these items are not "cherry-picked" nor or they random!
 
Folks have spent time on this over months (since Dublin meeting).
 
Of course you are free to propose other items, but please go back and read the archives and past meeting materials before expressing comments on topics which you may not be fully aware of :-)
 
Thanks,
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
Sent: Fri 4/3/2009 7:53 AM
To: Jari Arkko
Cc: netext at mail.mobileip.jp; Rajeev Koodli
Subject: Re: [Netext] next steps for netext

Hi Jari,

I've a concern with the planned charter. The list is too random and
cherry picked and I dont believe proper input from all the folks went into
this. There are many other items that are required for a reasonable
deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
years, some of them that were left out in the base spec, some that we
realized as gaps when compared to other SDO protocols and some as
optimizations that we realized while implementing PMIP6, these items
should be in the initial scope.

I understand the charter needs to be limited in scope, but just 3 or 4
random items, I'm not sure if this helps in short term PMIP6 requirements.
I've no issue with the currently listed items, but there are other items
that should get equal or higher priority.

For example, item #6, is absolutely required, from the perspective of
having a complete specification of 5213. There we allowed a mobile node to
perform handoff betweek two interfaces. We defined all the hooks on the
network side, but we did not provide how a terminal vendor can support
that. A simple informational draft on how some one move prefixes between
interfaces will greatly help. Some guidance on how to create a virtual
interface and also some related notes for each platform (Linux, BSD,
Android ..etc). This should not fall in the controversial discussion scope
of same address on two interfaces etc, thats a different problem, or about
the issue of enhancing mobile node's capabilities. This is just
informational work, required to leverage what 5213 already supports.

Item #2, is required. The multimob BOF raised some issues, we need to
show how multicast services can be enabled in PMIP network. May be this
wont require extensions, a simple draft covering those aspects will help.

I think, the charter should be bit more relaxed and more extensive. As I
see it, atleast the folks are interested in doing the work. We should add
atleast 4 or 5 more items to this list. I've identified some of the
potential work items below.

Regards
Sri

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

1. Dynamic LMA Assignment

In blade architecture systems or in a load balancer configuration, the
PDNGW
should have the ability to dynamically assign a LMA on the fly, along the
lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
[RFC-4433].
Currently, GTP provides such semantics and this is a important requirement
for deployment. Here the goal is to

a.) Expose a single IP address to the SGW
b.) The exposed IP address should not be in path once the assignment is
done.

[LMA1]---
   |      |
[LMA2]--[LMA]==========[MAG]
   |      |
[LMA3]---

Along the lines of:

http://tools.ietf.org/html/draft-korhonen-netext-redirect-01

2. Multicast Support in Proxy Mobile IPv6

We need an informational specification on how multicast support can be
enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
analysis
on
this. This is required and critical for enabling any multicast services.
However,
Behcet may disagree with the scope of the work.

3. Bulk Registration Support

This is a simple extension which helps in signaling optimization, along
the
lines of:

http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02

4. Partial Failover Support

We need a mechanism to notify the peer on revoke a partial set of
bindings.

http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
txt

5. Group Identifier Support for Proxy Mobile IPv6

This provides a simple and a generic semantic for assigning a group
identifier
to a mobile node's binding. GTP has very similar semantics, Connexion Set
Id.
Both #3 and #4 can leverage this. Additionally, in load balancer systems
where
the load balancer is in path for all signaling messages, it can use this
as
a
tag for redirecting the message.

http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

6. Virtual-Interface Support on IP host for supporting Inter-tech
handoffs:

RFC-5213 supports handoff between two interfaces. The ability to move
prefixes between interfaces. In other words address continuity is assured
with any IPv6 host on the planet and with absolutely no changes. This
meets
even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
not assured is the aspect of session continuity. Which requires a virtual
interface implementation on the host, by binding the address/prefix to a
virtual interface and by not exposing the physical interface or by hiding
the handoff events from the layer-3 stack.

In essence, we need an informational specification which provides some
general guidance to how to leverage the feature support provided in
RFC-5213,
along the lines of:

http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00

7. Route Optimization for Proxy Mobile IPv6

There were atleast 4 drafts in this area on Route Optimization. Marco
Liebsch
analyzed this exensively:

http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
txt

8. Prefix Management in Proxy Mobile IPv6 support

Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
to a given mobile node's interface. It might be useful to specify how the
LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
AAA to manage this aspect. Behcet has one draft on this.

9. Partial Handoff Support

We are missing some semantics in 5213 for moving a subset of the prefixes
between interfaces as part of the inter-tech handoff. This is about
defining
a new handoff value. This allows partial flow management, but moving the
flows associated to a prefix, as a whole group.

http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00

10. CMIPv4/PMIP Interworking

This is probably required to specify how an IPv4-only can move between
CMIP and PMIP environments.

http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
meghana-netlmm-pmipv6-mipv4-00.txt

11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6

On Fri, 3 Apr 2009, Jari Arkko wrote:

> In the meeting we ended up having a big argument about the multihoming and
> handover parts. I don't know what to do about that yet, but I would still
> like to suggest that the other parts should move forward. I edited the
> charter from the web site. Comments appreciated:
>
> -------
>
> Network-Based Mobility Extensions (NETEXT)
>
> Last Modified: 2009-04-03
>
> 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. Hosts are not affected, as they still send
> and receive their packets via the MAG.
>
> 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, and
> is complementary to the initial LMA discovery work in the NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
>
> _______________________________________________
> 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

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 3 Apr 2009 08:04:35 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Regarding multiple interface support and inter-access handovers: the
> primary issue is the ability to use the same address across
> interfaces.

I'll differentiate the two cases that the above statement covers, to
make sure both dont get the same tag.

- Inter-interface handoff of support, leveraging what is
   supported in 5213. Where the mobile node has the ability
   to move prefixes between interfaces, for address and
   session continuity. This is currently supported.

- The ability for the mobile node to attach to two networks,
   configure the same prefix and address on two interfaces
   simultaneously. In affect, the interfaces operating in
   bridged mode and a virtual interface managing the ND aspects.
   This is beyond 5213, and is in scope for the proposed
   multihoming work.

Solution may be very well use a virtual interface for solving both.
May be this can be two different work items, or one.

Sri

On Fri, 3 Apr 2009, Rajeev Koodli wrote:

> Hi Jari,
>
> thanks for the start on the charter.
>
> Regarding multiple interface support and inter-access handovers: the
> primary issue is the ability to use the same address across
> interfaces. This can be considered a functionality that needs to be
> turned on, e.g., through the use of virtual interfaces. This is not a
> "host change" per se, at least we can be clear about it in the
> charter. As Ryuji pointed out, IPv6 is (still?) disabled by default on
> Windows OS. Does enabling it constitute a "host change"?
>
> I think we need to consider problems which need to be solved (in
> addition to the good debate which may sometime turn here and there :-)
> ).
>
> Regards,
>
> -Rajeev
>
>
> On Fri, Apr 3, 2009 at 12:31 AM, Jari Arkko <jari.arkko at piuha.net> wrote:
>> In the meeting we ended up having a big argument about the multihoming and
>> handover parts. I don't know what to do about that yet, but I would still
>> like to suggest that the other parts should move forward. I edited the
>> charter from the web site. Comments appreciated:
>>
>> -------
>>
>> Network-Based Mobility Extensions (NETEXT)
>>
>> Last Modified: 2009-04-03
>>
>> 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. Hosts are not affected, as they still send
>> and receive their packets via the MAG.
>>
>> 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,
>> and is complementary to the initial LMA discovery work in the NETLMM WG.
>>
>> 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.
>>
>> Milestones
>>
>> May 2009 ? ? ? ? ? ? WG chartered
>> July 2009 ? ? ? ? ? ? ?Initial WG draft on Bulk Refresh
>> 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 2009 ? ? ? 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
>>
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Fri, 3 Apr 2009 07:53:28 -0700 (PDT)
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

I've a concern with the planned charter. The list is too random and
cherry picked and I dont believe proper input from all the folks went into
this. There are many other items that are required for a reasonable
deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
years, some of them that were left out in the base spec, some that we
realized as gaps when compared to other SDO protocols and some as
optimizations that we realized while implementing PMIP6, these items
should be in the initial scope.

I understand the charter needs to be limited in scope, but just 3 or 4
random items, I'm not sure if this helps in short term PMIP6 requirements.
I've no issue with the currently listed items, but there are other items
that should get equal or higher priority.

For example, item #6, is absolutely required, from the perspective of
having a complete specification of 5213. There we allowed a mobile node to
perform handoff betweek two interfaces. We defined all the hooks on the
network side, but we did not provide how a terminal vendor can support
that. A simple informational draft on how some one move prefixes between
interfaces will greatly help. Some guidance on how to create a virtual
interface and also some related notes for each platform (Linux, BSD,
Android ..etc). This should not fall in the controversial discussion scope
of same address on two interfaces etc, thats a different problem, or about
the issue of enhancing mobile node's capabilities. This is just
informational work, required to leverage what 5213 already supports.

Item #2, is required. The multimob BOF raised some issues, we need to
show how multicast services can be enabled in PMIP network. May be this
wont require extensions, a simple draft covering those aspects will help.

I think, the charter should be bit more relaxed and more extensive. As I
see it, atleast the folks are interested in doing the work. We should add
atleast 4 or 5 more items to this list. I've identified some of the
potential work items below.

Regards
Sri

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

1. Dynamic LMA Assignment

In blade architecture systems or in a load balancer configuration, the 
PDNGW
should have the ability to dynamically assign a LMA on the fly, along the
lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
[RFC-4433].
Currently, GTP provides such semantics and this is a important requirement
for deployment. Here the goal is to

a.) Expose a single IP address to the SGW
b.) The exposed IP address should not be in path once the assignment is
done.

[LMA1]---
   |      |
[LMA2]--[LMA]==========[MAG]
   |      |
[LMA3]---

Along the lines of:

http://tools.ietf.org/html/draft-korhonen-netext-redirect-01

2. Multicast Support in Proxy Mobile IPv6

We need an informational specification on how multicast support can be
enabled in Proxy Mobile IPv6 environment. Behcet has done extensive 
analysis
on
this. This is required and critical for enabling any multicast services.
However,
Behcet may disagree with the scope of the work.

3. Bulk Registration Support

This is a simple extension which helps in signaling optimization, along 
the
lines of:

http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02

4. Partial Failover Support

We need a mechanism to notify the peer on revoke a partial set of 
bindings.

http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
txt

5. Group Identifier Support for Proxy Mobile IPv6

This provides a simple and a generic semantic for assigning a group
identifier
to a mobile node's binding. GTP has very similar semantics, Connexion Set
Id.
Both #3 and #4 can leverage this. Additionally, in load balancer systems
where
the load balancer is in path for all signaling messages, it can use this 
as
a
tag for redirecting the message.

http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

6. Virtual-Interface Support on IP host for supporting Inter-tech 
handoffs:

RFC-5213 supports handoff between two interfaces. The ability to move
prefixes between interfaces. In other words address continuity is assured
with any IPv6 host on the planet and with absolutely no changes. This 
meets
even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
not assured is the aspect of session continuity. Which requires a virtual
interface implementation on the host, by binding the address/prefix to a
virtual interface and by not exposing the physical interface or by hiding
the handoff events from the layer-3 stack.

In essence, we need an informational specification which provides some
general guidance to how to leverage the feature support provided in
RFC-5213,
along the lines of:

http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00

7. Route Optimization for Proxy Mobile IPv6

There were atleast 4 drafts in this area on Route Optimization. Marco
Liebsch
analyzed this exensively:

http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
txt

8. Prefix Management in Proxy Mobile IPv6 support

Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
to a given mobile node's interface. It might be useful to specify how the
LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
AAA to manage this aspect. Behcet has one draft on this.

9. Partial Handoff Support

We are missing some semantics in 5213 for moving a subset of the prefixes
between interfaces as part of the inter-tech handoff. This is about 
defining
a new handoff value. This allows partial flow management, but moving the
flows associated to a prefix, as a whole group.

http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00

10. CMIPv4/PMIP Interworking

This is probably required to specify how an IPv4-only can move between
CMIP and PMIP environments.

http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
meghana-netlmm-pmipv6-mipv4-00.txt

11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6

On Fri, 3 Apr 2009, Jari Arkko wrote:

> In the meeting we ended up having a big argument about the multihoming and 
> handover parts. I don't know what to do about that yet, but I would still 
> like to suggest that the other parts should move forward. I edited the 
> charter from the web site. Comments appreciated:
>
> -------
>
> Network-Based Mobility Extensions (NETEXT)
>
> Last Modified: 2009-04-03
>
> 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. Hosts are not affected, as they still send 
> and receive their packets via the MAG.
>
> 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, and 
> is complementary to the initial LMA discovery work in the NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: rajeev.koodli at gmail.com (Rajeev Koodli)
Date: Fri, 3 Apr 2009 07:49:49 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

thanks for the start on the charter.

Regarding multiple interface support and inter-access handovers: the
primary issue is the ability to use the same address across
interfaces. This can be considered a functionality that needs to be
turned on, e.g., through the use of virtual interfaces. This is not a
"host change" per se, at least we can be clear about it in the
charter. As Ryuji pointed out, IPv6 is (still?) disabled by default on
Windows OS. Does enabling it constitute a "host change"?

I think we need to consider problems which need to be solved (in
addition to the good debate which may sometime turn here and there :-)
).

Regards,

-Rajeev

On Fri, Apr 3, 2009 at 12:31 AM, Jari Arkko <jari.arkko at piuha.net> wrote:
> In the meeting we ended up having a big argument about the multihoming and
> handover parts. I don't know what to do about that yet, but I would still
> like to suggest that the other parts should move forward. I edited the
> charter from the web site. Comments appreciated:
>
> -------
>
> Network-Based Mobility Extensions (NETEXT)
>
> Last Modified: 2009-04-03
>
> 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. Hosts are not affected, as they still send
> and receive their packets via the MAG.
>
> 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,
> and is complementary to the initial LMA discovery work in the NETLMM WG.
>
> 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.
>
> Milestones
>
> May 2009 ? ? ? ? ? ? WG chartered
> July 2009 ? ? ? ? ? ? ?Initial WG draft on Bulk Refresh
> 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 2009 ? ? ? 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: Xiangsong.Cui at huawei.com (Xiangsong Cui)
Date: Fri, 03 Apr 2009 16:52:06 +0800
Subject: [Netext] next steps for netext
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Jari,

Thank you for your updating the charter.

In my mind the BoF covers both the extensions on PMIP6 and 
the extension on PMIP4, and also the interworking between 
them, is it ?

After I read the charter, I was impressed that the extensions
are only on PMIP6, because the charter mentioned RFC5213 and
MEXT WG, but without any information about PMIP4.

Shall we show the scope more clearly?

Thanks and regards.

Xiangsong

????????  

??????????????? ???518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
????????????????????????????????????????
????????????????????????????????????????
???????????????????????????????????
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

  ----- Original Message ----- 
  From: Jari Arkko 
  To: netext at mail.mobileip.jp ; Rajeev Koodli ; Basavaraj Patil 
  Sent: Friday, April 03, 2009 3:31 PM
  Subject: [Netext] next steps for netext

  In the meeting we ended up having a big argument about the multihoming 
  and handover parts. I don't know what to do about that yet, but I would 
  still like to suggest that the other parts should move forward. I edited 
  the charter from the web site. Comments appreciated:

  -------

  Network-Based Mobility Extensions (NETEXT)

  Last Modified: 2009-04-03

  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. Hosts 
  are not affected, as they still send and receive their packets via the MAG.

  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, and is complementary to the initial LMA discovery work in the 
  NETLMM WG.

  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.

  Milestones

  May 2009             WG chartered
  July 2009              Initial WG draft on Bulk Refresh
  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 2009       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

  _______________________________________________
  NetExt mailing list
  NetExt at mail.mobileip.jp
  http://www.mobileip.jp/mailman/listinfo/netext
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090403/fe26601a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outlook_huawei_logo_cn.jpg
Type: image/jpeg
Size: 6737 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090403/fe26601a/attachment-0001.jpg>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Fri, 03 Apr 2009 09:52:55 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C1E8@ftrdmel1>
References: <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C1E8@ftrdmel1>
Message-ID: <[email-masked]>

Ah, yes, you are right of course. Thanks for spotting the error.

Jari

pierrick.seite at orange-ftgroup.com wrote:
> Hi Jari,
>
> I guess the milestone for submitting Submit LMA Redirection to IESG is January 2010, not 2009 :-)
>
> Regards,
> Pierrick
>
>   
>> -----Message d'origine-----
>> De : netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] De la part de Jari Arkko
>> Envoy? : vendredi 3 avril 2009 09:32
>> ? : netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
>> Objet : [Netext] next steps for netext
>>
>> In the meeting we ended up having a big argument about the multihoming
>> and handover parts. I don't know what to do about that yet, but I would
>> still like to suggest that the other parts should move forward. I edited
>> the charter from the web site. Comments appreciated:
>>
>> -------
>>
>> Network-Based Mobility Extensions (NETEXT)
>>
>> Last Modified: 2009-04-03
>>
>> 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. Hosts
>> are not affected, as they still send and receive their packets via the MAG.
>>
>> 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, and is complementary to the initial LMA discovery work in the
>> NETLMM WG.
>>
>> 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.
>>
>> Milestones
>>
>> May 2009             WG chartered
>> July 2009              Initial WG draft on Bulk Refresh
>> 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 2009       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
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     
>
>
>   

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Fri, 3 Apr 2009 09:47:52 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD105A7C1E8@ftrdmel1>

Hi Jari,

I guess the milestone for submitting Submit LMA Redirection to IESG is January 2010, not 2009 :-)

Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de Jari Arkko
> Envoy??: vendredi 3 avril 2009 09:32
> ??: netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> Objet?: [Netext] next steps for netext
> 
> In the meeting we ended up having a big argument about the multihoming
> and handover parts. I don't know what to do about that yet, but I would
> still like to suggest that the other parts should move forward. I edited
> the charter from the web site. Comments appreciated:
> 
> -------
> 
> Network-Based Mobility Extensions (NETEXT)
> 
> Last Modified: 2009-04-03
> 
> 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. Hosts
> are not affected, as they still send and receive their packets via the MAG.
> 
> 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, and is complementary to the initial LMA discovery work in the
> NETLMM WG.
> 
> 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.
> 
> Milestones
> 
> May 2009             WG chartered
> July 2009              Initial WG draft on Bulk Refresh
> 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 2009       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
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: jari.arkko at piuha.net (Jari Arkko)
Date: Fri, 03 Apr 2009 09:31:44 +0200
Subject: [Netext] next steps for netext
Message-ID: <[email-masked]>

In the meeting we ended up having a big argument about the multihoming 
and handover parts. I don't know what to do about that yet, but I would 
still like to suggest that the other parts should move forward. I edited 
the charter from the web site. Comments appreciated:

-------

Network-Based Mobility Extensions (NETEXT)

Last Modified: 2009-04-03

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. Hosts 
are not affected, as they still send and receive their packets via the MAG.

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, and is complementary to the initial LMA discovery work in the 
NETLMM WG.

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.

Milestones

May 2009             WG chartered
July 2009              Initial WG draft on Bulk Refresh
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 2009       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: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Wed, 1 Apr 2009 13:00:50 -0400
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Hitoshi,

> Is it guaranteed that regular MNs (i.e. with no protocol 
> modification) and MNs with new extension can coexist in 
> either the traditional (or
> standard) PMIP domain or new PMIP domain which would have 
> some difference in the current LMA/MAG configuration?

Again, no new protocols on the MN side. 

Folks would like to work on the multiple interface support and
inter-tech handovers.
As it turns out, one of the primary questions here is how a single
address can be made to work on multiple interfaces. From what I have
heard, this can be done in implementation-specific ways (i.e., no
protocol extensions). What I feel may be useful is to document one or
two techniques (such as use of virtual interface) in an Informational
ID. It is up to the group to decide, finally..

Hope this is useful.

Regards,

-Rajeev

> 
> The interoperability is the most important thing for the 
> further discussion.
> 
> Regards,
> --
> Hitoshi Asaeda
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 01 Apr 2009 14:19:43 +0200
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Sangjin,

Sangjin Jeong schrieb:
> Hi Marco,
>
> Thanks for developing the RO PS document. It seems that the RO application
> scenarios in the current document does not explicitly mention IPv4
> support cases.
>   
Yes, good point. I agree that we should mention IPv4 support in the PS 
and consider
IPv4 in the solution space.

> When a PMIP6 domain supports IPv4, the IPv4 support scenario of RO may be
> divided into following possible subcases.
>
> (1) a MN and a CN IPv4 home address mobility
>   
IPv4 home address mobility I see as main aspect we need to take into 
account for the solution.

> (2) a MN and a CN belong to different MAGs and both MAGs support IPv4 transport
> to the same LMA
> (3) a MN and a CN belong to different MAGs and the MAGs support
> different IP version
> transport to the same LMA
>   
For these cases, I am not sure if there is anything to be done on the 
interface
between MAG and LMA which is not to be solved for RFC5213 operation already.
Maybe I misunderstood the subcase.
But I see some need to take care about transport between MAGs, which means
using IPv4 tunnels between MAGs in case of v4 only transport.

> I think that it is worthwhile to investigate each subcase so as to
> decide which subcase
> should be included in the scope and/or whether there is any issue to
> be resolved.
>   
Yes, fully agree.

Thanks,
marco

> Regards,
> Sangjin
>
> On Thu, Feb 5, 2009 at 7:33 AM, Marco Liebsch <liebsch at nw.neclab.eu> wrote:
>   
>> Hi all,
>>
>> please find the link to a first version of a Localized Routing Problem
>> Statement below.
>> The abstract of the PS document is as follows:
>>
>> Abstract:
>>
>>  Proxy Mobile IPv6 is the IETF standard for network-based localized
>>  mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>  topologically anchored at a Local Mobility Anchor, which forwards all
>>  data for registered mobile nodes.  The set up and support for
>>  localized routing, which allows forwarding of data packets between
>>  mobile nodes and correspondent nodes directly without traversing an
>>  LMA, is not considered.  This document describes the problem space of
>>  localized routing in Proxy Mobile IPv6.
>>
>>
>> Any comments to this version of the problem statement are welcome.
>>
>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
>>
>> Best regards,
>> marco
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>>     

From: asaeda at sfc.wide.ad.jp (Hitoshi Asaeda)
Date: Wed, 01 Apr 2009 12:55:33 +0900 (JST)
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

> we should discuss "MN involvement" more clearly rather than overloading it.
>  
> During the introduction, we made it clear that No New protocols are
>  planned (please see the slides).
> However, host-internal modifications that may be needed should be in
>  scope (this does not mean we need a normative document). A specific
>  example is the management of the same address over multiple
>  interfaces. As some folks have argued, this seems feasible (without
>  saying you need classical Mobile IP for this) with techniques that
>  people implement on their own. We might want to document some of
>  those in an Informational document. 
>  
> This is Network-mobility Extensions. So, I think we should be able
>  to support features like multiple interface support and inter-tech
>  handovers without new protocol extensions (but *may* be with
>  techniques we don't have to normatively specify).

Is it guaranteed that regular MNs (i.e. with no protocol modification)
and MNs with new extension can coexist in either the traditional (or
standard) PMIP domain or new PMIP domain which would have some
difference in the current LMA/MAG configuration?

The interoperability is the most important thing for the further
discussion.

Regards,
--
Hitoshi Asaeda

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 31 Mar 2009 12:38:09 -0400
Subject: [Netext] Today's BOF Discussion
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Behcet,
 
we should discuss "MN involvement" more clearly rather than overloading it.
 
During the introduction, we made it clear that No New protocols are planned (please see the slides).
However, host-internal modifications that may be needed should be in scope (this does not mean we need a normative document). A specific example is the management of the same address over multiple interfaces. As some folks have argued, this seems feasible (without saying you need classical Mobile IP for this) with techniques that people implement on their own. We might want to document some of those in an Informational document. 
 
This is Network-mobility Extensions. So, I think we should be able to support features like multiple interface support and inter-tech handovers without new protocol extensions (but *may* be with techniques we don't have to normatively specify).
 
Regards,
 
-Rajeev

________________________________

From: netext-bounces at mail.mobileip.jp on behalf of Behcet Sarikaya
Sent: Tue 3/31/2009 9:04 AM
To: Mohana Jeyatharan; Domagoj Premec; ext Sri Gundavelli
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Subject: Re: [Netext] Today's BOF Discussion

During netext BoF it became clear that people were very much concerned with MN involvement. PMIPv6 was designed with the assumption of no MN involvement.
 
Same sensitivity was shown in 6ai BoF. When IPv6 was designed they said no need for NAT boxes. 6ai BoF was proposing IPv6 NAT.
 
This is the bottom line which should be respected I think. 
 
Cheers,
 
Behcet

________________________________

From: Mohana Jeyatharan <Mohana.Jeyatharan at sg.panasonic.com>
To: Behcet Sarikaya <sarikaya at ieee.org>; Domagoj Premec <domagoj.premec.ext at nsn.com>; ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Sent: Monday, March 30, 2009 7:16:39 PM
Subject: RE: [Netext] Today's BOF Discussion

Hi Behcet,

I think the issue of multilink subnet is not a issue if the host is slightly changed and knows this is PMIP domain and not the conventional multilink subnet. What I mean is we have a Point to point ink model here for PMIP and we have unique prefix per MN and the issues with multilink will not appear. A small host fix would do. Anyway many SDOs do some small host fixes even when they apply PMIP. 

For example, unmodified host DAD is essential according to IETF RFCs. But in 3GPP standard document they say DAD can be optional reason being per MN unique prefix. Thus small
host modification when we consider PMIPv6 alone should be allowed and I really don't see why not.

These are few thoughts.

BR,
Mohana

________________________________________
From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Behcet Sarikaya
Sent: Tuesday, March 31, 2009 5:12 AM
To: Domagoj Premec; ext Sri Gundavelli
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Subject: Re: [Netext] Today's BOF Discussion

I agree with Domagoj.
Besides advertizing the same prefix on two different interfaces of MN as in Fig. 4 of Ryuji's paper will create multi-link subnet at the LMA.
 
Unless these two interfaces are single-radio interfaces.
 
Regards,
 
Behcet

________________________________________
From: Domagoj Premec <domagoj.premec.ext at nsn.com>
To: ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft..com <mailto:dthaler at windows.microsoft.com> 
Sent: Friday, March 27, 2009 2:07:04 AM
Subject: Re: [Netext] Today's BOF Discussion

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by 
> >> binding the address/prefix to a virtual interface and by 
> not exposing 
> >> the physical interface or by hiding the handoff events from the 
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the 
> > PMIPv6 service in the network (how?) so that it knows that 
> it needs to 
> > instantiate the virtual interface and assign the address to the 
> > virtual interface instead of assigning it to a physical 
> interface. And 
> > then some sort of connection manager is neccessary that takes care 
> > that the virtual interface is associated with the right physical 
> > interface (the active one) as the MN moves across access networks.
> >
> 
> The piece of software that is required on the host for 
> supporting this capability, is not changing "any of the IETF 
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's 
> provide software SDK to implement this. So, application 
> requirement does not imply host change.
> 
> If you install a IPsec client on a host, it creates a virtual 
> adapter, the VPN address is bound to the adapter and all 
> applications bind to this address. Is this a host change or 
> an application requirement ?
> 
> When we say we dont want host change, as I see it, we are not 
> requiring changes to the earlier specified IETF protocol 
> specifications, it does count an application requirement..
> 
> Sri
> 
> 
> 

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

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Tue, 31 Mar 2009 09:04:46 -0700 (PDT)
Subject: [Netext] Today's BOF Discussion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

During netext BoF it became clear that people were very much concerned with MN involvement. PMIPv6 was designed with the assumption of no MN?involvement.

Same sensitivity was shown in 6ai BoF. When IPv6 was designed they said no need for NAT boxes. 6ai BoF was proposing IPv6 NAT.

This is the bottom line which should be respected I think. 

Cheers,

Behcet

________________________________
From: Mohana Jeyatharan <Mohana.Jeyatharan at sg.panasonic.com>
To: Behcet Sarikaya <sarikaya at ieee.org>; Domagoj Premec <domagoj.premec.ext at nsn.com>; ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Sent: Monday, March 30, 2009 7:16:39 PM
Subject: RE: [Netext] Today's BOF Discussion

Hi Behcet,

I think the issue of multilink subnet is not a issue if the host is slightly changed and knows this is PMIP domain and not the conventional multilink subnet. What I mean is we have a Point to point ink model here for PMIP and we have unique prefix per MN and the issues with multilink will not appear. A small host fix would do. Anyway many SDOs do some small host fixes even when they apply PMIP. 

For example, unmodified host DAD is essential according to IETF RFCs. But in 3GPP standard document they say DAD can be optional reason being per MN unique prefix. Thus small
host modification when we consider PMIPv6 alone should be allowed and I really don't see why not.

These are few thoughts.

BR,
Mohana

________________________________________
From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Behcet Sarikaya
Sent: Tuesday, March 31, 2009 5:12 AM
To: Domagoj Premec; ext Sri Gundavelli
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Subject: Re: [Netext] Today's BOF Discussion

I agree with Domagoj.
Besides advertizing the same prefix on two different interfaces of MN as in Fig. 4 of Ryuji's paper will create multi-link subnet at the LMA.
?
Unless these two interfaces are single-radio interfaces.
?
Regards,
?
Behcet

________________________________________
From: Domagoj Premec <domagoj.premec.ext at nsn.com>
To: ext Sri Gundavelli <sgundave at cisco.com>
Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
Sent: Friday, March 27, 2009 2:07:04 AM
Subject: Re: [Netext] Today's BOF Discussion

Hi Sri,

Having to install a new application on the host qualifies as a host change
in my eyes. We can debate what exactly is the host change, is this a change
to the IP stack, or to the link layer, or an additional application... My
opinion is that as long as it doesn't work out of the box with the
off-the-shelf hosts, it is a host change.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 26. ozujak 2009 23:53
> To: Domagoj Premec
> Cc: netext at mail.mobileip.jp; dthaler at windows.microsoft.com
> Subject: RE: [Netext] Today's BOF Discussion
> 
> Hi Domagoj,
> 
> >
> >> Now, what is not assured is the aspect of session continuity.
> >> Which requires a virtual interface implementation on the host, by 
> >> binding the address/prefix to a virtual interface and by 
> not exposing 
> >> the physical interface or by hiding the handoff events from the 
> >> layer-3 stack.
> >
> > For me, this is a host change. The host needs to be aware of the 
> > PMIPv6 service in the network (how?) so that it knows that 
> it needs to 
> > instantiate the virtual interface and assign the address to the 
> > virtual interface instead of assigning it to a physical 
> interface. And 
> > then some sort of connection manager is neccessary that takes care 
> > that the virtual interface is associated with the right physical 
> > interface (the active one) as the MN moves across access networks.
> >
> 
> The piece of software that is required on the host for 
> supporting this capability, is not changing "any of the IETF 
> RFC's", 4861, 4862, ... name it. To qualify this, all OS's 
> provide software SDK to implement this. So, application 
> requirement does not imply host change.
> 
> If you install a IPsec client on a host, it creates a virtual 
> adapter, the VPN address is bound to the adapter and all 
> applications bind to this address. Is this a host change or 
> an application requirement ?
> 
> When we say we dont want host change, as I see it, we are not 
> requiring changes to the earlier specified IETF protocol 
> specifications, it does count an application requirement.
> 
> Sri
> 
> 
> 

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

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090331/ac728b0e/attachment-0001.html>