RE: [NSIS] RE: nsis mobility interactions

Hi:

The "draft-ietf-ipv6-flow-label-03.txt" recommends classification based on triplet (src adr, dest adr, flow label). We should not deviate from it unless it is essential.

Also, what are those interesting implications on host implementations that you were referring to?

Hemant  

-----Original Message-----
From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: Sunday, October 27, 2002 6:35 PM
To: PIECHOCINSKI, MACIEJ; nsis@ietf.org
Subject: [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
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis