[Netext] next steps for netext

Sri,

I think that as part of the netext work we should have a thorough look at
the "certain advanced handoff operations" and specify exactly how this is
supposed to work. Leaving this to be solved outside of the IETF is
suboptimal... RFC 5213 is an IETF standard and we should take care that it
works well under all scenarios without any unspecified assumption or
undocumented restrictions.

domagoj

> -----Original Message-----
> From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
> Sent: 10. travanj 2009 06:42
> To: Domagoj Premec
> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Subject: RE: [Netext] next steps for netext
> 
> Hi Domagoj,
> 
> 
> On Thu, 9 Apr 2009, Domagoj Premec wrote:
> 
> > 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.
> >
> 
> The specification provides all the required hooks on the network side.
> There are proper protocol semantics for achieving this. 
> However, on the terminal side, sure, for certain advanced 
> handoff operations, the terminal and the network need to be 
> in sync. If that is through a MN-AR interface, L2, L3 or AAA 
> , is a solution detail.
> 
> 
> Sri
> 
> 
> 
> > 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
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> 