[Netext] next steps for netext

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

This is done by a special L2 message introduced for that - i.e. a change of the host (which is not visible to IETF as it is done at L2 and not L3, but still very real)

Gerardo

> 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