[Netext] next steps for netext

>
> Hi Gerardo,
>
> > What is the different between:
> > - the mobile sending a L2 message named "Attach Type" which triggers the PBU
> and the HI included in it
> > - the mobile sending a L3 message named "Registration Request" or "Binding
> Update"
> >
>
> Sure, there is a difference:
>
> - The mobile making a simple attach decision, vs doing all the
>    protocol work specified in MIPv6, DSMIP, IKE and IPsec specs.
>    Constant signaling, tunneling over the air link.
>

Constant signaling???

For tunneling over the air IETF already defined solutions. You will need ROHC with or without MIPv6 (i.e. for VoIP)

> - Building a Mobile IPv6 stack, IKEv2, IPsec, DSMIP6 stack on to
>    Windows, all variants of Linux, MAC OS/X .... zillion other
>    platforms and doing interop testing.

Indeed, you are not doing interop testing because your L2 colleagues need to do them, you are just moving the problem to another department.

>   Vs, building a simple
>    application for L2 triggers, or modifying client stack for the
>    same, the efforts are of different order.
>
> The simple L2 message, saves me from all the above.

Just because you don't implement it and others specify and implement it :-)
And other SDOs will define different L2 messages which may not provide all enough information for your MAG.

> And I
> cant convince Apple to bundle MIPv6 stack or atleast allow me to
> build it using their SDK.
>

OK, convince them to go to change 802.11 standard and to implement a L2 indication for PMIPv6 then ;-)
And also to change the 3G standard and to implement the L2 indication for PMIPv6 also there.

Gerardo

> So, there are differences. The pain points are different.
>
> Sri
>
>
>
>
> > To me the difference is just that IETF can work on (i.e. define, extend) the
> latter but not on the former. And that the latter works on any L2 while the
> former is tied to a particular technology.
> >
> > Gerardo
> >
> >> -----Original Message-----
> >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp]
> >> On Behalf Of Sri Gundavelli
> >> Sent: Wednesday, April 08, 2009 3:12 PM
> >> To: Domagoj Premec
> >> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> >> 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
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >