> I'm not sure how to convince smaller folks to do the right thing if the big
> people can't sort it out. (even with the right hooks).
You automate the process as much as possible, and let them sort out the
problems that result from their messed up shorter prefix routes.
:-)
Russ
_
> How do you know that the overlapping route takes traffic through the
> same path? AS path != routing path and BGP is a distance-vector
> protocol. Your router has no reliable knowledge of the routing path
> more than 1 hop away.
All that matters is that I draw the same traffic into my AS, where
>> Sorry, but it is always true that by removing information you always
>> lose optimality (you increase stretch). Whether that removal is done at
>> the edge or in the core, the result is always the same. There are two
>> ironclad rules of routing:
>>
>> - Removing information decreases optimal r
On Oct 3, 2012, at 10:21 AM, Russ White wrote:
>>
>> The problem as I see it is many of those that operate in the BGP/DFZ don't
>> know what they are doing.
>
> ???
>
> Then they shouldn't be using this technique. Or perhaps even running
> BGP. Protocols provide rope. It's choice whether you
On Wed, Oct 3, 2012 at 2:03 PM, Russ White wrote:
>
>>> No more than if the longer prefix were filtered for any other reason
>>> --such as if the provider is originating the shorter prefix, and decides
>>> to filter the longer prefix for whatever local policy reason. The only
>>> way to see this
Russ,
> Yes.
>
> Sorry, but it is always true that by removing information you always
> lose optimality (you increase stretch). Whether that removal is done at
> the edge or in the core, the result is always the same. There are two
> ironclad rules of routing:
>
> - Removing information decreases
>> No more than if the longer prefix were filtered for any other reason
>> --such as if the provider is originating the shorter prefix, and decides
>> to filter the longer prefix for whatever local policy reason. The only
>> way to see this as "losing AS Path information," is to see the filtering
On Wed, Oct 3, 2012 at 9:29 AM, Alvaro Retana (aretana)
wrote:
> I agree. Which is why our proposal is optional; if you want to do it, you
> can enable itŠas you can manually filter blocks of routes today or make
> all the exceptions you want (or are paid for).
Hi Alvaro,
That's not really an a
>> Because you could see this and mark your /24 not to be bounded (if we
>> put that back in). We were trying for the simplest solution to
>> increasing table sizes --I know there are economic reasons the table
>> sizes are growing, but we need at least some option to de-escalate the
>> madness at
On Wed, Oct 3, 2012 at 10:20 AM, Russ White wrote:
>>> I don't get how path information is lost in this draft. The AS Path is
>>> not altered in any advertisement, so it's not like aggregation, where
>>> you replace a series of AS' with a single AS, or anything like that.
>>
>> 10.1.0.0/16 AS path
On 03/10/2012 17:10, Russ White wrote:
> Because you could see this and mark your /24 not to be bounded (if we
> put that back in). We were trying for the simplest solution to
> increasing table sizes --I know there are economic reasons the table
> sizes are growing, but we need at least some optio
> How do you know it does not matter if you are not comparing it best
> path with less specific ? How do you know that your competitor which
> your dual home customer is also connected to is not filtering and is
> injecting /24 attracting and charging for all the traffic ?
Because you could see t
>> =
>> 3.3 Handling Marked Routes Within the AS
>>
>> Routes marked with the BOUNDED community MAY not be installed in the
>> local RIB of routers within the AS. This optional step will reduce
>> local RIB and forwarding table usage and volatility within the AS.
>
> So if I lear
Alvaro,
>> >10.1.0.0/16 AS path 12 5 4 2
>10.1.1.0/24 AS path 12 1
>
>The 12->1 path, 1 being a completely different origin AS than the
>covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated
>into 10.1.0.0/16.
>
The path is not aggregated. Instead, the /24 would be marked as
>> Suppose an Internet-connected network consists of site A and site B.
>> 10.1.1.0/24 is advertised from and used by site A while 10.1.2.0/24 is
>> advertised from and used by site site B. Both sites advertise
>> 10.1.0.0/16. Sites A and B are connected to each other, so if site A
>> receives a p
Russ,
Hmmm, I don't think this is a consistent message.. When I attempted to
give people rope i.e BGP Persistence IETF chairs felt that this was too much
rope ?? IMO it takes very little rope to hang oneself so, let's be consistent
as a starting point...
Jim Uttaro
-Original Messa
> The problem as I see it is many of those that operate in the BGP/DFZ don't
> know what they are doing.
???
Then they shouldn't be using this technique. Or perhaps even running
BGP. Protocols provide rope. It's choice whether you make good things or
bad things with the rope provided.
:-)
Rus
>> I don't get how path information is lost in this draft. The AS Path is
>> not altered in any advertisement, so it's not like aggregation, where
>> you replace a series of AS' with a single AS, or anything like that.
>
> Hi Russ,
>
> 10.1.0.0/16 AS path 12 5 4 2
> 10.1.1.0/24 AS path 12 1
>
>
Jared:
On 10/2/12 6:44 PM, "Jared Mauch" wrote:
>
>On Oct 2, 2012, at 5:23 PM, Russ White wrote:
>
- Path information is lost. While this doesn't impact loop
prevention, this
information is operationally useful.
>>>
>>> +1. Reachability data optimisation is highly desira
[Also catching upŠ]
Bill:
I want to say up front that the proposal is not for this draft to be a
standards track document and to have everyone do it by default. It
provides a tool that people may want to use, as reflected by some interest
at the WG meeting. This is why we intended the draft to
20 matches
Mail list logo
