[Netext] next steps for netext

Hi Domagoj,

On Fri, 10 Apr 2009, Domagoj Premec wrote:

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

I agree with you. The features that are supported in 5213, obviously
the mobile needs to be able to make use of it, some of the work I
proposed also aligns with this. RFC 5213's focus was on the network
side, we need ot be able to cover all the aspects.

Regards
Sri

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