Subject: Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

From: Russ White <[email-masked]>
Date: Tue, 02 Oct 2012 17:20:41 -0400

I haven't been keeping up on email very well, but...

> - Path information is lost.  While this doesn't impact loop prevention, this
>   information is operationally useful.  I'll offer the counter that this is
>   already done today through explicit policy, typically either because the
>   operator knows this is safe or because they simply don't care about the
>   consequences to forwarding.

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.
Path information is no more lost than with simple filtering for various
other reasons.

> - In several cases, the more specific prefix may be information that is
>   *not* present from the originating AS - i.e. a subnet has "wandered away".
>   Such situations will become increasingly common as the Internet
>   deaggregates under pressure of address space exhaustion.  This is my
>   primary concern.

I don't get this one, either... Your concern is that the mechanism
explained will become less useful over time as aggregation becomes less
possible because of greater spreading of origination... I'm not certain
why we should read this... "We shouldn't document or use ideas that
aren't 100% effective, or won't be 100% effective in the future?"

Can you clarify what you're actually saying here?

>   - The draft does suggest you can look at the AS_PATH.  This is certainly
>     much safer if you ensure that the less and more specific routes share a
>     common origin AS.

No, not really... The decision point is whether or not the additional
path will impact forwarding at the neighboring AS, not whether or not
the route is the same in some way. I don't much care if the origin AS is
the same, so long as the traffic will pass to the same neighboring AS to
reach the destination.

Aggregation, in fact, is based on the principle that as you come closer
to the actual destination, routing information becomes more specific. If
we take this objection to heart, we should disallow aggregation of all
types in all routing systems.

>   - But even if they do share a common origin AS, if you have an internal AS
>     partition, things may be unhappy if the more specific provided you
>     forwarding coverage and it got suppressed.

AS partitions are already handled in the draft as written. If the two
routers with overlapping prefixes aren't reachable through iBGP (no
matter what their AS numbers might happen to me), then the mechanism
won't suppress the longer prefix.

> - Tying the fate of the routes together will likely yield some interesting
>   route flaps as covering prefixes come and go, especially as part of iBGP
>   churn.  

Churn due to route flaps is a problem outside of aggregation of routing
information --in fact, this proposal is likely to reduce churn, rather
than increase it, by suppressing longer prefixes, which tend to be less
stable.

>   - I'm vaguely concerned there may be scenarios where astable route
>     announcements happen during some convergence scenario, but I haven't
>     figured one out yet.  If such can happen, our friend policy would
>     probably be involved. :-)

I'm not convinced we should disallow solutions because of vague
feelings... Can you actually find a situation so we can analyze whether
or not it impacts operation?

> Note that some of these arguments appeared in a different form while
> discussing the ATOMIC_AGGREGATE feature in BGP during the RFC 4271
> standardization process.

Since this proposal doesn't use ATOMIC_AGGREGATE, none of these
objections apply...

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Russ White <[email-masked]>
Date: Tue, 02 Oct 2012 17:23:07 -0400

>>   information is operationally useful.
> 
> +1.  Reachability data optimisation is highly desirable and may one day be
> necessary, but this is one of the wrong places to do it.

Again, I'm a bit baffled. Can you explain how this draft actually
removes reachability optimization in the DFZ? It's carefully crafted NOT
to remove any reachability information that produces a shorter path.

I know the chairs have already (short sightedly, IMHO), decided not to
accept this draft as a WG item, but I'd really like to understand what
specific situation you can draw up where the proposed mechanism
increases the stretch in any path.

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: William Herrin <[email-masked]>
Date: Tue, 2 Oct 2012 17:46:00 -0400

> 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

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.

> I don't get this one, either...

The prior example exhibits this case as well.

> won't suppress the longer prefix.

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 packet for 10.1.2.1, it will forward it to site B.

If site B should lose its internet connection, packets for 10.1.2.1
will follow the covering route via site A and still reach site B.
Regardless of aggregation.

Instead, lose the connection from site A to site B but keep both sites
connected to the Internet. The covering route continues to appear at
your router but if you send 10.1.2.1 to site A because you discarded
the more specific route, you have black-holed that packet. Even though
site B is connected to the Internet.

In normal operation, another nasty problem appears. Site A is in
London. Site B is in Honolulu. You're in Chicago. Your packet to
10.1.2.1 follows the closest aggregated route to London before it can
travel to Honolulu, adding thousands of miles and near a hundred
milliseconds to its trip.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Jared Mauch <[email-masked]>
Date: Tue, 2 Oct 2012 18:44:10 -0400

> increases the stretch in any path.

Russ,

The problem as I see it is many of those that operate in the BGP/DFZ don't know what they are doing.

This makes solving these problems infinitely more complex compared to how they should be if everyone was sane.

58.64.162.0/24	 2497 701 6453 45474 174 17444 

is a great example for me and easily observed (even if just as a transitory announcement).

I see this in my router, but the above leaked out...

*>i58.64.160.0/19     x.x.x.x                120      0 17444 17444 17444 17444 17444 17444 17444 i

Not only did the above route look disgusting for the as_path, but there should have been some better covering prefixes appear perhaps?

Anyways, you can't make people route sanely and the ISPs have a hard time rejecting the money people want to pay for the extra flexibility.

- Jared

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 3 Oct 2012 13:29:19 +0000

[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 be Experimental
at this point.

On 10/2/12 5:46 PM, "William Herrin" <[email-masked]> wrote:

>>>   Consequences to forwarding.
>>

The path is not aggregated.  Instead, the /24 would be marked as BOUNDED;
the draft explains what that means:

=====
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.

3.4 Handling Marked Routes at the Outbound Edge

   Routes marked with the BOUNDED community SHOULD NOT be advertised to
   external peers.  If they are advertised, they SHOULD then be marked
   with the NO_EXPORT community.
=====

The proposal is for the /24 to not be advertised further.  I can see how
this looks like loss of path information.

However, we also wrote the following:

=====
3.1 Marking Overlapping Routes

   As each prefix is received by a BGP speaker from an external peer, it
   is evaluated in the light of other prefixes already received.  If two
   prefixes overlap in space (such as 192.0.2.0/24 and 192.0.2.128/25),
   the longer prefix SHOULD be BOUNDED.

   A BGP speaker MAY also choose to check the AS_PATH attribute length
   and contents before marking a prefix as BOUNDED.
=====

The intent of the last paragraph was to have the local network decide
whether the AS_PATH should somehow match or not.

Given the comments, maybe we should change the 'MAY' above for 'SHOULD'
(??), and clarify what the checking would/could entail.

..
>Suppose an Internet-connected network consists of site A and site B.
..

Yes, that is a problem.

I do want to note that the same problem exists today if the more specific
route is discarded due to a policy related to the length of the prefixes
accepted by a given SP -- or any other such policy that can be implemented
with a manual filter.  As with the manual filter (as I said above), our
proposal is optional, it is intended to facilitate the operation if you
want to use it..

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 3 Oct 2012 13:29:50 +0000

Jared:

On 10/2/12 6:44 PM, "Jared Mauch" <[email-masked]> wrote:

>Not only did the above route look disgusting for the as_path, but there
>should have been some better covering prefixes appear perhaps?
>
>Anyways, you can't make people route sanely and the ISPs have a hard time
>rejecting the money people want to pay for the extra flexibility.

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).

For the example above, we do need to better articulate the "rules" around
checking the AS_PATH before making a decision.

Thanks!

Alvaro.

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 10:20:06 -0400

> covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated

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
of any possible route, including routes lost because they aren't the
best path, as "losing AS Path information."

> Regardless of aggregation.

This has always been true of any form of aggregation --this draft
doesn't introduce any new risk in this area. When you aggregate at any
level, ever, you always introduce the risk of suboptimal routes and/or
routing black holes. Does this mean all routes advertised into the DFZ
should be /24's, or host routes?

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 10:21:34 -0400

> 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.

:-)

Russ

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 3 Oct 2012 14:25:53 +0000

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 Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: Wednesday, October 03, 2012 10:22 AM
To: Jared Mauch
Cc: [email-masked]
Subject: Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

???

:-)

Russ
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 10:32:45 -0400

> should be /24's, or host routes?

BTW, I agree with Alvaro that the draft intends to leave open the option
of how to implement this within an individual provider's network, so the
provider could choose to check the entire AS Path before bounding a
particular route.

We had also removed (for simplicity) the "don't bound" community, but we
could easily add it back in if providers want the capability to have a
customer mark their routes to never be removed. Would that be useful?

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 03 Oct 2012 16:33:59 +0200

Alvaro,

>     local RIB and forwarding table usage and volatility within the AS.

So if I learn /24 from different peer then /16 arrives on given ASBR or 
such /24 arrives via different ASBR (both cases would result /24 to have 
different next hop then /16) such /24 would not be marked as BOUNDED 
correct ?

If so I really fail why this filtering can not be done by inbound EBGP 
policy on such ASBR. Why do we need new draft and new communities ???

R.

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 11:52:27 -0400

> policy on such ASBR. Why do we need new draft and new communities ???

MAY not, so it's a local option. This draft allows for two modes of
operation (at least), one where the two routes can arrive on two
different AS border routers, and one where they must arrive on the same
AS border router. The second case is just like filtering the longer
prefix at the inbound AS border router, the first keeps optimal exit
points out of the local AS, while removing information once it doesn't
matter to the flow of traffic.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 12:10:38 -0400

> 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 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 some point.

:-)

Russ

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Oct 2012 17:28:41 +0100

> sizes are growing, but we need at least some option to de-escalate the

People have been saying for the last twentysomething years that the sky is
falling due to DMZ growth.  Geoff Huston gave a talk about this last year
in Vienna where he presented some data and analysis:

http://ripe63.ripe.net/archives/video/178
http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

I'm not suggesting that the DFZ couldn't do with a bit of slimming, but the
bgp RIB is not the best place to do it because you're losing too much
information too early.

Nick

---

From: William Herrin <[email-masked]>
Date: Wed, 3 Oct 2012 13:41:02 -0400

Hi Russ,

With the occasional exception of leaf ASes, the longer prefix *isn't*
filtered for any reason today. Precisely because it breaks the routing
system. Some folks tried some filtering for a while, filtering at /21
based on RIR minimum allocation sizes within particular /8's but it
didn't work out. Operationally, the current expectation is that any
prefix /24 or shorter will be propagated throughout the system.

The moment a major transit AS uses this technique, everybody doing
something like the above has to disaggregate into non-overlapping
routes in order to maintain operations. Those two advertisements
become at least nine. Unless you can identify a sufficient number of
origins who for one reason or another *wouldn't* choose to
disaggregate, the use of the technique in any transit AS would result
in an *increase* rather than decrease the routing table load.

If you restrict your solution set to non-transit ASes there are some
promising techniques based on aggregating for AS distance rather than
overlap. As a leaf, once a route is distant enough from you, if you
see it from all "upstream" neighbors you can usually aggregate it into
a /8 covering route with typically negligible harm to your routing
efficiency. But that only works if you are a leaf AS. If there's
someone who would otherwise receive the more specific route from you
then you've just broken the routing system. And of course offering the
aggregate route to a neighboring AS is a recipe for nastiness since
you can't really analyze its impact anywhere other than inside your
own AS.

However, since you're already at the leaf AS for this approach, it's
not clear such a technique wouldn't be better applied to the FIB
produced from the RIB rather than to the RIB directly. You have to
process the prefixes inbound anyway and holding them in a radix tree
that isn't accessed on a per-packet basis isn't computationally
expensive.

> should be /24's, or host routes?

No. It means that the source AS is the only place technically capable
of making verifiably correct aggregation decisions impacting transit
ASes. Stated more generally, an AS is only capable of making
aggregation decisions which impact only that AS. The moment your
aggregation choice spreads to a neighbor AS you've broken the system.

