Subject: RE: zmaap suggestion: eliminate lease times

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 23 Mar 2001 10:17:51 -0800

We did a multicast channel allocation thing for IP/1394 (RFC 2734) called
MCAP. It is claim and defend, does not have a lease time, but does have a
count down timer so all hosts know when the current allocation expires.

-myron

> -----Original Message-----
> From: Daniel Senie [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 8:18 AM
> To: [email-masked]
> Subject: Re: zmaap suggestion: eliminate lease times
> 
> 
> Erik Guttman Sun Frankfurt Staff Engineer wrote:
> > 
> > In draft-ietf-zeroconf-zmaap-00.txt any mini-MAAS can
> > reallocate or deallocate an address just by multicasting
> > an AIU with the same ID and a different time.
> > 
> > One concern brought up at the WG meeting was that this
> > could very easily cause bad interactions among mini-MAASs
> > (one wants a lifetime of X, the other of Y, so they go
> > back and forth on it in a shouting match).
> > 
> > Stuart and I were discussing this in the hallway after
> > the WG meeting and he made what I think is a great
> > suggestion:  Why have lease times at all?   An allocation
> > could be considered to exist only as long as some mini-MAAS
> > is willing to defend it (like the allocator and any mini-MAAS
> > which has had an application register interest in the allocation).
> > 
> > Implications:
> > 
> >  1. No shouting matches would occur
> >  2. There would be no notion of deallocation
> >  3. Soft state caching of AIUs would be hard to do
> >     without lease times, but this isn't needed for
> >     correct operation.
> >  4. The protocol would be a lot simpler.
> > 
> > Thoughts?
> 
> This sounds good.
> 
> I was concerned also about deallocation from another perspective, that
> being a host which allocated and was using an address, and 
> then crashed
> without deallocation. That added messiness in trying to reclaim
> addresses which had been lost into such limbo. The approach outlined
> above removes that concern.
> 
> Dan
> 
> -- 
> -----------------------------------------------------------------
> Daniel Senie                                        [email-masked]
> Amaranth Networks Inc.                    http://www.amaranth.com
> 
>