RE: [NSIS] RE: nsis mobility interactions

hi hemant!

i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends classification
based on triplet (src adr, dest adr, flow label). in case of mobility it
would be much better to use the home address instead of the source address.
with a source address as part of the classifier all nodes along the path
require an update after the src address changed due to mobility.

ciao
hannes

> -----Original Message-----
> From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of
> Hemant.Chaskar@nokia.com
> Sent: Tuesday, October 29, 2002 10:07 PM
> To: robert.hancock@roke.co.uk; nsis@ietf.org
> Subject: 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

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis