[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [apops] Re: The Mandatory One Reply To This Weeks: The CidrReport
On Thu, 22 Mar 2001, Phillip Grasso-Nguyen wrote:
> 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.
yes. this is the key. many providers allow one to set a no-export,
no-export to peers community. someone buying transit from an ISP in
multi locations could send the /16 as advertise to all and then send /24s
with no-export type of community.
> 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 *
> >
>
Christian.
----
Network Architect
BENGI - Exodus
AS3967 .us .ca .au AS8709 .eu (.de .uk .nl .fr) AS4197 .jp
* APOPS: Asia Pacific Operations Forum *
* To unsubscribe: send "unsubscribe" to apops-request@apnic.net *
