[Netext] next steps for netext

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
> 