[ppml] Fwd: 2005-1 status

[Owen DeLong]

Oops... Experimenting with new mail client... Don't have the reply
defaults quite worked out yet.

Meant to post this originally...

Owen


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.
>
> -Scott
>
> 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  
>>> 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.
>>>
>> 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
>>>> them?
>>>
>>> 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
>>> engineering.
>>> See for example Jason Schiller's presentation on network operator
>>> traffic
>>> engineering concerns with shim6 that was presented at the L.A.  
>>> NANOG.
>>>
>> Invariably, traffic engineering eventually boils down to ways to  
>> divide
>> traffic load.  Eventually, this leads to ways to subdivide addressing
>> blocks.
>>
>> Owen
>>
>>