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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Sep 2012 16:19:54 -0400

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

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Wed, 26 Sep 2012 08:19:32 +0200

I adhere to Jeff's view.

Pedro A. Aranda

On Tue, Sep 25, 2012 at 10:19 PM, Jeffrey Haas <[email-masked]> wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 26 Sep 2012 10:20:56 +0200

On 25/09/2012 22:19, Jeffrey Haas wrote:
>   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.

Nick