Re: [netlmm] RE: Comments on draft-krishnan-netlmm-pmip-sel-00

Dear colleague.

> Yes, but then a MAG needs to be prepared to handle two different
> kinds of mobile nodes. Those that are vanilla IPv6 hosts and
> those that are PMIP6 aware. How does MAG know the difference?
> Based on the -proxymip6-01 when a MAG sends a RA the binding is
> already in process or completed. The MAG does not need to wait
> for a mobile to send a RS.

Actually, the MAG would send its RA message. However, there is an interval
time for sending RA message and an MN (wants to use its own mobility
signaling such as MIPv6) could send a RS message to get a RA message. Well,
as you mentioned, sure, there is no guarantee that the MN must send the RS
message with prior to the RA message sent from the MAG. This issue was
already mentioned before (
http://www1.ietf.org/mail-archive/web/netlmm/current/msg02594.html ), so
that S. Krishnan will consider this in the next version. Note that I cannot
be present in the Chicago meeting, S. Krishnan may perhaps solve this issue.

Cheers.

On 7/25/07, jouni.korhonen@teliasonera.com <jouni.korhonen@teliasonera.com>
wrote:
>
> Hi Suresh,
>
> > Hi Jouni,
> >    I see your point and I can empathize with you. I just want
> > to clarify a few things. The mechanism I proposed DOES NOT
> > require any changes on mobility unaware nodes (classic PMIP)
> > and everything works as expected.
>
> Yes, but then a MAG needs to be prepared to handle two different
> kinds of mobile nodes. Those that are vanilla IPv6 hosts and
> those that are PMIP6 aware. How does MAG know the difference?
> Based on the -proxymip6-01 when a MAG sends a RA the binding is
> already in process or completed. The MAG does not need to wait
> for a mobile to send a RS.
>
> > As far as using mobility signaling instead of using NDP/DHCP
> > hacks, this becomes impossible because PMIP makes the MN
> > believe that it has NOT MOVED and hence results in no
> > mobility signaling from the MN. So I do not see any other way
>
> Didn't get this. These prefix & mobility mode selections are
> mostly an issue durign the initial entry to the network.. afaik.
>
> > out of this. If there is such a way, I would be very happy to
> > follow it.
>
> Cheers,
>        Jouni
>
>
>
> >
> > Thanks
> > Suresh
> >
> > jouni.korhonen@teliasonera.com wrote:
> > > Hi Damic, Suresh, all,
> > >
> > >> Hi Suresh,
> > >>
> > >> I agree with your comments, PMIP6 indication is exactly what we
> > >> wanted to describe in the draft.
> > >> The MN does not explictly request PMIP6 / MIP6 service,
> > and neither
> > >> MAG has to make that decision.
> > >>
> > >> As we see it, the goal is to minimize the impact on the legacy
> > >> terminal e.g. nodes that are not MIP-capable.
> > >
> > > I have this issue with enhancing PMIP6 awareness in mobile nodes at
> > > layer-3. The nice idea of PMIP was that it is transparent, working
> > > without mobile node involvement in mobility signaling and requires
> > > minimal if any changes (i.e. no new client or stack
> > > modifications) in the mobile node. Why we now try to change these
> > > assumptions and try to add 'mobility client' like functionality to
> > > mobile nodes? Instead of calling the new functionality as a 'host
> > > mobility client' we extend address configuration phase, ultimately
> > > moving some of the unwanted 'client' functionality there.
> > Also instead
> > > of doing separate mobility signaling we bloat NDP and DHCP.
> > > I find this slightly controversial in PMIP6 context.
> > Though, I am well
> > > aware of the uses cases that would benefit from the proposed
> > > functionality, but still..
> > >
> > > [snip]
> > >
> > > Sorry for the rant ;-)
> > >
> > > Cheers,
> > >     Jouni
> > >
> > >
> > >
> >
> >
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www1.ietf.org/mailman/listinfo/netlmm
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org