I adhere to Jeff's view. Pedro A. Aranda
On Tue, Sep 25, 2012 at 10:19 PM, Jeffrey Haas <[email protected]> wrote: > 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
