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

[Scott Brim <swb@employees.org>]

Excerpts from Russ White on Tue, Dec 04, 2007 06:21:44PM -0500:
> I *believe* the number of default only AS' is going to reduce in
> size over time, for various reasons.... Hence, my basic thinking
> that all AS' should be treated as transit, or rather, any solution
> should be designed with a zero size "default only" zone, if you
> will.

I don't understand why you would think that.  If that were the case,
why hasn't it happened already?  Specifically what do you think is
about to change?

> > First, what locator table?  
> 
> The "global routing table."

OK.  Then ... 

> There's a strong incentive to advertise finer grained locator
> information, to control the flow of traffic through the transit AS. 

Could you explain why that would happen?  What strong incentive (not
just a generalization) is there that would override the incentives not
to do so, and why hasn't it already done so?

> Caches, IMHO, will not work. Caching information is based on
> specific traffic patterns that are going to probably change,
> dramatically, in the near future--it's never good to presume
> existing traffic patterns are permanent, and we can thus build an
> architecture based on those existing traffic patterns. Second, any
> form of reactive routing, which is what caches, in the end,
> represent, is going to have unacceptable side effects in terms of
> traffic delays, technical difficulties, etc.

Why do you think anyone was talking about caching based on current
behavior?

When you say caching "represents" "reactive routing", I suspect you
are talking about the balancing act between delay, packet drops,
security and FIB size.  There is a lot of text about this in the
drafts and on the mailing list.  We don't know where the balance point
will come out, so what we are trying to do is to build in the
flexibility so that we *can* move network behavior to a better balance
point as the Internet evolves.  One possibility is to have no delay
(and thus no "reactive routing") in map lookup at all.

Given that, when you assert that any reactive routing is unacceptable,
what do you propose?

> There are two tables, and the question is--how much state*churn will
> we have in both of those tables? IMHO, the state*churn in the DFZ
> routing table, the "locator" table, will be similar to what's there
> today, if not possibly worse. 

You understand that all that will be in DFZ routing will be the DFZ
networks themselves, a relatively small number, is this because you
think they will advertise long prefixes to each other?  If so, see
above.  If not, please explain.

> The state in the "mapping" table will be unbounded, probably many
> times larger than the current table size.

I believe so too, although not unbounded.  However, there is not
necessarily a "table" at all.  Mapping information may not be
completely collected anywhere (except where people want to for
analysis).  There can be -- that's part of the flexibility discussed
above.

> > 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.  
> 
> This assumes that the end destination traffic can always be treated
> as a single class, or a single monolithic block of traffic--or
> rather, all destinations within a given "leaf" AS can always be
> treated as a single destination. IMHO, this is not a good
> assumption, as shown by current trends.

Are you saying there will be TE within the DFZ?  Sure.  I included
that in "routes" -- we have that today.  

Please don't tell me what I'm assuming.  If you think I might be, ask
me.

> In the same way, this also assumes that all the locators within a
> given transit AS can always be treated as a single destination from
> outside that AS. Again, IMHO, this is not a good assumption.

No it doesn't.  Ask me if you think I'm saying something wrong -- it
may be that your assumptions are off.

> >   - Routing and addressing are more fundamental than mobility.
> >     Mobility can adapt to R&A but not vice versa.
> 
> In other words, mobility is a secondary requirement for IP
> transport.  Either it is a small part of the traffic, and will not
> grow, so there is no need to address it (?).... Or, it's not a
> problem that needs to be addressed through routing, it should be
> handled elsewhere. IE, IP == POTS.

I didn't say that.  You are inserting your agenda and cloaking it in
the guise of paraphrasing me.  Stop doing that.  It's no way to reach
an agreement.  Look again at the rest of what I said, about the
importance of mobility, and try again.  Maybe you could even
contribute a suggestion of how to solve the problems you think you
see.

> >   - 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.
> 
> Today. Again, I believe it's wrong to base an architecture on
> today's traffic patterns. Part of the job of the IETF isn't to solve
> today's problems, it's to solve tomorrow's problems in a way that
> doesn't impact today's services.

Nope.  This is not about network technology, it's about human behavior
and business behavior, regardless of underlying technology.  I can dig
out the studies but it will take a few days.  In the meantime, if you
have a proposal for an architecture to reach our goals ...

     1. Improved routing scalability                                                           
     2. Scalable support for traffic engineering                                               
     3. Scalable support for multi-homing                                                      
     4. Scalable support for mobility                                                          
     5. Simplified renumbering                                                                 
     6. Decoupling location and identification
     7. First-class elements                                                                   
     8. Routing quality                                                                        
     9. Routing security                                                                       
    10. Deployability    

... let us know.

swb

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