Re: [Mipshop] Proposed new charter

["Stefano Faccin" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
Sent: Thu 3/13/2008 6:28 AM
To: Frank Xia; Stefano Faccin; Vijay Devarapalli
Cc: Mipshop; [e-mail]
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: [e-mail]
	To: [e-mail]; [e-mail]
	CC: [e-mail]; [e-mail]
	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 <mailto:[e-mail]>  
		To: Vijay Devarapalli <mailto:[e-mail]>  ; Frank Xia <mailto:[e-mail]>  
		Cc: Mipshop <mailto:[e-mail]>  ; [e-mail] 
		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: [e-mail] on behalf of Vijay Devarapalli
		Sent: Wed 3/12/2008 2:11 PM
		To: Frank Xia
		Cc: Mipshop; [e-mail]
		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" <[e-mail]>
		> To: "Frank Xia" <[e-mail]>
		> Cc: <[e-mail]>; <[e-mail]>; "Mipshop" <[e-mail]>
		> 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" <[e-mail]>
		>>> To: <[e-mail]>
		>>> Cc: <[e-mail]>; "Mipshop" <[e-mail]>
		>>> 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
		>>>>
		>>>> [e-mail] 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: [e-mail]
		>>>>>     To: [e-mail]; [e-mail]
		>>>>>     CC: [e-mail]
		>>>>>
		>>>>>     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:* [e-mail] on behalf of [e-mail]
		>>>>>     *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: [e-mail]
		>>>>>      > To: [e-mail]
		>>>>>      > CC: [e-mail]
		>>>>>      > Subject: Re: [Mipshop] Proposed new charter
		>>>>>      >
		>>>>>      > Hi Vijay
		>>>>>      >
		>>>>>      > Please see my reply..
		>>>>>      >
		>>>>>      > BR
		>>>>>      > Frank
		>>>>>      > ----- Original Message -----
		>>>>>      > From: "Vijay Devarapalli" <[e-mail]>
		>>>>>      > To: "Frank Xia" <[e-mail]>
		>>>>>      > Cc: "'Mipshop'" <[e-mail]>
		>>>>>      > 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" <[e-mail]>
		>>>>>      > > > To: "'Mipshop'" <[e-mail]>
		>>>>>      > > > 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
		>>>>>      > > >> [e-mail]
		>>>>>      > > >> https://www.ietf.org/mailman/listinfo/mipshop
		>>>>>      > > >>
		>>>>>      > >
		>>>>>      > >
		>>>>>      > _______________________________________________
		>>>>>      > Mipshop mailing list
		>>>>>      > [e-mail]
		>>>>>      > 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
		>>>> [e-mail]
		>>>> https://www.ietf.org/mailman/listinfo/mipshop
		>>>>
		>>
		
		_______________________________________________
		Mipshop mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/mipshop
		
		


________________________________

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. <http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join>  

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