On Thu, Aug 30, 2012 at 10:03:23PM -0400, Christopher Morrow wrote:
> you're probably not missing anything in particular, except that you
> didn't state whether or not the doc (or the ideas that the doc
> contains/explains) should show up as a working-group work item.
I'm not in favor of this being adopted as a WG document. While I have great
sympathy for the problem being solved, I have several concerns with the
practice. (I do, however, support a document detailing the problem space as
suggested in another document.)
To briefly summarize a few of my concerns:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. :-)
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.
-- Jeff
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
