[ppml] 2005-1 status

Scott Leibrand sleibrand at internap.com
Tue Jan 24 16:11:27 EST 2006

On 01/24/06 at 11:09am -0500, Howard, W. Lee <Lee.Howard at stanleyassociates....:

> I've never been a traffic engineer.  Looks to me like BGP is designed
> with lots of knobs to determine how bits flow away from you, but fewer
> knobs to determine how bits flow toward you,

That much is true.

> none of which extends beyond the neighbor AS (unless they
> choose to propagate).  With multiple neighbor ASes with different
> policies, the only tool is to deaggregate announcements in
> careful ways.
> Is this characterization accurate?

Not quite.  You can also prepend your own ASN on announcements to your
upstreams, making one path look longer than the other when the BGP
decision falls to AS path length.  This is a bit of a blunt instrument,
but its use is preferable IMO to deaggregation.

> Should engineers be able to determine how traffic flows toward
> them?

Yes, definitely.

> Will the need for traffic engineering by deaggregation be a
> major pressure on routing table size in the future?

That depends on what other options are available for traffic engineering.
See for example Jason Schiller's presentation on network operator traffic
engineering concerns with shim6 that was presented at the L.A. NANOG.


More information about the ARIN-PPML mailing list