[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 4599) Re:  BGP and renumbering
From:       Pedro Marques <roque () cisco ! com>
Date:       1997-09-30 19:58:30
[Download RAW message or body]

>>>>> "Matt" == Matt Crawford <crawdad@fnal.gov> writes:

    >> Renumbering the routers is a cinche by comparison to
    >> renumbering the customers served by an ISP (who in most cases
    >> simply refuse).
    >> 
    >> What I'm getting at is that IPv6 needs to solve the end system
    >> problems and don't worry so much about renumbering the
    >> intrastructure because that's not where the problem is.
    >> 
    >> Curtis

    Matt> I believe that the IPNG WG collectively feel that we have
    Matt> that one pretty much licked.

>From the Munich meeting i'd the impression that we still don't know
how to solve the problem of renumbering hosts.

If i remember correctly Erik Nordmark's site-prefixes draft wasn't fully
discussed in the meeting due to lack of time and some of the issues it
raises didn't seam close to be settled. But regardless of the actual
solution, one thing the draft clearly points out is that simply
being able to dynamic learn and reconfigure the addresses that an host
is using is not enought.

Also, talking about renumbering in the IPv6 context is a difficult problem
since everybody seams to have it's own definition of what renumbering means.
It would be nice if the IPng WG could agree on a definition. One could
probably obtain a clear one by answering the questions: "what renumbers ?",
"how often ?" and "why ?".

Maybe it would be useful if we actually step back for a bit and try to
list the problems we must solve in term of address visibility (i.e. what
causes the routing table explosion problem).

Assume for a while that the following list is the smallest list that covers
the problems that really must be solved:
1) Leaf site changing providers.
2) Multihoming of leaf sites.

If we look at multihoming, the requirements are ability to do load-balancing
and fallback. I would argue that this really has nothing to do with
renumbering. Fallback can be accomplished by either injecting the failing
prefix temporarily via the working paths or by changing the addresses in
use by the connection, which are pretty different cenarios from renumbering
a site.

So from the list above, and eliminating multihoming from the problems
renumbering must solve we end up with a pretty simple definition of
renumbering: readdressing of leaf sites when they change provider.
Which is tipically an infrequent operation and can accomodate grace
periods of weeks.

There are several conclusion we can take from this hypothesis:
. Renumbeing eBGP connections is not a problem since changing the eBGP
peering is the reason for renumbering in the first place.
. Operations like off-line resigning all DNS records for a site are
pretty acceptable.
. The focus should pretty much be on being able to perform the real
problem at hands...

Of course none of the above holds if the list of problems to solve is
really much different from what i enumerated but i do believe people
should think twice before adding things to that list. Needless to say
that trying to solve world hunger is not always productive.

    Matt>   Deployment experience will
    Matt> prove it, or will shatter the illusion.

Indeed.

  Pedro.
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]