[ppml] Fwd: 2005-1 status
owen at delong.com
Tue Jan 24 17:35:17 EST 2006
Oops... Experimenting with new mail client... Don't have the reply
defaults quite worked out yet.
Meant to post this originally...
Begin forwarded message:
> From: Scott Leibrand <sleibrand at internap.com>
> Date: January 24, 2006 2:25:42 PM PST
> To: Owen DeLong <owen at delong.com>
> Subject: Re: [ppml] 2005-1 status
> Yeah. I think we agree here. Feel free to post your comments &
> clarifications, though, for the benefit of people like Lee.
> On 01/24/06 at 2:23pm -0800, Owen DeLong <owen at delong.com> wrote:
>>>> 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
>>> 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
>>> but its use is preferable IMO to deaggregation.
>> Of course it is, but, if you want 1/2 of a prefix to have a longer
>> AS path one way and the other 1/2 of the same prefix to be preferred
>> the other way, then, it doesn't help without deaggregation.
>>>> Should engineers be able to determine how traffic flows toward
>>> Yes, definitely.
>> I would say Yes, it would be nice, but, at the same time, determining
>> how traffic flows towards your AS is, by definition, determining how
>> traffic is routed by your neighboring ASs. I'm not so sure you
>> should be able to do that. I agree that we need a mechanism to
>> INFLUENCE how traffic flows towards your AS, and, several are
>> available. However, determining should be done by the AS doing
>> the forwarding.
>>>> 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
>>> See for example Jason Schiller's presentation on network operator
>>> engineering concerns with shim6 that was presented at the L.A.
>> Invariably, traffic engineering eventually boils down to ways to
>> traffic load. Eventually, this leads to ways to subdivide addressing
More information about the ARIN-PPML