Re: [RRG] Consensus? End-user networks need their own portable address space

[Robin Whittle <rw@firstpr.com.au>]

Short version:     There are two kinds of PI space:

                     Today's BGP-managed PI space.
                     Scalable map-encap-managed PI space.

                   Any solution for IPv4 or IPv6 must implement
                   the requirement for easy change of providers
                   by providing PI space - no other approach
                   meets the needs of any end-user network with
                   servers.  Only the map-encap type of PI space
                   can be provided in a scalable fashion.

Scott Brim wrote:

> PI is a solution, not a requirement.  The requirements are easy
> multihoming and easy connectivity change.

As I argued at the start of this thread, for any practical IPv4 or
IPv6 solution in the foreseeable future, the only way a substantial
end-user network can change providers is to keep its public address
space when it moves.  There are far too many places where IP
addresses turn up in config files, DNS zone files etc. for a change
to these to be done securely and reliably.

Recent messages from Bill Herrin (which were supported in general by
Eliot Lear) highlight two other instances of IP addresses being
beyond the reach of any secure, robust, automatic update system: VPN
client config files and the historic reputations of mail servers as
used by spam detection software the world over.

Tony wrote to Bill:

> | We're well past the point where "PI for servers" should be
> | considered an architectural requirement until proven otherwise.
>
> Again, isn't PI a point solution?  While PA today is not currently
> acceptable, your claim, if true, negates just about every solution
> presented here.  I'm not prepared to accept it as axiomatic.

Bill's use of "PI", included a scalable new kind of PI space
available via map-encap (and perhaps other approaches), so I think
it is wrong to state that "PI for servers" isn't supported by
current proposals.


Currently there is only one way of providing Provider Independent
address space: advertise the prefix in BGP.  This leads directly to
the routing scaling problem we need to solve.

The map-encap systems provide a new kind of PI space.  It is just as
provider independent as the current kind, as long as the providers
have ETRs.

If there was only one map-encap end-user network prefix in every BGP
advertisement, then this new kind of space would have no scaling
benefits.

The explicit plan for Ivip is for a large prefix to be advertised in
 BGP and for this to contain many Ivip-mapped prefixes which
collectively serve the needs of many end-user networks - tens,
hundreds or perhaps tens of thousands.

LISP could clearly be used the same way, since for backwards
compatibility with networks without ITRs - to enable Proxy Tunnel
Routers to work - there needs to be a BGP advertisement of an
encompasing prefix for one or more enclosed EID prefixes.  I think
LISP can and should be used exactly as I described for Ivip: in
general, use it so that the advertised prefix contains many (tens,
hundreds, thousands etc.) of EID prefixes.

So both Ivip and LISP are perfectly capable of providing the new
kind of PI space in a highly scalable fashion.

I think the same is true of APT and TRRP.


 - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg