Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Avi" == Avi Freedman <freedman@netaxs.com> writes:

Avi> What's the smallest CIDR block Sprint will listen
Avi> to from an external source in the
Avi> 207.x.x.x-208.x.x.x range? Is it different than
Avi> the filters on > /19s in 206.x.x.x-207.x.x.x
Avi> range?

- From non-customer BGP peerings we listen to /19s in 206/8.

We listen to /18s in 207/8 to the top of the IPv4 unicast space.

The nanog email archive should have lots more detail for you.

Sean.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey

iQCVAwUBMM5g4kSWYarrFs6xAQH5/gQAo+8wnZB6X2GVx4ow9ISd/cMsw+2OOYuB
NWIo/G6zms7g5GtCabGtlwy8w8xaQnjEI4EIgfBnwm1jyu+QNXNpLkjAfreUt36H
NAuNp2y++wzTvTuD8fgyqropx0TlOAP4Z3fV69tNKvqyqkqUcCazN7YyRK4tq+el
Ry3KTeVgGgc=
=xM6+
-----END PGP SIGNATURE-----

MCI aggregates all its customer's routes into /19's. We have just
received our first block of address space from the 207.x.x.x range. If
you continue to filter at /18's for the 207.x.x.x range, you won't be
able to reach all of MCI's customers.

Needless to say MCI would appreciate it if you'd change your policy to be
/19's, and I'm sure Sprint's customers would appreciate it as well.

Regards, Daniel


---------------------------------------------------------------
| Daniel M. Barton Internet: dmbarton@mci.net |
| MCI Internet Services World Wide Web: |
| Cary, North Carolina, USA http://infopage.mci.net |
---------------------------------------------------------------

On Wed, 13 Dec 1995, Sean Doran wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> >>>>> "Avi" == Avi Freedman <freedman@netaxs.com> writes:
>
> Avi> What's the smallest CIDR block Sprint will listen
> Avi> to from an external source in the
> Avi> 207.x.x.x-208.x.x.x range? Is it different than
> Avi> the filters on > /19s in 206.x.x.x-207.x.x.x
> Avi> range?
>
> - From non-customer BGP peerings we listen to /19s in 206/8.
>
> We listen to /18s in 207/8 to the top of the IPv4 unicast space.
>
> The nanog email archive should have lots more detail for you.
>
> Sean.
>

Daniel Barton writes:

MCI aggregates all its customer's routes into /19's. We have just
received our first block of address space from the 207.x.x.x range. If
you continue to filter at /18's for the 207.x.x.x range, you won't be
able to reach all of MCI's customers.

Needless to say MCI would appreciate it if you'd change your policy to be
/19's, and I'm sure Sprint's customers would appreciate it as well.
==========
Aside from what Daniel says about Sprint and MCI's routing policy
mismatch, this statement is interesting on another level. For Dan says:
MCI aggregates all its customer's routes into /19's. This is new is it
not? Also it says *MCI* does the aggregating and not the customer.
Would someone please explain how this differs from what I understand to
be Sprints policy which says (i believe) that it is the CUSTOMER's
responsibility to aggregate the routes they present to sprint???

Why would MCI do the aggregating? Is such mci policy good for mci or
good for the customer or equally good for both?

********************************************************************
Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85
The COOK Report on Internet Individ. hard copy $150
431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200
(609) 882-2572 Corporate $350
Internet: cook@cookreport.com Corporate Site Lic. $650
Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages
********************************************************************

> Aside from what Daniel says about Sprint and MCI's routing policy
> mismatch, this statement is interesting on another level. For Dan says:
> MCI aggregates all its customer's routes into /19's. This is new is it
> not? Also it says *MCI* does the aggregating and not the customer.
> Would someone please explain how this differs from what I understand to
> be Sprints policy which says (i believe) that it is the CUSTOMER's
> responsibility to aggregate the routes they present to sprint???
>
> Why would MCI do the aggregating? Is such mci policy good for mci or
> good for the customer or equally good for both?

If one gets a /19 and redistributes it to 8 new ISP customers, it is
your responsibility to make sure that you only redistribute that /19 -
and not any more specifics. If you *know* what those /19s, /18s, ...
are, you can put specific aggregate statements into the peering routers.

It's trickier when you have some contiguous space (customer X announces
a /23 to you and customer Y announces a /23 - and the two /23s can be
merged into a /22) that comes from customer's space allocations. You
have to detect that aggregation is possible and then statically insert
it - and check that it won't break anything (i.e. that customer X doesn't
need only the /23 announced because he wants it to override a larger /22).

But certainly when you are directly allocated address space, you have
a responsibility to aggregate announcements from your customers who are
in that space yourself.

