[Netext] next steps for netext

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