Dave, Dave Thaler wrote: > > How does the application requesting a particular lifetime effect the > > lifetime that the routers use when advertising the unicast prefix? > > It doesn't. > In the abstract API, the application supplies a minimum and desired > lifetime. If the app says [0, 6 months] and the host knows that > the unicast prefix is valid for 1 week, it can tell the app it has > it for one week (and the app can renew it at any time).
That was my intent. It fits the existing v4 mcast allocation architecture. A host may request an address for ANY particular lifetime, but there are no guarantees that the requested lifetime can be honored. > > > Are you envisioning some new protocol to inform the routers (and the > > system > > admin, ISP, RIR) that allocated the unicast prefix that it needs to > > stay around for long enough to satisfy the applications request? :-) > > Gosh I hope not :) Agreed! I am trying to reduce the number of protocols. > > > So while there might be an abstract API that allows the application > > to ask, the scheme in uni-based-mcast doesn't seem to have the pieces > > so that the system can honor such a request; at least not with a > strict > > interpretation of the relationship between the RFC 2462 notion of > lifetime > > of the unicast prefix, and the presumed lifetime of the derived > multicast' > > address. > > If the app says [6 months, 6 months] then personally I would expect the > host to fail the request if it only has a unicast prefix lifetime of 1 > week. > I think your question is really: should we allow such a host to grant > a request for 6 months if it only has a unicast prefix lifetime of 1 > week? > > In my previous email, if there is a need to allow this (and I'm not > saying > there is), then we'd have to just say it SHOULD NOT, and say that after > the unicast lifetime, the multicast packets are not guaranteed to be > routed. I have no problems changin the text to SHOULD NOT. > > > Hence my question whether the intent is to have such a strict > relationship > > or not. > > I'd like to hear others opinions, but I think that is the authors' > intent. It was my intent. IF we are going to try and eliminate the multi- layered allocation architecture, there needs to be some controlling mechanism and the only one I could find was the unicast prefix in the RAs. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