It doesn't hurt the customer, since the space is administratively yours -
if they want to multi-home, their other provider (who obviously does not
own the same /19 or /18 or ...) will announce the more specific /22 route
and things will be fine for that customer (except that if it's newer
address space, Sprintlink customers won't see the second provider's path
to that /22 unless the second provider *is* Sprintlink).

Avi

> Aside from what Daniel says about Sprint and MCI's routing policy
> mismatch, this statement is interesting on another level. For Dan says:
> MCI aggregates all its customer's routes into /19's. This is new is it
> not? Also it says *MCI* does the aggregating and not the customer.
> Would someone please explain how this differs from what I understand to
> be Sprints policy which says (i believe) that it is the CUSTOMER's
> responsibility to aggregate the routes they present to sprint???

The difference is that MCI refers to addresses assigned out of their
CIDR block. They are saying that they are aggregating nets on a /19
basis- one might assume on a per pop basis, or something similar.


> Why would MCI do the aggregating? Is such mci policy good for mci or
> good for the customer or equally good for both?

They are not referring to proxy aggregation of PI address space. That
is another religious war altogether. This is good policy, in that
they are aggregating. They are most likely prevented from aggregating
their announcements further to their peers in the interests of maintaining
better routing policy to the individual nets- for example, say part of the space was in new york, and another was in dallas. If they only announced
the aggregated /16 to their peers, their peers would pass off traffic to the
closest announcement of the aggregate, as opposed to passing the net off
to the closest place to the destination.

'Course, I remember that some poeple are shortest exit to MCI anyway-
but that may have changed.

_k

Gordon,

There are lots of reasons a provider might aggregate networks for their
customers. One is that many customers are not able to run routing protocols
that do aggregation (customers that are not running routing protocols and
use a static default is one example). In fact, in this case Sprint ought
be doing aggregation for such customers (and I am sure they are).

In any case, MCI's policy is not unique. Many providers do this.






--
Stan | Academ Consulting Services |internet: sob@academ.com
Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

I think this is misleading. MCI does announce routes smaller than this
for its customers.

> MCI aggregates all its customer's routes into /19's. We have just

> MCI aggregates all its customer's routes into /19's. We have just
> received our first block of address space from the 207.x.x.x range. If
> you continue to filter at /18's for the 207.x.x.x range, you won't be
> able to reach all of MCI's customers.
>
> Needless to say MCI would appreciate it if you'd change your policy to be
> /19's, and I'm sure Sprint's customers would appreciate it as well.
> ==========
> Aside from what Daniel says about Sprint and MCI's routing policy
> mismatch, this statement is interesting on another level. For Dan says:
> MCI aggregates all its customer's routes into /19's. This is new is it
> not? Also it says *MCI* does the aggregating and not the customer.

That may hold true internally, however, I suspect that externally, they
announce only /16's or /15's. Of course, I could be wrong.

What I see right now, is only one announcement from the 207 block...a /19
coming from netaxs, and then some customer of PSI is announcing 5 or so
/24's in the 208 block!

> Would someone please explain how this differs from what I understand to
> be Sprints policy which says (i believe) that it is the CUSTOMER's
> responsibility to aggregate the routes they present to sprint???

Sprint already proxy-aggregates for many of their customers. Most of them
probably don't realize it. It doesn't even affect most of them.

> Why would MCI do the aggregating? Is such mci policy good for mci or
> good for the customer or equally good for both?

Depends on the situation as to whether it's detrimental. Proxy-aggregation,
as this is called, can alter traffic patterns in dual-homed situations. The
change is not always bad, though it is often un-desirable.

In general, proxy-aggregation is good for everybody.

Dave

--
Dave Siegel President, RTD Systems & Networking, Inc.
(520)623-9663 Network Engineer -- Regional/National NSPs (Cisco)
dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP,
http://www.rtd.com/~dsiegel/ for an ISP."

> Depends on the situation as to whether it's detrimental. Proxy-aggregation,
> as this is called, can alter traffic patterns in dual-homed situations. The
> change is not always bad, though it is often un-desirable.
>
> In general, proxy-aggregation is good for everybody.

If we had a good method for people to indicate routes that they didn't want to
be aggregated, then more proxy aggregation could be done safely.

>
> > Depends on the situation as to whether it's detrimental. Proxy-aggregation,
> > as this is called, can alter traffic patterns in dual-homed situations. The
> > change is not always bad, though it is often un-desirable.
> >
> > In general, proxy-aggregation is good for everybody.
>
> If we had a good method for people to indicate routes that they didn't want to
> be aggregated, then more proxy aggregation could be done safely.
>

If I may... The idea of using a routing registry for
this purpose has been suggested before. I still think
it is a valid approach. Could be very useful in assisting
with better proxy aggregation for all.

--bill

> What I see right now, is only one announcement from the 207 block...a /19
> coming from netaxs, and then some customer of PSI is announcing 5 or so
> /24's in the 208 block!

Yeah, I see those /24s in 208/8 also.

I posted to nanog a few weeks ago about it and was surprised to see those
routes (still) there this morning. 208.0.1, 208.0.4, 208.0.5, 208.0.9 coming
from AS 3847 (Internet Media Network), through PSI.

We were just allocated the /19 yesterday in 207/8.

Avi

> > > Depends on the situation as to whether it's detrimental. Proxy-aggregation,
> > > as this is called, can alter traffic patterns in dual-homed situations. The
> > > change is not always bad, though it is often un-desirable.
> > >
> > > In general, proxy-aggregation is good for everybody.
> >
> > If we had a good method for people to indicate routes that they didn't want to
> > be aggregated, then more proxy aggregation could be done safely.
> >
>
> If I may... The idea of using a routing registry for
> this purpose has been suggested before. I still think
> it is a valid approach. Could be very useful in assisting
> with better proxy aggregation for all.
>
> --bill

Here here. This came up in response to an experiment on the
routing table (http://routes.netaxs.com).

But unless everyone uses an RR, it is not going to be a useful for building
proxy-aggregations on the fly (i.e. without human checking and intervention).

Avi

Let me clarify something I incorrectly stated earlier. The MCI provider
network (MCI-NETBLKxx) are aggregated into /16s at the borders, not /19s
as my earlier note said. As a result, our new 207.0/14 block will be
reachable to Sprint, since they will hear the /16s.

Regards, Daniel

---------------------------------------------------------------
| Daniel M. Barton Internet: dmbarton@mci.net |
| MCI Internet Services World Wide Web: |
| Cary, North Carolina, USA http://infopage.mci.net |
---------------------------------------------------------------

Message-ID: red-13-msg951213213258MTP[01.51.00]000000ac-28766

MCI announces smaller routes for its customers that do not use the CIDR
blocks given to MCI. If you brought address space to MCI they would
announce it. The most important thing is that on NEW CIDR blocks they
stay aggregated. This is why Sprint will not listen to the announcement
of /18 or less address space in the 207.xx/8 block. Painful but effective.


Ted L.
----------
From: Jon Zeeff <jon@branch.com>
To: <cook@cookreport.com>
Cc: <dmbarton@mci.net>; <smd@chops.icp.net>; <freedman@netaxs.com>;
<nanog@merit.edu>
Subject: Re: Sprint BGP filters in 207.x.x.x?
Date: Wednesday, December 13, 1995 1:17PM


I think this is misleading. MCI does announce routes smaller than this
for its customers.

> MCI aggregates all its customer's routes into /19's. We have just

> > What I see right now, is only one announcement from the 207 block...a /19
> > coming from netaxs, and then some customer of PSI is announcing 5 or so
> > /24's in the 208 block!
>
> We see these:
>
> Network Next Hop Metric LocPrf Weight Path
> *> 207.8.128.0/19 192.41.177.87 10 0 4969 i
> * 192.41.177.241 10 0 1239 3491 4969 i
> * 192.41.177.170 10 0 3830 3491 4969 i
> * 192.41.177.87 10 0 3491 4969 i

I was looking this AM and saw (with different AS-paths) the same thing - I was
curious to see if anyone else was announcing in 207/8. Apparently not, yet.

> * i208.0.1.0 149.20.64.1 10 100 0 1280 3847 ?
> *>i 149.20.64.1 10 100 0 1280 3847 ?
> * i208.0.4.0 149.20.64.1 10 100 0 1280 3847 ?
> *>i 149.20.64.1 10 100 0 1280 3847 ?
> * i208.0.5.0 149.20.64.1 10 100 0 1280 3847 ?
> *>i 149.20.64.1 10 100 0 1280 3847 ?
> * i208.0.9.0 149.20.64.1 10 100 0 1280 3847 ?
> *>i 149.20.64.1 10 100 0 1280 3847 ?

Avi

>>If we had a good method for people to indicate routes that they didn't want to
>>be aggregated, then more proxy aggregation could be done safely.
>>
>
> If I may... The idea of using a routing registry for
> this purpose has been suggested before. I still think
> it is a valid approach. Could be very useful in assisting
> with better proxy aggregation for all.

Let me just say I think the RR has some good uses, i.e.
finding out what people intended the routing to look like, etc.

I don't really understand how a RR can help with proxy aggregation
seeing as the route objects really only provide origin AS
and regular aggregation.

It seems to me dual homed sites which are the concence of
proxy aggregation, can be detected with a reasonably full set
of routes, i.e. the second from AS from the origin in the ASPATH
being different. (Or some split in the path outside of an
AS communinity or confederation).

But I don't fully understand all the details of this, so I'm
sure someone can correct me if I'm wrong.

> Jeremy Porter <jerry@fc.net> writes:
> I don't really understand how a RR can help with proxy aggregation
> seeing as the route objects really only provide origin AS
> and regular aggregation.

It can help in several ways:

1) If you proxy aggregate you put in a route object for the aggregate.
This infiormation can be used to track down the cause of problems
caused by proxy aggregation.

2) The route object can also contain information about "holes" in an
aggregate, which can be quite useful when evaluating aggregation
strategies.

3) The routing registry also contains 'aut-num' objects describing the
routing policy of each AS: who they peer with, which routes they announce
and accept. Given this information the consequences of proxy aggragation
can be evaluated/simulated before putting a proxy aggregation in place.

Daniel

In message <m0tPwiv-000Nj8C@aero.branch.com>, Jon Zeeff writes:
> > Depends on the situation as to whether it's detrimental. Proxy-aggregation
> ,
> > as this is called, can alter traffic patterns in dual-homed situations. Th
> e
> > change is not always bad, though it is often un-desirable.
> >
> > In general, proxy-aggregation is good for everybody.
>
> If we had a good method for people to indicate routes that they didn't want t
> o
> be aggregated, then more proxy aggregation could be done safely.


One way is to register an aut-num if the routes are in a separate AS
and correctly indicate what other AS you peer with so others know
there are backup paths which are going to have to still work after
aggregation is done and not become primary paths.

If you don't have an AS then register the route in all the AS you are
multihomed to, not just one of them. This is gross, but I don't see a
good way around it.

In short, the only reason not to aggregate is to preserve correct
routing for a dual homed situation (or properly indicate a hole). The
means to indicate this is by properly registering the information in
the IRR. Then hope the proxy aggregator bothers to look there, but if
they don't then you have grounds to yell at them. Otherwise, they can
just shrug.

Curtis

In message <199512140726.BAA08568@freeside.fc.net>, Jeremy Porter writes:
> >>If we had a good method for people to indicate routes that they didn't want
> to
> >>be aggregated, then more proxy aggregation could be done safely.
> >>
> >
> > If I may... The idea of using a routing registry for
> > this purpose has been suggested before. I still think
> > it is a valid approach. Could be very useful in assisting
> > with better proxy aggregation for all.
>
> Let me just say I think the RR has some good uses, i.e.
> finding out what people intended the routing to look like, etc.
>
> I don't really understand how a RR can help with proxy aggregation
> seeing as the route objects really only provide origin AS
> and regular aggregation.

The additional clues can be found in the aut-num for dual homed AS.
If a route is registered with more than one origin AS and you route
differently to these two AS, that's a clue to look carefully before
proxying too.

> It seems to me dual homed sites which are the concence of
> proxy aggregation, can be detected with a reasonably full set
> of routes, i.e. the second from AS from the origin in the ASPATH
> being different. (Or some split in the path outside of an
> AS communinity or confederation).

The secondary route may not be advertised to you if the primary
suppresses the advertisement. For example if previders are A and B
and they peer with each other, I may think I can aggregate some prefix
over provider A, but B may not be advertising a backup path since it
is preferring the same primary through A.

Curtis

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> ""Daniel" == "Daniel M Barton" <dmbarton@mci.net> writes:


Daniel> Let me clarify something I incorrectly stated
Daniel> earlier. The MCI provider network
Daniel> (MCI-NETBLKxx) are aggregated into /16s at
Daniel> the borders, not /19s as my earlier note
Daniel> said.

Which is a good thing too, since, as we do closest-exit
routing towards InternetMCI, whether we hear one prefix
in your /14 or 10000, packets will go out the same
direction under normal circumstances.

Anyone wanting to deal with abnormal circumstances
(partitioning of InternetMCI that makes part of a
big aggregate unreachable from a border gateway
announcing the entire aggregate) is welcomed to study
Yakov Rekhter's excellent presentation on the "push"
operation.

Anyone downstream from us wanting to route differently
towards different parts of the big aggregate is welcomed
to study Yakov Rekhter's excellent presentation on
the "pull" operation.

Sean.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey

iQCVAwUBMNOmkESWYarrFs6xAQFYkgP+OEq1hmM7UAx/UCY/Sfku+w9DeOCkwq/8
oG4Pohy6I96Qrq4DiM0ufqQXRGJed5vzh+kuQrhbALSd2JP7Nfj18/CClcR5xz6/
9YF2nC9A23dA0MXxsXMb3RNSoGcWyOoRLA0jOekR087uTUNIKQ+jv9uMLQqjazte
h2ytLMREXrM=
=ja/7
-----END PGP SIGNATURE-----