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