Subject: Re: [Mipshop] Proposed new charter

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Mar 2008 20:43:12 -0700 (PDT)

Hi Stefano,
  Sorry but my memory does not confirm your observations on what happened in mext WG. Can you point out exactly where and when these things happened?

Regards,

Behcet

----- Original Message ----
From: Stefano Faccin <[email-masked]>
To: [email-masked]
Cc: Mipshop <[email-masked]>; [email-masked]
Sent: Thursday, March 13, 2008 10:50:17 AM
Subject: Re: [Mipshop] Proposed new charter

.hmmessage P
{
margin:0px;padding:0px;}
body.hmmessage
{
FONT-SIZE:10pt;FONT-FAMILY:Tahoma;}
Zarrar,
I am not disagreeing with you that optimizing the various tunnels and related procedure is an interesting and potentially useful work.
 
However, the tunnel optimization work is coming to us from MEXT, where there was extensive discussion and a good consensus built. If we want to extend the work beyond what already has consensus, we need to go through a wide discussion that may delay considerably our ability to adopt the new charter and definitely delay the rest of the work. I am not sure this is the best way forward for the working group. We could proceed in stages, i.e. optimizing first the tunnels over the air, then in a later phase (rechartering) focus on other tunnel optimizations.
 
Cheers,
Stefano

From: [email-masked] [mailto:[email-masked]]
Sent: Thu 3/13/2008 6:28 AM
To: Frank Xia; Stefano Faccin; Vijay Devarapalli
Cc: Mipshop; [email-masked]
Subject: RE: [Mipshop] Proposed new charter

Hello Stefano and Vijay,
 
I would support Frank in his argument regarding expanding the scope and focus of the charter. I would like to stress again that we need to have a holistic look at the tunneling optimization issue. IMO when we talk about the tunneling overhead, it should also encompass all other exchange of protocol messages that is exchanged "while" the tunnel is established and not confine the specifics of the charter for messages that go "through" the tunnel only.....
 
The charter should allow tackling the issue at two parallel and synchronous tiers:
 
1. To reduce the tunneling overhead over the air link (as per the original charter suggestion)
2. To optimize the tunnel itself in terms of the processing delay and resource consumption.
 
I think that managing the two issues together is very important as they depend on each other and MAY have affects on each other. 
 
In view of the fact that we already have ideas and/or drafts to support the above two issues, taking upon the two issues together would quicken the pace of standardization and optimization.
 
I hope to get some performance results in a little more than a month regarding the second aspect and will share the result with the members.
 
BR
 
Zarrar Yousaf

Date: Wed, 12 Mar 2008 21:13:54 -0500
From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [Mipshop] Proposed new charter

Hi Stefano and Vijay
 
If you say tunnel optimization is only for radio,
I don't agree.
 
Header compression is popular practice in the industry.
IMO, if we only focus on this, I think we can benefit little for our effort.

BR
Frank
----- Original Message ----- 
From: Stefano Faccin 
To: Vijay Devarapalli ; Frank Xia 
Cc: Mipshop ; [email-masked] 
Sent: Wednesday, March 12, 2008 4:23 PM
Subject: RE: [Mipshop] Proposed new charter

Frank,
I definitely agree with Vijay. In a wireless communication, the bottleneck is mostly on the radio leg, therefore it is important to optimize the tunnel over the radio. As Vijay correctly says below, PMIP does not tunnel over the radio, so we should not focus on it for the time being. I would suggest we solve one problem at a time.
Cheers,
Stefano

From: [email-masked] on behalf of Vijay Devarapalli
Sent: Wed 3/12/2008 2:11 PM
To: Frank Xia
Cc: Mipshop; [email-masked]
Subject: Re: [Mipshop] Proposed new charter

Frank Xia wrote:
> Hi Vijay
>
> First of all, I am supporting this rechartering item in general.
>
> IMO, mechanism that is applicable to MIP is also possible feasible
> to PMIP  after some adaptations.
> I don't  think it is necessary to exclude the possibility of  PMIPv6 application.

If it is possible to re-use the solution we develop for
PMIPv6 also, great. But we are not going to focus on
PMIPv6 or FMIPv6 for now.

Vijay

