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

[Russ White <[e-mail]>]

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

-- 
<><
[e-mail]
[e-mail]