[NSIS] RE: nsis mobility interactions

hi all,

i discussed these issues with Charles (Shen) at Yokohama. He (& colleagues) have produced newer drafts:
draft-shen-nsis-rsvp-mobileipv6-00.txt
draft-shen-nsis-mobility-fw-00.txt
which I think change some of the previous conclusions or at least emphasis.

since this is now effectively a framework discussion, i can recommend the second of these, as well as (I hope) section 5.3 of draft-ietf-nsis-fw-00.txt.

with the momentum behind the discussion, i'd like to highlight some of the more general questions:
*) can we agree the assumption that flow identification should be based on 'normal' header fields (i.e. not the HA e.g. in HAO). Note: this has some interesting implications for host implementations.
*) is the HA a suitable value to use as the basis of a reservation identifier (basically, does the way it gets secured provide sufficient protection from the point of view of devices which aren't the MN & CN)?
*) should we restrict the scope of NSIS considerations to MIP, or consider other mobility scenarios (e.g. SIP-based mobility solutions, or stuff as in draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't be a constant HA anyway?
*) actually, what are the re-authentication/re-authorisation requirements in such mobility scenarios? how much authority can be devolved to the interior nodes in the network?

plenty of others, of course...

cheers,

robert h.

> -----Original Message-----
> From: PIECHOCINSKI, MACIEJ [mailto:maciej.piechocinski@bell.ca]
> Sent: 25 October 2002 18:33
> To: nsis@ietf.org
> Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some 
> commentson
> draft-ietf-nsis-req-04.txt)
> 
> 
> draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues
> with RSVP & MIP:
> -using Home Address as a constant flow/reservation identification
> -localizing reservation updates
> -explicit teardown of old path after handoff
> 
> Maciej
> 
> Bob Braden wrote:
> > 
> >   *>
> >   *> Whenever i think about this, i have to admit i get 
> confused. (One of
> >   *> the reasons i like the thomas seamoby draft is the 
> abstract, which
> >   *> starts "IP Mobility along with RSVP makes my head hurt".)
> >   *>
> >   *> But in the hard handover (break-before-make 
> situation), the sort of
> >   *> reasoning is:  *) if you send the tear before the 
> handover, you will
> >   *> lose the whole e2e path (can't find the crossover point without
> >   *> signaling via the new router); *) if you wait until 
> after the handover,
> >   *> you no longer have the ability to signal via the old 
> router and you
> >   *> can't tear the dead branch down.  So, what would be 
> nice is if you
> >   *> could send some message after the handover which had a 
> reference to the
> >   *> old reservation in a way which allowed the dead branch 
> to be removed.
> >   *> (NB this path tear problem is only one of the 
> problems, of course. the
> >   *> analysis documents contain several others.)
> > 
> > Robert,
> > 
> > OK, you win, now my head hurts too ;-)  The problem, I 
> guess, is that
> > mobile IP breaks the Internet architecture in a fundamental 
> way, so to
> > understand how QoS signaling will work you have to look at 
> the details
> > of how mobile IP works.  That's just philosophy, but it does suggest
> > that we need to put the bandage where the wound is -- we probably
> > need a solution that is local to the mobile region, not E2E.
> > 
> > Bob
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis