Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt



Note: replying to a number of separate messages here...

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya at isc.org> writes:

> At Thu, 3 Jul 2008 17:07:34 -0400,
> "Wes Beebee (wbeebee)" <wbeebee at cisco.com> wrote:

> > <wb>
> > What if there are cache-inconsistency problems, prefix renumbering, or
> > stale information?  I think it's better just to get rid of caching
> > on-link information in stable storage and get such information fresh
> > from RA's.  That way, administrators can better rationalize the behavior
> > of their network from the configured RA's.
> > </wb>

> The same argument applies to caching the address, so it cannot be a
> reason why we specifically prohibit the (on-link) prefix part of this
> behavior.

Exactly.

> Actually, I see it can rather be harmful if we only prohibit the
> on-link prefix part of this behavior.

Again, I agree.

Note also, that DNA approaches essentially "cache" information about
the configuration of an interface across interfaces going up and down
-- which is very similar to the type of caching you are proposing to
disallow.

There is nothing wrong with caching information (as long as it has not
expired) so long as one replaces it if updated information comes along
later.

So I continue to be unpersuaded by any of the discussion so far that
we should saying "don't do that". 

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.