As I mentioned in previous emails, this has been explored ad nauseam
over in RRG. It would be very productive to dig through those archives
and use the knowledge there to produce an RFC that documents the
myriad issues that a solution in this space would have to resolve.
Perhaps as a first step to further analyzing your approach.

Regards,
Bill Herrin

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 13:44:07 -0400

> http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

I would suggest:

1. IPv6, over time, is going to present a different issue...
2. That the problem is an economic problem, not a technical one, and
hence we need a solution that pushes the tradeoffs between the cost of
advertising and the cost of not advertising into the front of our minds,
rather than making the advertisement of a new longer prefix route "free."

> bgp RIB is not the best place to do it because you're losing too much

This isn't at the BGP RIB, this is removing routes from the system when
they are no longer useful for modifying forwarding direction. It's no
different than removing routes that have lost in the best path decision
process, in terms of "lost information." We could, of course, back up
and argue that we shouldn't be removing routes that lose in the bestpath
process, because we're "losing AS Path information," if we want to argue
for complete information everywhere.

:-)

Russ

---

From: William Herrin <[email-masked]>
Date: Wed, 3 Oct 2012 13:45:31 -0400

> all the exceptions you want (or are paid for).

Hi Alvaro,

That's not really an accurate characterization of the described
approach. When a particular AS chooses to aggregate a route, the
discarded route does not pass to neighbor to whom he'd otherwise pass
it on a general routing policy basis. Folks paying the AS for a full
view of the Internet do not receive a full view of the Internet.

Regards,
Bill Herrin

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 14:03:19 -0400

> prefix /24 or shorter will be propagated throughout the system.

There's a vast difference between filtering out everything longer than a
/21 and suppressing a /24 when an overlapping route that takes the
traffic through the same path available. Completely different concepts.

In the case of suppressing longer prefixes, the result is something like
fisheye routing, or simple aggregation today. If an edge device only has
a default route, you don't expect the traffic to travel to the far end
of the network before it starts following a more sane path to the
destination. Instead, the traffic might follow a less than optimal route
until it reaches a point in the network where more specific routing
information is available.

This proposal does the same thing --I notice that I will be advertising
two overlapping routes that will draw traffic along the same path (to
me) to a peer. There's no reason to advertise both possible paths, it's
simply overlapping information that's not needed to draw traffic in the
right direction. So I don't advertise it.

> No. 

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 optimal routing.
- Removing information is necessary for the stability of the system.

You can play with different ways and places to remove information, but
you're always going to need to remove information. You can try to remove
information in the way that least impacts optimal routing, but you're
always going to introduce suboptimality in some way.

This proposal is about the minimal you can get to in terms of removing
information (no worse than best path does today), to keep modifications
to the path traffic actually flows to a minimum. I've looked at stuff
that does less than this, none of which has turned out to have any
meaningful impact, and stuff that does more than this, which has turned
out to be either complex for the gain, or increases stretch in
significant ways in normal operation (and not just broken corner cases).

> It means that the source AS is the only place technically capable
> ASes. 

Actually, the origin AS is the one place where you can't know how far
your route should propagate in order to effectively engineer traffic.
The only place you can know that the longer prefix is no longer useful
is at the point where two overlapping prefixes exist that will point
traffic in the same direction.

> Perhaps as a first step to further analyzing your approach.

I can feel your hands waving all the way over here... :-)

How about thinking up a specific situation where a problem exists that
will not or can not exist through normal aggregation, or through normal
route processing today, and posting it to the list? We can then sort out
whether its something that's actually broken (outside brokenness that
already exists in the routing system), if can be fixed, or if it's
impossible to fix.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Oct 2012 20:27:17 +0200

Russ,

No.

If you remove information which is redundant and when such removal
will not result in even a single bit of sub-optimal routing what you
wrote above is false "ironclad rule".

Also the critical piece is that the determination when and what should
be removed must be 100% automated. There is no way where manual
intervention would be required for any scheme to work right. And your
proposal does require manual NOC intervention as you have already
confirmed today.

The proposal from Pedro however is automated, adjust itself to
topology changes as well as removed only redundant information where
such removal does not impact a single bit routing optimality.