>
> BR
> Frank
>
> ----- Original Message -----
> From: "Vijay Devarapalli" <[email-masked]>
> To: "Frank Xia" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; "Mipshop" <[email-masked]>
> Sent: Wednesday, March 12, 2008 1:52 PM
> Subject: Re: [Mipshop] Proposed new charter
>
>
>> Frank Xia wrote:
>>> Hi Vijay
>>>
>>> I would like to suggest that PMIPv6 is in the scope.
>> The PMIPv6 tunnel is not over the air. In addition, the PMIPv6
>> tunnel between the MAG and the LMA is used carry traffic for a
>> number of mobile nodes. There is no tunnel per mobile node.
>>
>> What kind of optimization do we need for PMIPv6?
>>
>> Vijay
>>
>>> BR
>>> Frank
>>>
>>> ----- Original Message -----
>>> From: "Vijay Devarapalli" <[email-masked]>
>>> To: <[email-masked]>
>>> Cc: <[email-masked]>; "Mipshop" <[email-masked]>
>>> Sent: Wednesday, March 12, 2008 1:40 PM
>>> Subject: Re: [Mipshop] Proposed new charter
>>>
>>>
>>>> Hello Zarrar,
>>>>
>>>> I believe the current scope of work is about reducing the tunneling
>>>> overhead over the air due to protocols like MIPv6 and HMIPv6. This
>>>> work had a lot of consensus in the MEXT WG and then transferred here.
>>>>
>>>> My personal opinion is that I think we should stick to that scope
>>>> for now. Expanding the scope of the work would require more
>>>> discussions and consensus in the MIPSHOP WG. Until then we should
>>>> not expand the scope.
>>>>
>>>> Vijay
>>>>
>>>> [email-masked] wrote:
>>>>> Hello Stefano,
>>>>> 
>>>>> Thanks for your comments and your feedback. I agree with your argument
>>>>> but on the other hand, IMHO, the duration of the tunnel existence is
>>>>> also a resource consuming phenomena in which resources are reserved on
>>>>> both ends of the tunnel and the tunneling/de-tunneling of packets
>>>>> (in both directions) will not only add extra overhead but also incur
>>>>> processing delay and this will impact real time communication sessions
>>>>> and fast moving users (with smaller dwell times) in terms of jitter and
>>>>> delays.
>>>>> I very much agree that a holistic and across-the-board approach towards
>>>>> optimizing the tunneling function is required (so that MIPv6 can also be
>>>>> optimised) but I would also suggest that this aspect (of finding ways to
>>>>> reduce tunneling duration) should also be made part of the new charter,
>>>>> as I see FMIPv6 a good candidate for providing near-seamless handovers
>>>>> for "fast moving users".
>>>>> 
>>>>> take care
>>>>> 
>>>>> Zarrar Yousaf
>>>>> Communication Networks Institute,
>>>>> Dortmund University of Technology (TU Dortmund)
>>>>> Germany
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     Subject: RE: [Mipshop] Proposed new charter
>>>>>     Date: Wed, 12 Mar 2008 08:01:17 -0700
>>>>>     From: [email-masked]
>>>>>     To: [email-masked]; [email-masked]
>>>>>     CC: [email-masked]
>>>>>
>>>>>     Dear Zarraf,
>>>>>     thanks for the email. Interesting draft. My understanding of the
>>>>>     tunnel optimization in the charter is however slightly different. In
>>>>>     fact the charter refers to "negative impact on the protocol
>>>>>     efficiency which is translated in the data packet size, bandwidth
>>>>>     usage and battery power consumption. Therefore, a mechanism which
>>>>>     enables reducing the tunneling overhead would benefit the mobile
>>>>>     node and optimize the bandwidth usage. The MIPSHOP WG will
>>>>>     standardize such a mechanism." Therefore the charter refers to
>>>>>     optimizations to the way tunneling is performed to e.g. reduce the
>>>>>     size of the packets. IMO it does not refer to the temporary tunnel
>>>>>     created in FMIPv6 between the PAR and the NAR, but to the tunneling
>>>>>     present through the whole connection.
>>>>>     Cheers,
>>>>>     Stefano
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     *From:* [email-masked] on behalf of [email-masked]
>>>>>     *Sent:* Wed 3/12/2008 1:32 AM
>>>>>     *To:* Frank Xia; Vijay Devarapalli
>>>>>     *Cc:* 'Mipshop'
>>>>>     *Subject:* Re: [Mipshop] Proposed new charter
>>>>>
>>>>>     Hello,
>>>>>     
>>>>>     Regarding Tunnel optimization in FMIPv6, a draft has already been
>>>>>     submitted called "Proactive Bindings in FMIPv6"
>>>>>     (https://datatracker.ietf.org/drafts/draft-yousaf-ietf-mipshop-pbfmipv6/)
>>>>>     in which a proposal regarding the reduction of the tunnel
>>>>>     duration has already been proposed.
>>>>>     
>>>>>     At the moment we are performing simulation and measurement tests and
>>>>>     the initial results are  very encouraging, however i will be able to
>>>>>     share more details after about one month.
>>>>>     
>>>>>     BR
>>>>>     
>>>>>     Zarrar Yousaf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>      > Date: Tue, 11 Mar 2008 18:38:52 -0500
>>>>>      > From: [email-masked]
>>>>>      > To: [email-masked]
>>>>>      > CC: [email-masked]
>>>>>      > Subject: Re: [Mipshop] Proposed new charter
>>>>>      >
>>>>>      > Hi Vijay
>>>>>      >
>>>>>      > Please see my reply..
>>>>>      >
>>>>>      > BR
>>>>>      > Frank
>>>>>      > ----- Original Message -----
>>>>>      > From: "Vijay Devarapalli" <[email-masked]>
>>>>>      > To: "Frank Xia" <[email-masked]>
>>>>>      > Cc: "'Mipshop'" <[email-masked]>
>>>>>      > Sent: Tuesday, March 11, 2008 5:29 PM
>>>>>      > Subject: Re: [Mipshop] Proposed new charter
>>>>>      >
>>>>>      >
>>>>>      > > Frank Xia wrote:
>>>>>      > > > Hi Vijay
>>>>>      > > >
>>>>>      > > > For Tunnel Optimization, why should we limit in Mobile IPv6
>>>>>     and HMIP6?
>>>>>      > >
>>>>>      > > It wasn't meant to be an exhaustive list of protocols that
>>>>>      > > tunnel.
>>>>>      > Frank=>IMO, it is a little bit ambiguous. For example,
>>>>>      > why is HMIP6 is highlighted? why isn't FMIP6 highlighted?
>>>>>      > It will be helpful if you make it clearer.
>>>>>      >
>>>>>      > >
>>>>>      > > > I think it is also possible for PMIPv6 and Mobile IPv4.
>>>>>      > >
>>>>>      > > We have not taken on any work related to Mobile IPv4 so far.
>>>>>      > >
>>>>>      > > Vijay
>>>>>      > >
>>>>>      > > >
>>>>>      > > > BR
>>>>>      > > > Frank
>>>>>      > > >
>>>>>      > > >
>>>>>      > > > ----- Original Message -----
>>>>>      > > > From: "Vijay Devarapalli" <[email-masked]>
>>>>>      > > > To: "'Mipshop'" <[email-masked]>
>>>>>      > > > Sent: Tuesday, March 11, 2008 5:12 PM
>>>>>      > > > Subject: Re: [Mipshop] Proposed new charter
>>>>>      > > >
>>>>>      > > >
>>>>>      > > >> Hello,
>>>>>      > > >>
>>>>>      > > >> The MEXT working group has asked to take on some additional
>>>>>     work.
>>>>>      > > >> This is about a mechanism to reduce the tunneling overhead
>>>>>     due to
>>>>>      > > >> MIPv6 and HMIPv6. So we modified the charter to include this
>>>>>     work
>>>>>      > > >> too. Here is the revised charter. Please review.
>>>>>      > > >>
>>>>>      > > >>
>>>>>     ------------------------------------------------------------------------
>>>>>      > > >>
>>>>>      > > >> Mobility for IP: Performance, Signaling and Handoff
>>>>>     Optimization (MIPSHOP)
>>>>>      > > >>
>>>>>      > > >> Description of Working Group:
>>>>>      > > >>
>>>>>      > > >> Mobile IPv6 enables IPv6 mobile nodes to continue using a given
>>>>>      > > >> "home address" in spite of changes in its point of attachment to
>>>>>      > > >> the network. These changes may cause delay, packet loss, and
>>>>>     also
>>>>>      > > >> represent overhead traffic on the network. The MIPSHOP WG has so
>>>>>      > > >> far worked on two technologies to address these issues.
>>>>>      > > >> Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency
>>>>>      > > >> of signaling between a MN, its Home Agent and one or more
>>>>>      > > >> correspondent nodes. Fast Handovers for Mobile IPv6 (FMIPv6)
>>>>>      > > >> reduces packet loss by providing fast IP connectivity as soon as
>>>>>      > > >> the mobile node establishes a new point of attachment at a new
>>>>>      > > >> link.
>>>>>      > > >>
>>>>>      > > >> The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and
>>>>>      > > >> the necessary extensions to improve these protocols. The MIPSHOP
>>>>>      > > >> WG will also identify missing components that are required for
>>>>>      > > >> deploying these protocols and standardize the necessary
>>>>>     extensions.
>>>>>      > > >> The WG will also address interworking of these protocols
>>>>>     with other
>>>>>      > > >> mobility management protocols in the IETF, including
>>>>>     network-based
>>>>>      > > >> mobility management protocols.
>>>>>      > > >>
>>>>>      > > >> The IEEE 802.21 Media Independent Handoff (MIH) working
>>>>>     group aims
>>>>>      > > >> at providing services to assist with handoffs between
>>>>>     heterogeneous
>>>>>      > > >> link-layer technologies, and across IP subnet boundaries. MIH
>>>>>      > > >> services can be delivered through link-layer specific solutions
>>>>>      > > >> and/or through a "layer 3 or above" protocol. MIPSHOP will
>>>>>     define
>>>>>      > > >> the delivery of information for MIH services for this latter
>>>>>     case.
>>>>>      > > >> A L3 based mechanism to identify a valid information server
>>>>>     is also
>>>>>      > > >> required. The MIPSHOP will work on developing a protocol for
>>>>>      > > >> transport of MIH services information and mechanisms for
>>>>>     discovering
>>>>>      > > >> the MIH server. Security for the transport of MIH
>>>>>     information will
>>>>>      > > >> also be addressed.
>>>>>      > > >>
>>>>>      > > >> The widespread use of different forms of IP tunneling mechanisms
>>>>>      > > >> in mobile environment, e.g., MIPv6, HMIPv6, has a negative
>>>>>     impact
>>>>>      > > >> on the protocol efficiency which is translated in the data
>>>>>     packet
>>>>>      > > >> size, bandwidth usage and battery power consumption.
>>>>>     Therefore, a
>>>>>      > > >> mechanism which enables reducing the tunneling overhead would
>>>>>      > > >> benefit the mobile node and optimize the bandwidth usage. The
>>>>>      > > >> MIPSHOP WG will standardize such a mechanism.
>>>>>      > > >>
>>>>>      > > >> The MOBOPTS Research Group in the IRTF is chartered to work on
>>>>>      > > >> optimizations related to Mobile IPv6 and IP handoffs among other
>>>>>      > > >> things. The MIPSHOP WG will take mature proposals from the
>>>>>     MOBOPTS
>>>>>      > > >> group and standardize them in the IETF on a case-by-case basis.
>>>>>      > > >>
>>>>>      > > >> The MIPSHOP WG will also consider and standardize
>>>>>     optimizations for
>>>>>      > > >> the Mobile IPv6 protocol and IP mobility in general.
>>>>>      > > >>
>>>>>      > > >> Scope of MIPSHOP:
>>>>>      > > >>
>>>>>      > > >> The working group will:
>>>>>      > > >>
>>>>>      > > >> 1. Complete the current set of documents with the IESG
>>>>>      > > >> - HMIPv6 (draft-ietf-mipshop-4140bis)
>>>>>      > > >> - FMIPv6 (draft-ietf-mipshop-fmipv6-rfc4068bis)
>>>>>      > > >> - FMIPv6 over IEEE 802.16e (draft-ietf-mipshop-fh80216e)
>>>>>      > > >> - FMIPv6 over 3G CDMA 2000 (draft-ietf-mipshop-3gfh)
>>>>>      > > >> - MIH problem statement (draft-ietf-mipshop-mis-ps)
>>>>>      > > >>
>>>>>      > > >> 2. FMIPv6 Mobile Node - Access Router security using the AAA
>>>>>      > > >> infrastructure
>>>>>      > > >>
>>>>>      > > >> Currently MIPSHOP has produced a standards track protocol for
>>>>>      > > >> setting up security between the mobile node and access router
>>>>>      > > >> for security FMIPv6 signaling messages. However, the protocol
>>>>>      > > >> depends on SeND (Secure Neighbor Discovery) to be available on
>>>>>      > > >> the mobile node and the access router. An alternate mechanism
>>>>>      > > >> that leverages the AAA infrastructure is required. Many target
>>>>>      > > >> systems where FMIPv6 is likely to be used use a AAA
>>>>>      > > >> infrastructure to authenticate and authorize network access.
>>>>>      > > >>
>>>>>      > > >> 3. Prefix Management for point-to-point links
>>>>>      > > >>
>>>>>      > > >> Using FMIPv6 over point-to-points like requires some additional
>>>>>      > > >> considerations with respect to managing and allocating prefixes
>>>>>      > > >> for the mobile node on these point-to-point links. Therefore
>>>>>      > > >> the WG will work on a BCP to document these considerations.
>>>>>      > > >>
>>>>>      > > >> 4. Use of FMIPv6 with Proxy Mobile IPv6
>>>>>      > > >>
>>>>>      > > >> Proxy Mobile IPv6 (PMIPv6) is a network-based mobility
>>>>>      > > >> management protocol where a node in the access network, called
>>>>>      > > >> the Mobile Access Gateway (MAG) handles mobility on behalf of
>>>>>      > > >> the mobile node. It has been proposed to use FMIPv6 to
>>>>>      > > >> optimize the handover in terms of reducing the packet loss and
>>>>>      > > >> transferring relevant context from the old MAG to the new MAG.
>>>>>      > > >> The working group will work on specifying FMIPv6 extensions to
>>>>>      > > >> enable fast handovers for PMIPv6.
>>>>>      > > >>
>>>>>      > > >> 5. Work on protocols and extensions for transporting information
>>>>>      > > >> related to IEEE 802.21:
>>>>>      > > >>
>>>>>      > > >> The work includes the layer 3 protocol for transporting MIH
>>>>>      > > >> related information and DHCP and DNS extensions for discovery
>>>>>      > > >> the information servers.
>>>>>      > > >>
>>>>>      > > >> 6. IP Tunneling Optimization
>>>>>      > > >>
>>>>>      > > >> Work on a mechanism to reduce the tunneling overhead associated
>>>>>      > > >> with protocols like Mobile IPv6 and HMIPv6.
>>>>>      > > >>
>>>>>      > > >> 7. Standardize mature proposals from the MOBOPTS IRTF Group
>>>>>      > > >>
>>>>>      > > >>
>>>>>      > > >> Goals and Milestones:
>>>>>      > > >>
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt
>>>>>      > > >> Done Working Group Last Call on
>>>>>      > > >> draft-ietf-mipshop-lmm-requirements-XX.txt
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt
>>>>>      > > >> Done Discuss Last Call comments and security analyses at IETF 58
>>>>>      > > >> Done Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt
>>>>>     to IESG
>>>>>      > > >> for publication as Informational
>>>>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for
>>>>>     publication
>>>>>      > > >> as Experimental
>>>>>      > > >> Done Submit draft-ietf-mipshop-hmip-xx.txt to IESG for
>>>>>     publication
>>>>>      > > >> as Experimental
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-80211fh-xx.txt
>>>>>      > > >> for Informational
>>>>>      > > >> Done Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for
>>>>>      > > >> publication as Informational
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-cga-cba-XX.txt
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mis-ps
>>>>>      > > >> Done Submit draft-ietf-mipshop-cga-cba to the IESG for
>>>>>     publication
>>>>>      > > >> as Proposed Standard
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-fmipv6-rfc4068bis
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-handover-key-send
>>>>>      > > >> Done Submit draft-ietf-mipshop-mis-ps to the IESG for
>>>>>     publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-rfc4041bis
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-3gfh
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fh80216e
>>>>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-rfc4068bis to the IESG
>>>>>     for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Done Submit draft-ietf-mipshop-handover-key-send to the IESG
>>>>>     for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Done Submit draft-ietf-mipshop-3gfh to IESG for publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Submit draft-ietf-mipshop-fh80216e to IESG for
>>>>>     publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mih-support
>>>>>      > > >> Apr 2008 Submit draft-ietf-mipshop-4140bis to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Apr 2008 Submit draft-ietf-mipshop-mih-support to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> May 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-mos-dns-discovery
>>>>>      > > >> May 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-mos-dhcp-options
>>>>>      > > >> Jun 2008 Working group last call on
>>>>>     draft-ietf-mipshop-fmipv6-ptp
>>>>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dns-discovery to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dhcp-options to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Jul 2008 Working Group Last Call on draft-ietf-mipshop-pfmipv6
>>>>>      > > >> Jul 2008 Submit draft-ietf-mipshop-fmipv6-ptp to the IESG for
>>>>>      > > >> publication as Best Current Practice
>>>>>      > > >> Aug 2008 Submit draft-ietf-mipshop-pfmipv6 to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Aug 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-fmipv6-aaa-key
>>>>>      > > >> Oct 2008 Submit draft-ietf-mipshop-fmipv6-aaa-key to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Nov 2008 Working Group Last call on
>>>>>      > > >> draft-ietf-mipshop-tunneling-optimization
>>>>>      > > >> Jan 2009 Submit draft-ietf-mipshop-tunneling-optimization to
>>>>>     the the
>>>>>      > > >> IESG
>>>>>      > > >>
>>>>>      > > >>
>>>>>     ---------------------------------------------------------------------------
>>>>>      > > >>
>>>>>      > > >> Vijay
>>>>>      > > >> _______________________________________________
>>>>>      > > >> Mipshop mailing list
>>>>>      > > >> [email-masked]
>>>>>      > > >> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>      > > >>
>>>>>      > >
>>>>>      > >
>>>>>      > _______________________________________________
>>>>>      > Mipshop mailing list
>>>>>      > [email-masked]
>>>>>      > https://www.ietf.org/mailman/listinfo/mipshop
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     Climb to the top of the charts! Play the word scramble challenge
>>>>>     with star power. Play now!
>>>>>     <http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Shed those extra pounds with MSN and The Biggest Loser! Learn more.
>>>>> <http://biggestloser.msn.com/>
>>>> _______________________________________________
>>>> Mipshop mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>
>>

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

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. 

-----Inline Attachment Follows-----

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

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 18 Mar 2008 12:52:17 -0700 (PDT)

I support widening the scope. 

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: Alper Yegin <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Tuesday, March 18, 2008 1:37:17 PM
Subject: Re: [Mipshop] Proposed new charter

Hi Alper,

<chair hat on>

The work we are considering to add to the MIPSHOP charter currently
is rather very specific in scope. It is about using the FMIPv6
signaling messages to setup forwarding for packets between the MAGs
during a  PMIPv6 handover. The context is transferred as part of
signaling between the MAGs. The following draft was assumed.
http://www.ietf.org/internet-drafts/draft-yokota-mipshop-pfmipv6-02.txt
I also came to know that this document is now on the 3GPP2-IETF
dependency list. So 3GPP2 wants the IETF to standardize this draft.

Now I see that there is some interest in generic PMIPv6 handover
optimizations. Not necessarily just on avoiding packet loss during
the handover or transferring the context between the MAGs. Some of
the optimizations involve changes at the LMA. It is also not clear
whether some of the optimizations fit in MIPSHOP or NETLMM.

So, now we need to discuss whether we should expand the scope for
the work in MIPSHOP (something like PMIPv6 handover optimizations).
Or stick to the current narrow scope. I would like to see this
discussion happen ASAP, since I don't want MIPSHOP re-chartering
delay too much.

Vijay

Alper Yegin wrote:
> Hi Hidetoshi,
> 
> Right, I missed the tunneling aspect in my e-mail. I guess you are
> implicitly referring to an I-D in your message. I'd appreciate if you can
> send me the pointer.
> 
> Thanks.
> 
> Alper
> 
>> -----Original Message-----
>> From: Hidetoshi Yokota [mailto:[email-masked]]
>> Sent: Tuesday, March 18, 2008 3:18 PM
>> To: Alper Yegin
>> Cc: 'Vijay Devarapalli'; 'Mipshop'
>> Hi Alper,
>> Alper Yegin wrote:
>>> I'm guessing that we are not talking about the host using FMIPv6, as we
>> have
>>> been saying host is neither aware nor capable of L3 mobility management.
>> If
>>> all we are interested in is "context transfer for PMIPv6", then let's
>> say
>>> so. Whether the solution may be simply reusing some parts of FMIPv6
>> protocol
>>> is a discussion to have later.
>> One thing I would like to point out is that when you try to apply the
>> FMIPv6 concept to PMIPv6, information exchange between ARs (MAGs) is
>> inevitable since the mobile node is not involved in either its mobility
>> or fast handover. FMIPv6 supports packet forwarding from the PAR to NAR
>> and the NAR (New MAG) needs to know beforehand about, for example, the
>> MN-HoA to distinguish the forwarded packets. Such information needs to
>> be transferred from the PAR to NAR. The goal is fast handover and the
>> information exchange between ARs is a means for that and not separable.
>> Just highlighting the context transfer feature is not our intention and
>> could be misleading.
>>
>> I would appreciate your understanding.
>>
>> Regards,
>> --
>> Hidetoshi
>>
>>> Alper
>>>
>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Mar 2008 10:57:28 -0700 (PDT)

Ahmad, let's agree to disagree. But let's also agree not to use inflammatory language.

Regards,

Behcet

----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, March 19, 2008 11:26:34 AM
Subject: RE: [Mipshop] Proposed new charter

Sorry Behcet, but this is my last email exchange on this topic.

Firstly, I can not follow you replies because of the email format you
are using which is the least to be said is confusing.

Secondly, please see inline.

Regards, 
Ahmad

________________________________

    [Ahmad-start-2]
    I am not sure I understand what you are trying to say here, but
please
    see the above comment.
    
    [Ahmad-end-2]            
            
     [behcet to Ahmad-2]
    I think the question Vijay asked was if the scope should be
widened to the type of approaches you mentioned above in Ahmad-1, so I
take your view that you are in support of this?
    
[Ahmad-last-start]
It is very interesting!
 
Earlier you suggested for us to forget about the other solutions
proposed on netlmm wg and let us focus on the FMIPv6 for PMIPv6 handover
as the only solution for PMIPv6 handover. Later on, you admitted that
FMIPv6 solution is very speciifc in nature and supported the proposal of
widening the scope to include all other netlmm proposal to be addressed
under MIPSHOP! Now, you interpreting my views according to something
that I am not aware of.

Could you please focus on the technical discussion and let people speaks
for themselves.

Many thanks for your consideration.

Best Regards,
Ahmad     

[Ahmad-last-end]

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Mar 2008 09:00:19 -0700 (PDT)

Hi Ahmad,
  The point you made below is a good one.
However, it is possible that nMAG requests the context and the current draft copes with it using extensions to  Hi/Hack messages.

Regards,

Behcet 

----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: Rajeev Koodli <[email-masked]>
Cc: Mipshop <[email-masked]>; Vijay Devarapalli <[email-masked]>
Sent: Sunday, March 23, 2008 12:06:51 AM
Subject: Re: [Mipshop] Proposed new charter

 Hi 
Rajeev,
sorry 
for the late reply. please see one comment inline.
Regards, 
Ahmad 

      From: Rajeev Koodli   [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2008   7:13 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Vijay   Devarapalli; Mipshop
Subject: Re: [Mipshop] Proposed new   charter

  On Wed, Mar 19, 2008 at 1:58 PM, Ahmad Muhanna <[email-masked]> wrote:
                                  As I mentioned in my previous e-mail, base FMIP specifies parameters       to be exchanged in HI/HAck. Whether you call that CT or something else is       not relevant. We are using a similar set of parameters for PMIP       purposes.

      And, we defined options for HI/HAck in FMIP. They are meant to be       used by folks. Would you forbid using those options if folks want to       exchange parameters during handover? I would not; it does not make sense.       So, it is not quite accurate to characterize it as coupled with       CT!  

            [Ahmad]
      Well, then is the use of 
      CT within HI and Hack optional?

  There are some parameters in HI/HAck which are required, just as in FMIP. 
  We don't consider that as CT - just as you don't for a routing protocol that 
  exchanges link state information.

  Then there are options which a protocol can define. The language   (MUST/SHOULD/MAY) for using these options are dependent on the particular   protocol. For instance, in PFMIPv6, the context request option is used only   for the reactive handover case. 
   
  [Ahmad]
  Does 
  this mean that the proposed solution could stand alone and be deployed 
  with the Predictive fast Handover alone? 

  Regards,

  -Rajeev

      Best 
      Regards,
      Ahmad