[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Keith Moore <moore@cs.utk.edu>
cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Robert Elz <kre@munnari.OZ.AU>
Date: Thu, 09 Aug 2001 00:56:50 +0700
In-Reply-To: <200108081709.NAA14777@astro.cs.utk.edu>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

    Date:        Wed, 08 Aug 2001 13:09:38 -0400
    From:        Keith Moore <moore@cs.utk.edu>
    Message-ID:  <200108081709.NAA14777@astro.cs.utk.edu>

  | DNS cannot tell you that old addresses are no longer valid, it can only
  | tell you that some addresses should be valid.  The absence of some address 
  | in a list of A (or AAAA or A6) records is not an indication that the 
  | address is not valid.

I'm not sure I agree with that.   The RRset should be the complete
list of addresses that belong to a name (which isn't necessarily the
complete set that belong to the node that owns the name of course).

If an address isn't in the RRset, then it doesn't belong to the name,
by definition, and hence, is invalid as a translation of the name.
Whether that address still happens to reach the entity that it reached
yesterday, when it was a valid translation of the name is a different
question.

  | any system for renumbering (including the one you are proposing)
  | will require changes to existing protocols.  the question is, 
  | where is the best place to make these changes?    my guess is, 
  | some combination of ND/RD and ICMP.

I'm not sure it is possible.   Sure, a node could respond with some
kind of message to a peer that sends a packet to an address that the
node is in the process of deprecating - but that doesn't help at all
for all the other peers that don't happen to send any traffic during
the deprecation period.

  | which apps are affected depends on the frequency of renumbering and the
  | overlap during which multiple addresses are valid.

The overlap period, yes, the frequency, no, not really.   I can renumber
7 times in a day, and as long as the first (and rest) of those addresses
remain valid long enough, then all is OK.

  | we really need for these to be explicitly chosen design parameters.

That means then the overlap period.

Unfortunately, I suspect that's not possible.

  | my feeling is that the mean time between renumbering should be no worse 
  | than the mean time between shutdown of reasonable hosts for other reasons,
  | which is to say, several months.  that way, renumbering doesn't 
  | significantly affect application reliability.

And unfortunately you're trying to equate two measures that are likely
moving in opposite directions.  Hosts (and OS's) are becoming more
stable, and remaining running between shutdowns far longer than used to
be possible (I recall the days when computers were turned off each night
when people went home...)

And renumbering is likely to become more necessary, hence more frequent,
as the net gets bigger, and the routing problems get worse (assuming no
revolutionary solution of course).

But in any case, it isn't host uptime that counts, but application connection
time - what you would like is for addresses to remain valid (after ceasing to
be preferred) for at least as long as the average app connection is likely
to remain.

It would be nice to aim for that where possible, but circumstances being
what they are, mandating it would just make us look foolish.

kre


Home | Date list | Subject list