Rgs,
R.

---

From: William Herrin <[email-masked]>
Date: Wed, 3 Oct 2012 17:00:46 -0400

Hi 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.

Even if you could know the routing path was the same, consider:

ISP 88
10.1.0.0/16 via 2 3
10.1.1.0/24 via 2 3 (suppressed)

ISP 99
10.1.0.0/16 via 4 12 62 16 2 3
10.1.1.0/24 via 4 8 9 5 3 (not suppressed)

ISP 111 (customer of 88 & 99):
10.1.0.0/16 via 88 2 3
10.1.1.0/24 via 99 4 8 9 5 3

Best route was lost. But 111 can't safely suppress the /24 route
because he has no knowledge of whether the /24 is reachable via 88 1 2
3. To the best of 111's knowledge, AS3 might look like this right now:

2 - 3A
5 - 3B
No connection between 3A and 3B.

That's right, 111 doesn't know that AS3 is a contiguous network right
now. 111 doesn't even know that it's *intended* to be a contiguous
network ever. The most he knows about AS3 is that it's the same
organization from an administrative standpoint.

So, 111 is stuck using the badly suboptimal route because 88
suppressed a route that 111 needed to choose a reasonable next hop.

This is if you require exact path matching to suppress a route, which
your draft does not. Trivial scenarios following your draft lose
connectivity entirely.

Regards,
Bill Herrin

---

From: Jared Mauch <[email-masked]>
Date: Wed, 3 Oct 2012 17:21:23 -0400

> bad things with the rope provided.

Sure.

But expecting them to do anything 'smart' has been a huge undertaking.  Some providers (e.g.: Bellsouth/ATT) have been trying for 2+ years to fix their unnecessary aggregate leaks with no success. 

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).

- Jared

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 21:27:26 -0400

>> - Removing information decreases optimal routing.

Yes. :-)

In fact, one of the points people are arguing here is, "in these
circumstances, the stretch increases."

1. Under normal operation, this proposal doesn't increase stretch (that
I know of).
2. Under broken conditions, any proposal may (probably will, in fact)
increase stretch.
3. In fact, normal aggregation increases stretch, so...

> proposal does require manual NOC intervention as you have already

Robert --methinks you're putting words in my mouth. Beyond the basic
configuration, there's no "manual intervention." If you consider
configuring the option to be "manual intervention," then we have a fully
manual routing system already in place. :-)

> such removal does not impact a single bit routing optimality.

This is a very simplified version of the proposal Pedro made --in fact,
this proposal actually predates Pedro's. I like Pedro's proposal, but I
consider the two different solutions parallel, rather than opposed.
There's no reason one AS couldn't implement one, and another the other
--it really isn't going to matter in the long run.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 21:36:58 -0400

> protocol. Your router has no reliable knowledge of the routing path

All that matters is that I draw the same traffic into my AS, where the
more specifics still exist, so I can optimally route the traffic out of
my AS --the same as I always have. You seem to be thinking that this
would be done at the edge in some way --that the originating AS would be
doing the suppression. That's not the way this is designed to work at all.

The suppression is supposed to take place at least one hop away from the
route origin, and only if I can be reasonably certain that my
suppression of the longer route isn't going to change traffic patterns
from my perspective.

> 3. To the best of 111's knowledge, AS3 might look like this right now:

So, I'm trying to guess how you have things connected, but it seems like
what you're saying is that the longer prefix is suppressed, leaving a
shorter prefix that loses to another peer's shorter prefix which doesn't
actually contain the longer prefix.

Further, the two AS' advertising the two shorter prefixes cannot be
connected to one another.

I actually don't see how this would work in normal routing, much less if
you suppress the shorter --you're saying you have a situation where one
AS has access to 10.1.0.0/16 and 10.1.1.0/24, and another has access to
10.1.0.0/16, but not 10.1.1.0/24. I'd like to see a network designed
where this is true without data plane filters implemented.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 03 Oct 2012 21:37:46 -0400

