[Netext] next steps for netext

Sri,

> Sure. But indeed, "Inter-tech handovers are supported in PMIPv6".

I still fail to see how the inter-tech handover works if you don't assume a
constrained enviroment where only attachment through a single access at a
time is allowed. What you say above is a generic statement, but it does not
hold for the generic deployment case. 

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 09. travanj 2009 00:12
> To: Domagoj Premec
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: RE: [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
> >>>>
> >>>
> >>>
> >>
> >
> >
> 