> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Friday, December 15, 2000 7:43 PM
> To: abha ahuja
> Cc: irtf-rr@nether.net; irtf-rr@puck.nether.net
> Subject: Re: Wither irtf-rr
>
> We're looking at the growth in routes, which is now roughly at the same
> rate it was in 1993 prior to the deployment of CIDR. We believe that this
> is primarily related to multihoming,
It's also interesting to consider growth of the number of
inconsistent routes. Improper multihoming is partly
responsible for it.
> and may be amenable to adjustment
> using policies. Geoff Huston has suggested that we put a TTL on routes
> advertised - when transit contracts are in place, maybe I want my
immediate
> neighbor to get a certain /28 route, but there is no need to send it
beyond
> him although other routes will go beyond him.
TTL=1 exists today. The idea of global communities that would be
required for TTL>1 has been opposed not once by providers who seem
to be reluctant to allow for route manipulations in their backbones
by remote ASs with whom they don't have peering relationship. I
remember this being discussed in a little bit different context,
though, -- controlling incoming traffic at the remote points.
> Attacking the same problem, I
> suggested another approach - if my route to you and my route to your left
> nostril have the same next hop, I don't need to store the fact in my FIB,
> nor advertise it beyond me.
I thought about the same idea before and I came up with the following
observations:
1) You don't really do anything for PI blocks. "Extraneous" PI routes
are handled in basically the same way by the default BGP behavior.
2) (A tendency to) the almost full mesh of ASs. You probably had this
picture in mind:
-----
| AS5 |
-----
|
|
-----
----------| AS4 |-----------
/ ----- \
/ \
/ \
-------------- --------------
| AS Mesh 1 | | AS Mesh 2 |
|not connected | |not connected |
| to AS Mesh 2 | | to AS Mesh 1 |
| (maybe NULL) | | (maybe NULL) |
-------------- --------------
| |
| |
----- -----
| AS2 | | AS3 |
----- -----
| |
| |
------------------------------------------
| Multihomed AS1 |
------------------------------------------
Suppose AS2 uses Pref2 and AS1 uses a PA block Pref2.1
from the Pref2 address space; AS3 advertises Pref2.1 above.
Then the ASs that would benefit from the idea
are AS5 and "beyond", since AS5 has both Pref2
and Pref2.1 with the same next hop in AS4.
However, let's consider more realistic picture:
----- -----
| AS4 |---| AS5 |
----- -----
| \ / |
| X |
| / \ |
----- -----
| AS2 |---| AS3 |
----- -----
| |
| |
----------------
| Multihomed AS1 |
----------------
In this picture, there may be no AS that would benefit from
the idea since in any AS, the next hops for Pref2 and Pref2.1
may be different. And clearly, "beyond"s benefiting from
the technique are only those legs of high tier providers
having the single topology path to the "core".
The general observation would be that the Internet
infrastructure tends to be less and less hierarchical
and we need to face this part of reality at some point.
> >>That said, the growth in IP routes is pretty bad, and I suspect that
> >>there are some pretty simple things we can do to limit that. Many of the
> >>routes are multihomed /24 and smaller prefixes being punched through
> >>alternate carriers. Many times, I suspect, the result of the route
> >>calculation is that a /31 or a /24 has the same next hop as some larger
> >>aggregate. Whenever that is true, I will argue that we have no strong
> >>reason to set up a separate MPLS tunnel for it, to store the route in
our
> >>own FIB, or pass the route to anyone else. I'd love to see a simple
> >>"simplify routes" mode that tells BGP to look for such cases and not
pass
> >>them along when they apply. There are some issues there, such as the
fact
> >>that if we literally did that, the network that the smaller prefix was
> >>out of might not advertise the prefix on. We can overcome that, I think.
This particular issue is easy to solve, I think, by not doing "simplify
routes" if the shorter prefix has the NULL AS_PATH.
> >I believe that our experience with DUAL would help us to implement it in
> >some variation of BGP, which would improve convergence. The latter is
also
> >interesting; from a NIMROD perspective, if I replaced the word "router"
> >with "addressable entity, which might be a router or any set of routers,
> >including one or more AS's", I might be able to build that towards some
of
> >the concepts from NIMROD. There might be value in that direction.
The major problem with DUAL was scalability (rapidly growing
number of SIAs for large networks, etc.). Even active usage of
summarization did not always help. Hence, I agree, some aggressively
hierarchical model (like NIMROD) is required if you want to use
DUAL for IDR. But see my observation above...
Anyway, it's still interesting and I'd like to repeat Avri's question
about if this study has already begun and if there are any results.
> >>Specific to MPLS, I have no problem with
> >>using MPLS for what it brings to the party - the ability to enumerate
> >>routes, which perhaps then means the ability to traffic engineer them or
> >>build VPNs out of them - but I have a real problem with making the
> >>Internet depend on them. They might make sense for optical networks, for
> >>which a lambda has a lot of the same characteristics as an MPLS path.
But
> >>I see them as frosting, something added on to the fundamentals, not as
> >>themselves fundamental.
A very rare point of view in these days. It looks like it's almost
indecent to say something like that today :)
I asked the same question ("if really nothing else left to `fix some
routing probelms` except MPLS") on the MPLS mailing list a couple of
times but this was a wrong place to ask. However, the arguments (basically
of this sort -- "if it's cheaper and easier to provide a tool for, say,
TE using MPLS, why do we need to think about anything else?") were strong.
> >>And then there is traffic engineering. We do what we do with MPLS in
> >>order to achieve that. But I do find myself wondering if there is
> >>something we could do that would improve matters in IP. For example,
> >>while I understand the oscillation that happened in BBN SPF twenty years
> >>ago, I'm not sure the experience is as relevant as we think.
Moreover, there were attempts to fix things there. These attempts were
described, for example, in
http://www.acm.org/pubs/citations/proceedings/comm/75246/p45-khanna/.
But this theme is much less popular, as far as I can see.
> >>We have shied away from anything time-based or load-based as
oscillatory. I
> >>wonder whether the influx of bandwidth affects that at all. Suppose, for
> >>example, that route metrics told me the mean drop rate per kilobit
> >>transferred, with a minimum value of ping round trip delay of the line?
> >>what I wind up with by default is the network path with the shortest
RTT,
> >>and when the line starts dropping, we start spreading load. Suppose that
> >>BGP had a "round trip to target" attribute, and which contained either
> >>the mean traceroute delay to the network or the sum of the TCP RTTs of
> >>the BGP sessions going to the network, and that we had a verb that said
> >>"when presented with two or more potential routing paths, take the path
> >>with the shortest cumulative delay"?
Supposes one of those TCP RTTs changes, do you send any updates?
(It's just one of too many questions.)
There too many issues on this way. The most complete (for
market use) result that I know of and that addresses most
of them is OMP. And even it experienced "a lack of interest
and implementation".
> >>Several of these can be handled within the existing routing protocols,
> >>and would be options that might be worth exploring. Improving BGP
> >>convergence, I think, requires an improved protocol. There, I would
argue
> >>for the algorithms used in EIGRP, which are designed to improve
> >>convergence in a distance vector protocol. Suppose we used something
very
> >>EIGRP-ish - in a standard protocol - as a way to distribute routing
> >>information (nodes on the tree being AS's rather than routers, at least
> >>in non-IBGP cases), but basically distributing BGP routing information?
I
> >>think we could pretty readily make the case that convergence improves.
> >>
> >>Just a start. Maybe you have some notions.
I have a notion of the following nature. I'm surprised that we don't see
research of a new routing protocol that would be based on a dynamic network
model (the stochastic control theory seems to be the best candidate).
It's kind of insane, in my opinion, to expect any adequate results from
a routing protocol governing behavior of a dynamic system (network)
and derived from the static theory (like the graph theory) or, more
generally, from the static network model.
The more I think about it, the more it becomes obvious to me that a lot of
major problems in routing today (at least three from your list, BTW:
>> convergence time
>> quality of routes
>> traffic engineering
) would have just no place to exist if such a routing protocol
is constructed...
-- dima.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT