Re: [apops] Re: The Mandatory One Reply To This Weeks: The Cidr Report

["Phillip Grasso-Nguyen" <phillipg@magna.com.au>]

Why not announce the aggregate's to all neighbours, and announce the longer
blocks with no-export stamped. This should still allow control of traffic
direction. This could be solved alot easier if more of the larger backbone
providers supported a better community set.

e.g. Concert/AT&T, i.e. whois -h whois.radb.net AS5727

With more backbones that allow functions like stamping no-exports,
as-prepends, and stopping announcements to specific peers/upstreams, it
would be much simpler to control traffic flow.

Regards
 Phillip.


-----Original Message-----
From: "Joe Abley" <jabley@automagic.org>
To: "Christian Nielsen" <cnielsen@exodus.net>
Cc: "Hank Nussbacher" <hank@att.net.il>; "Aleksi Suhonen"
<nanog-poster@axu.tm>; <apops@apnic.net>
Date: Thursday, 22 March 2001 10:07
Subject: Re: [apops] Re: The Mandatory One Reply To This Weeks: The Cidr
Report


>On Wed, Mar 21, 2001 at 02:43:10PM -0800, Christian Nielsen wrote:
>> On Wed, 21 Mar 2001, Joe Abley wrote:
>> > The solution of advertising a large number of prefixes in different
>> > ways to different adjacent networks is one way of accomplishing the
>> > policy dissemination; however, one problem is the large amount of
>> > prefix bloat associated with it that the whole network gets to see.
>>
>> right. that is correct. i guess i can better understand this if they, the
>> end user/edge network, would run BGP.
>>
>> *>i148.182.0.0      209.1.40.63                  1000      0 1 16779 1221
i
>> *>i148.182.16.0/24  209.1.40.63                  1000      0 1 16779 1221
?
>> *>i148.182.17.0/24  209.1.40.63                  1000      0 1 16779 1221
?
>> *>i148.182.18.0/24  209.1.40.63                  1000      0 1 16779 1221
?
>>
>> i have no problems seeing
>>
>> * i148.182.12.0/22  209.1.220.156                1000      0 5727 1221
4740 4740 4740 4740 i
>
>I think the issue here is you are only seeing part of what 122 may be
>trying to do by your single view. If you can imagine other views of the
>network where those /24s have different attributes, you can see how
>there might be some method behind the madness; the deaggregation in
>that case is a method for 1221 to influence routing in remote ASes in
>order to do it's own inter-AS traffic engineering.
>
>Note that I have no real knowledge of what 1221 is doing, or why. However,
>Geoff is in Minneapolis presenting on exactly these topics and it seems
>entirely possible that the two observed phenomena are related :)
>
>
>Joe
>*             APOPS: Asia Pacific Operations Forum              *
>* To unsubscribe: send "unsubscribe" to apops-request@apnic.net *
>

*             APOPS: Asia Pacific Operations Forum              *
* To unsubscribe: send "unsubscribe" to apops-request@apnic.net *