> 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

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Thu, 4 Oct 2012 11:47:18 +0200

Just to add a bit more of entropy...

As part of my PhD, I'm working on a way to reduce the Internet's core
routing tables by looking at prefixes that can be aggregated. I'm
following this discussion, because of that and I suddenly see a
'Pedro' being mentioned... Is it me? :-)

Best regards,
/PA

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 4 Oct 2012 14:25:45 +0200

> 'Pedro' being mentioned... Is it me? :-)

Nope :)

http://tools.ietf.org/id/draft-marques-idr-aggregate-00.txt

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Oct 2012 15:11:28 -0400

>    with the NO_EXPORT community.

I suspect my use of aggregated (implicit) conflicts with your use
(explicit/policy).  A recurring nightmare from working on RFC 4271 for me,
perhaps.

RFC 4271, sec 9.1.4:
:    If a BGP speaker receives overlapping routes, the Decision Process
:    MUST consider both routes based on the configured acceptance policy.
:    If both a less and a more specific route are accepted, then the
:    Decision Process MUST install, in Loc-RIB, either both the less and
:    the more specific routes or aggregate the two routes and install, in
:    Loc-RIB, the aggregated route, provided that both routes have the
:    same value of the NEXT_HOP attribute.
: 
:    If a BGP speaker chooses to aggregate, then it SHOULD either include
:    all ASes used to form the aggregate in an AS_SET, or add the
:    ATOMIC_AGGREGATE attribute to the route.  This attribute is now
:    primarily informational. [...]

No one that I'm aware of implements ATOMIC_AGGREGATE in this way.
As I pointed out many times during the standardization of 4271, your 3.4
above is effectively the same thing at a black-box perspective.  

Effectively, your bounded marking is largely what we should be doing for
ATOMIC_AGGREGATE.  The primary difference, and part of what I was alluding
to, is that if no path information is being lost, bounding is largely safe.
The partitioned AS case unfortunately is still not fully covered, but it's
better.

> proposal is optional, it is intended to facilitate the operation if you

I believe I already agreed with this point.  The primary difference is
whether the operator is aware of whether it's safe to do this or not.  When
such a process is automated, that operator safety net is removed.  It's also
problematic in the sense that the party it may cause problems for is several
hops removed.  If you're a stubby enough AS, the loss of a more specific may
deny you reachability to the network.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Oct 2012 15:28:32 -0400

> suppression of the longer route isn't going to change traffic patterns

AS 1 has 10.1.0.0/16
AS 2 has walked away with 10.1.1.0/24 

AS 1 doesn't providing routing for AS2's prefix.  
- This means that any traffic for AS 2 via AS 1 is dropped.
- This also means that AS 1 gets traffic for AS 2 in some cases, especially
  during events where AS 2's routes are dropped.  They were aware of this
  when they signed the contract to let AS 2 use that address space.

AS X receives the /16 and the /24 from upstream.  AS X bounds the /24 and
only advertises the /16.
AS Y receives only the /16 from upstream.

AS Z is dual-homed to AS X and Y.
AS Z receives the /16 from AS X and AS Y.

If AS Z chooses AS Y's /16, it has no reachability to AS 2.
If AS Y chooses AS X, everything works.

If AS X didn't implicitly aggregate the route, AS Z could use either AS X or Y.

Summary:
In cases where a subnet doesn't provide full reachability to contained more
specifics, suppressing the more specific may result in lost reachability
downstream.
a. This is less likely to be the case when the origin ASes are identical.
b. Even so, this doesn't preclude partitioned ASes.  Providers may leak the
   more specific for an internal network when internal topology isn't
   sufficiently diverse to cover certain types of outages.  See use cases for
   accepting one's own AS in an AS_PATH (junos 'loops', similar knobs in other
   implementations).
c. You'd be correct that even in cases like b, when you're "far enough
   away", implicit aggregation is probably safe again.  Such arguments have
   been used for route 'hop-limit' proposals.  The usual counter argument
   usually devolves down to Internet core-meshiness making hop-limits somewhat
   useless.

-- Jeff