From: Peter van Oene (pvo@usermail.com)
Date: Fri Jul 02 2004 - 20:00:24 GMT-3
At 06:31 PM 7/2/2004, James wrote:
>Hi Howard,
>
>By "backbones" I meant transit ISP backbones. Not enterprises..
Clearly Howard meant enterprise backbones as you seem to agree. Debating
his enterprise oriented strategy from an SP perspective isn't all that
useful ;-)
> >
> > In the real world, I find confederations most useful to build a
> > complex backbone-of-backbones for enterprises. They let you split
> > IGP domains, and also let you implement complex enterprise (or
> > extranet) interdomain policies.
>
>I would agree to some extent in this.
>
> >
> > Splitting IGP domains can be useful in several ways. The most obvious
> > is scalability by restricting the number of routes and routers in
> > each domian.
>
>IGP domains are usually not a scalability issue on most transit backbones
>(e.g. AS209, AS7018, AS1668) as they carry only infrastructure next-hops
>required by BGP to make routing decisions, in IGP. Almost everything else is
>carried in IBGP with appropriate community (i.e. no-export or their own
>version
>of no-export) to prevent leak to outside. Most of their scalability issues
>come
>from edge router peerings into the core, which is alleaveated easily by
>route-reflectors going down from core->edge.
>
>AS209 and 1668 use exclusively ISIS on their entire international network,
>carrying only TLVs necessary to carry needed next-hops and perform BGP
>traffic engineering by modifying IGP cost of a peering circuit.
>
> > Next, sometimes a topology that would be quite awkward
> > with OSPF or ISIS backbone rules becomes much easier when you have a
> > limited number of interdomain connections, which don't need to follow
> > strict hierarchy.
>
>It's not always about the hierarchy these days with these backbones. They want
>something simple for overall peering topology and be able to TE the peering
>routes by simple modification of IGP cost in multi-location peering sessions.
>A flat-IGP network is the best for this type of scenario.
>
> > If you are a multinational enterprise, the
> > bandwidths available in continents or regions often tend to differ.
>
>That's totally dependent of your IGP engineering.
>
> > Routing performance tends to be most predictable when there isn't a
> > huge range of bandwidths in the same IGP domain.
> > these are apt to be traffic-engineered, using at least RSVP and
> > probably MPLS. ISP backbones tend to be fairly flat. POPs feed into
> > the edges of these backbones, and the POPs usually involve route
> > reflectors, often fully meshed within the cluster to avoid some of
> > the oscillation conditions described in RFC 3345. I suspect the CCIE
> > lab does not consider 3345 issues.
>
>I fully agree with this.
>
>-J
>
> >
> > >
> > >-J
> > >
> > >On Fri, Jul 02, 2004 at 04:19:33PM -0400, Tom Martin wrote:
> > >> It is tough to follow Howard and offer any kind of practical advice on
> > >> BGP... But I will throw my idea out on the assumption that you're
> > >> studying for the lab and just looking for options for "what if"
> > >> scenarios...
> > >>
> > >> You could configure the existing AS 100 as a confederation AS within AS
> > >> 200 by adding a single line:
> > >>
> > >> router bgp 100
> > >> bgp confederation identifier 200
> > >>
> > >> That would also have the effect of advertising AS 200 to EBGP peers,
> > >> without reconfiguration of any existing neighbors. That assumes that you
> > >> aren't going to have new neighbors, that your neighbors will be
> > >> correctly configured for your "new" AS, etc.
> > >>
> > >> -- Tom
> > >>
> > >> -----Original Message-----
> > >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > >> ccienj
> > >> Sent: Friday, July 02, 2004 2:54 PM
> > >> To: ccielab@groupstudy.com
> > >> Subject: BGP AS-Migration
> > >>
> > >> An ISP currently on AS 100 will move to AS 200 next year, to avoid
> > >> reconfiguration for this year's customer's what would be best solution
> > >> to
> > >> minimize reconfiguration.
> > >>
> > >> I think BGP Local-as would be the best way to handle this any other
> > >> ideas ?
> > >>
> > >> thanks,
> > >>
> > >> _______________________________________________________________________
> > >> Please help support GroupStudy by purchasing your study materials from:
> > >> http://shop.groupstudy.com
> > >>
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >>
> > >> _______________________________________________________________________
> > >> Please help support GroupStudy by purchasing your study materials from:
> > >> http://shop.groupstudy.com
> > >>
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >
> > >--
> > >James Jun TowardEX
> > >Technologies, Inc.
> > >Technical Lead Network Design, Consulting, IT
> > >Outsourcing
> > >james@towardex.com Boston-based Colocation &
> > >Bandwidth Services
> > >cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> > >www.twdx.net
> > >
> > >_______________________________________________________________________
> > >Please help support GroupStudy by purchasing your study materials from:
> > >http://shop.groupstudy.com
> > >
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>--
>James Jun TowardEX
>Technologies, Inc.
>Technical Lead Network Design, Consulting, IT
>Outsourcing
>james@towardex.com Boston-based Colocation & Bandwidth
>Services
>cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
>www.twdx.net
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3