Subject: Re: [arch-d] It's the routing, people!

From: "Schliesser, Benson" <[email-masked]>
Date: Sat, 11 Nov 2006 20:40:05 -0600

I assume Geoff can correct me on this, but my gut response to the 15k number is that some visibility is probably missing. I.e. Those ASs may be multihomed, and the analysis tools just don't see the secondary path(s) to their prefixes.

Some ISPs that assign to their customers from a larger allocation enforce aggregation, which makes origin analysis less obvious. (Though this isn't often a good idea, and it's likely that researchers thought of this) More tricky, and more likely the issue with visibility, is that local policy in transit ASs may not share more specific prefixes or particular AS-paths with customers, or with peers, or however it serves their business best. ("Tier 2" providers are in some cases financially motivated to not send these prefixes to their upstreams, but to share them more freely with their peers) Any given router is unlikely to see all the paths.

In any case, 15k is a big number, too big to make me feel good by either my explanations above or the possibility of unnecessary single-homed BGP. I agree with you that we need some more analysis.

And if I haven't been obvious yet, I totally agree with you about not "pitching it all", but rather engineering (the E in IETF) a sustaining solution. Of course, I still think we need to have the broader architecture discussions, too, but its clear to me that good architecture needs to think beyond immediate issues to produce ideal results. They really are two separate topics at this point in time.

Cheers,
-Benson

-----Original Message-----
From: Fred Baker
To: Schliesser, Benson
CC: [email-masked]
Sent: Sat Nov 11 16:05:31 2006
Subject: Re: [arch-d] It's the routing, people!

On Nov 11, 2006, at 12:19 PM, Schliesser, Benson wrote:

>
> >> I don't see routing melting today.
> > I'm only here because other people seem to think
> > it's coming, and want to get
> > moving on a solution.
>
> I don't want to derail the broader architectural discussion, which  
> I think is valuable. But let me point out something directly  
> related to the engineering problem we face in the routing system:  
> Of the approx 23k ASs in the global routing system, only 3k are  
> transit ASs. The other 20k systems are basically end networks that  
> multihome.

actually, I asked Geoff about this, and he told me that ~15K AS's had  
only one upstream AS, meaning that only ~8K have more than one  
(multihome at the BGP level) and (per you) only ~3K of those have  
"many" peer and upstream AS's.

> If we can come up with a good solution to multihoming that removes  
> the need for these end networks to participate in global routing  
> etc, and change policy so that it reflects this in turn, it seems  
> to me that we can materially reduce table size and rate of growth.  
> (Geoff, it was said you spend all of your time studying this; would  
> you agree?)
>
> Yes, the way I envision this it would be far from a new  
> architecture. But if it solves the immediate problem then those of  
> us running networks can keep the network working, and this mailing  
> list can continue to function as a forum for architectural  
> discussion.  ;)

I would generally agree, and the interesting thing is that one  
doesn't really need a pitch-it-all-and-redo architecture change to  
accomplish that. It means that you either want a model in which every  
upstream assigns a part of its own prefix to each of its downstreams  
and every host on every interface has an address from each of the  
relevant ISPs (which is a characteristic of both shim6 and GSE,  
although they are implemented very differently), or that somehow a  
prefix is assigned to an agreeable set of edge networks that can use  
that prefix across multiple ISPs (which is a characteristic of Metro).

http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis  
tries to do something of an analysis of those from a technical  
perspective based on RFC 3582. Bottom line, if one does an analysis  
of the approach and can enumerate the number of prefixes in the  
backbone and comes up with a number on the order of 10^4 or 10^5, we  
have accomplished something important. The one thing we know for sure  
is that PI addressing doesn't do that.

This is why I keep asking for that analysis. I think it's important  
enough to not be hand-waved.

What I have concluded from various discussions is that the entire  
requirements set isn't on the table, though. I hear a lot about  
traffic engineering, for example, but don't see an RFC-3582-like set  
of assertions on that topic.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Geoff Huston <[email-masked]>
Date: Mon, 13 Nov 2006 04:09:27 +1100

At 01:40 PM 12/11/2006, Schliesser, Benson wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C70603.DC489A89"
>
>
>I assume Geoff can correct me on this, but my gut response to the 
>15k number is that some visibility is probably missing. I.e. Those 
>ASs may be multihomed, and the analysis tools just don't see the 
>secondary path(s) to their prefixes.

It depends on the nature of the multi-homed configuration. If the AS 
is multi-homed for transit then the alternative transit providers get 
exposed on withdrawl, in general.

If the multi-homing is actually multi-peering, then you just can't 
see this from a remote location - BGP won't expose this.

>Some ISPs that assign to their customers from a larger allocation 
>enforce aggregation, which makes origin analysis less obvious. 
>(Though this isn't often a good idea, and it's likely that 
>researchers thought of this) More tricky, and more likely the issue 
>with visibility, is that local policy in transit ASs may not share 
>more specific prefixes or particular AS-paths with customers, or 
>with peers, or however it serves their business best. ("Tier 2" 
>providers are in some cases financially motivated to not send these 
>prefixes to their upstreams, but to share them more freely with 
>their peers) Any given router is unlikely to see all the paths.

If the route propagation is constrained, then more power to these 
folk - thats what keeps the routing system in some kind of  'control' 
-  the issue is the gloibal propagation of more specifics, which is 
genrally the result of using a combination of more specifics and 
multiple upstream transits.

>In any case, 15k is a big number, too big to make me feel good by 
>either my explanations above or the possibility of unnecessary 
>single-homed BGP. I agree with you that we need some more analysis.

I suspect that an AS is sometimes something that consultants puton 
their check list. i.e. "get the client an AS number" :-)

Geoff