[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] How to Incrementally Deploy APT
Hi Bill,
Thanks for your questions. Please see our answers inline. In case it
wasn't clear, this scheme is specifically meant for APT, which is our
design for a complete map & encap scheme for improved routing
scalability. Our answers below may make more sense if you review our draft:
http://tools.ietf.org/html/draft-jen-apt
Though some things are out of date, it should be a decent overview.
William Herrin wrote:
On Thu, Feb 21, 2008 at 10:52 PM, Dan Jen <jenster@cs.ucla.edu> wrote:
We have devised a plan for incremental
deployment that we would like you to consider.
Please hit us with any comments and questions. We would love feedback
on how ridiculous or perfect you think our ideas are.
Hi Dan,
What is the smallest unit? An "APT network" of which one or more are
contained in an "APT island"?
We assume an APT network to be an entire BGP AS.
How do I go about deploying exactly one APT network into an existing
BGP AS? What new equipment do I install?
You would need to make some modification to all border routers so that
they can do encap/decap and store a cache for mapping information. We
are hoping this can be a software-only upgrade for most hardware.
Additionally, you would need at least one new device called a default
mapper. You probably want at least two, just for redundancy purposes.
The details can be found in our draft.
What do I attach the equipment to?
The border routers stay where they are, the default mappers can be
anywhere in your AS, preferably distributed in such a way as to minimize
latency from most border routers. You just need to assign an anycast
address for them, and configure the border routers to use that anycast
address.
What external information do I feed into it and how do I
get that information?
There is a service running on the default mapper(s) that will exchange
mapping information with other APT networks in your APT island. You
merely need to manually configure the peering with your neighbors'
default mappers, as you would for BGP routers. We are updating the
details here, and will send another message to the list about that soon.
What does it feed into my routing table? What do
I remove from my routing table? If you need to make assumptions about
the architecture of my existing BGP AS in order to give a concrete
answer, please do so.
Since APT is a map & encap system, you won't have any additions to your
routing table, but the default mapper(s) store the full *mapping* table,
and the border routers store a small cache of recently used mappings.
You can remove from your internal routing tables any of your customers'
PI prefixes, as well as any of the prefixes of other customer PI
prefixes in the island. Any border routers on the border of the island
will still need to keep these prefixes, however.
What benefit do I get from being the first APT network? Are there new
services I can sell to my customers? Do I save money by having
deployed apt? Why should I be the first?
Primarily, you should be able to be much more competitive in supporting
a large number of customers, regardless of whether they use PI prefixes.
You will be able to remove their prefixes from the routing tables in
most of your routers, and you will no longer need to have BGP peerings
with your customers.
What benefit do I get when my neighbor deploys an APT network and we
form an island of two APT networks? Are there new services I can sell
to my customers? Do I save money by having deployed apt?
Now, you can both remove each others' customers' prefixes from your
routing tables at all routers except at the border of the island.
A-(B-C-D)-E-F
B, C and D are APT networks in an APT island. A and E connect to the
island with classic BGP. E connects to F with classic BGP. A host in A
wants to talk to a host in F. How does that work? Is BGP in the island
carrying all of E's BGP over to A and vice versa?
Our goal with APT is to separate end sites (or edge networks) and
transit networks into different routing spaces. So, in your example, A
must be an edge network, which does not participate in (B-C-D)'s routing
space. So A's traffic enters B at an ITR, which encapsulates it with a
destination address of a border router in D, which in turn decapsulates
the traffic and forwards it to E based on its BGP tables.
Now A wants to talk to C. You've stated that BGP in the island does
not contain prefixes in the island's mapping table. How does A get C's
prefixes?
Since we are intending to separate A from the routing space of the APT
island, A CANNOT address any host in C. This is meant to be a feature.
End users should not need to talk directly to nodes in the infrastructure.
-Michael and Dan
--
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