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