Re: [RRG] Thoughts on the RRG/Routing Space Problem

[Scott Brim <swb@employees.org>]

Excerpts from Russ White on Mon, Dec 03, 2007 06:56:18PM -0500:
> > I disagree; transit and leaf are fundamentally mutually exclusive.
> > Either your AS provides transit to the DFZ for another AS or it
> > doesn't.
> 
> So, your definition is that as long as you transit anything, you are
> a transit AS. If you do not, you are a leaf. It doesn't matter if
> you originate traffic, or you sink traffic, the only thing that
> matters is that you transit traffic.
> 
> In this case, I posit this is a distinction without a difference.
> All AS' should be assumed to be transit in all cases.

Different aspects matter in different contexts.  For IP routing, I
believe the main question is whether you are DFZ or not.  

> > No.  The mapping table may get disturbingly large, but the locator
> > table (i.e. DFZ) shouldn't grow in proportion.
> 
> As long as you assume that the transit AS never has any reason to
> engineer traffic towards the various actual destinations reachable
> through a given locator, or that the peering AS never wants to split
> their locator space into multiple pieces to accomplish TE.
> 
> IMHO, the end result will be that the locator space will be split to
> the same degree the current routing table is, over time, and hence,
> the locator table will be the same size, in the end, as the current
> routing table--because:
> 
> 1. The cost of adding another locator to provide traffic engineering
> is low (to the person injecting it into the table).
> 
> 2. Splitting locator blocks into smaller pieces to control inbound
> traffic flow into your network adds value.
> 
> So, the value proposition is the same as with the current routing
> table--you incur little cost, and you do gain something, by making
> the locator table larger. If the value proposition is the same, the
> result will be the same, IMHO.

First, what locator table?  

In case you mean routing of globally routed addresses in the DFZ, in a
map&encaps scheme the routing information will only grow based on the
number of DFZ ASs and their policies on routing within the DFZ,
because RLOCs are assigned by upstream providers, and will aggregate.
Addresses of ETRs are just addresses in their upstream providers.  In
DFZ routing, policies can only be applied to the upstream providers,
not to things outside the global DFZ.  Policies on non-routed sites
will be applied in the mapping function (data plane and control
plane).

When you say "locator table" I think you mean the locally routed
"EIDs", and thus an EIDprefix->GlobalLocator mapping table (or
database).  In that case, let's not forget that some approaches don't
have anything resembling a mapping table or database, but are
completely distributed.  For them there is no problem of mapping table
size.  

Then there's the cache of prefix maps in an ITR.  There would be a
problem for an ITR that wanted to send traffic to every prefix,
because it would have to cache many prefix mappings.  There are a
number of deployment heuristics we can both think of to avoid that
problem.

> > For instance, if I (as a leaf AS) have five ISPs, there will be
> > exactly five routes to my five locators -- the aggregates from
> > those ISPs.  However, I could have potentially thousands of EIDs,
> > each mapped individually to a random selection of those locators
> > in a way that couldn't be aggregated.
> 
> There will a route per destination you want to steer traffic to, not
> 5.  You could assume 5 if you could assume the mapping system
> converged instantly, and if you could assume the transit upstream
> did not want to steer traffic to specific entry points based on the
> exit point from their network. I don't think these two are true,
> myself--the mapping system's convergence speed will not be
> instantaneous, and traffic engineering, will, in the end, trump the
> clean mapping implied.

I don't understand this.  I thought the question is how much routing
information there will be in the global routing DFZ.  Behavior there
will be like BGP today.  In map&encap, traffic from ITR to ETR will
follow paths that BGP hunts out, just like today.  Yes, destination
sites will want to steer traffic to specific exit points (ETRs), and
they will do so in the mapping function.  Every ingress point (ITR)
might be asked to send traffic to a different exit point.  DFZ routing
won't care.  It will just carry routes to the ISPs that provide those
exit points.  

> Further, I think mobility throws another wrench into the works that
> hasn't been addressed.

In map&encap, if you implement the optimized routing ideas in MIPv6,
then every time a mobile node moves to a site it has never been in
before, there is a *chance* that several mapping lookups may be
necessary.  This is true of any approach that restricts the scope of
end site prefix routing.  However, 

  - Routing and addressing are more fundamental than mobility.
    Mobility can adapt to R&A but not vice versa.  R&A need to take
    mobility into account as a general issue, but we have always lost
    when we tuned fundamental designs to specific mechanisms that ran
    over them, and we have always won by producing general purpose,
    flexible designs.  So we should take mobility into account but
    clean elegance in routing and addressing is of primary importance.  

  - In the real world mobile users are rather provider-aggregated, and
    even if we use the currently conceived route optimization
    mechanisms, the need for new map lookups will be less than one
    would think.

  - Route optimization has not, or hardly, been deployed in MIPv4 or
    MIPv6.  It is a theoretical requirement that I applaud, but it is
    not a hard requirement that we support it.

So MIP will be interesting, but not a hard obstacle.  We put a little
text in the last draft-farinacci-lisp draft about it.  Once we have a
better idea of where we are going in RRG, we can do a full draft about
interactions with mobility.

> We're assuming:
> 
> 1. A large mapping table is easier to deal with. Well, it is for the
> routing system, because the tables are outside the routing system.
> :-)

Do you mean that it's hard for ITRs?  If so, see above.

> IMHO, there are drivers which will push the locator table size
> larger, at least to the same size as the current table. IMHO, we are
> also going to wind up, as the meshiness increases, with a much
> larger set of the attached networks acting as transits.

Just because an ISP is multiply-connected doesn't mean it's a transit.

See you ... Scott (in SIDR)

--
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