(ngtrans) Re: 6BONE AUP

[Pedro Marques]

>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:

    Perry> No. That's really unacceptable. It is fine to automate
    Perry> something like this and say "the solution is automation"
    Perry> (AFTER you demonstrate said automation), but it is *not*
    Perry> fine to say "the solution is burning human cycles". If that
    Perry> is the solution, then we'll never be able to
    Perry> renumber.

I've to confess i've always found the discussions about renumbering
"interesting"... specially since people often refuse to quantify what
should be renumbered. Since the costs of such operation depend on the
position on the topology of what you are trying to renumber that has
always sounded to me that ipv6 will do renumbering at all costs.  From
an engineering point of view, which is basically the "art" of making
tradeoffs, that sounds odd. As if we had taken "renumbering" as a
buzzword without looking at the implications.

But let's not discuss if renumbering is, or rather when it is, a good
idea.

The major implication of renumbering is that you can't consider
addresses as identifiers of the objects but instead you must have
another handle for those objects.

Thus, you must have a way to resolve objects into addresses. Which is
fine for most purposes but becomes a real problem when you think about
the infrastructure that is involved in that resolution. A router, for
instance, is typically involved in such process. As such, it's
configuration has to be already "resolved". For instance you fall into
trouble really fast if you try to resolve a router's policy in terms
of objects (dns names or what-have-you).

Assuming we agree that a router's policy should be "resolved" and specified
in terms of addresses (which i believe we do from the router
renumbering efforts i'm aware off) there are basically two ways to go
about solving the resolution problem.

1) Notify all the dependents of an object->address mapping of any
changes in such mapping.

2) Express the router's policy in terms of objects off-line and
periodicly resolve the mappings and feed the resolved policies to the
router.

My humble opinion is that 1 is basically an untractable problem (and
curriously the aproach that has been given more consideration so
far). Number 2 is basically the aproach used by a reasonably large
network this days... but it is an aproach that is fairly limitative if
carried all the way and that requires quite a shift in paradigm.

regards,
  Pedro.

btw: just in case you need to be reminded, the opinions expressed
above reflect my own personal opinions only and not those of my
current employer.