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

From: Peter Schoenmaker <[email-masked]>
Date: Thu, 23 Aug 2012 13:44:47 +0800

Hello,

At IETF in vancouver we had a presentation from Russ White for a new working
group item draft-white-grow-overlapping-routes-00.  I would like to gauge
the working group interest in adopting this draft as a working group item.
Can people please voice their approval or disapproval.

Thanks

Peter

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 Aug 2012 15:12:07 +0100

On 23/08/2012 06:44, Peter Schoenmaker wrote:
> At IETF in vancouver we had a presentation from Russ White for a new
> working group item draft-white-grow-overlapping-routes-00.  I would like to
> gauge the working group interest in adopting this draft as a working group
> item.  Can people please voice their approval or disapproval.

I'm concerned by a lot of statements in this draft, particularly:
	
> Overall, then, it is desirable to remove overlapping routes from the
> global routing table where possible.

People inject prefixes into the DFZ for specific reasons.  If they are
pruned by some upstream providers but not others, then the traffic
engineering model is broken because you can no longer depend on
more-specifics having visibility around the dfz.  Or am I reading this
incorrectly?

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Aug 2012 18:06:59 +0200

Hi Nick,

> more-specifics having visibility around the dfz.  Or am I reading this

You are very correct. In fact there is documented prior attempt to only 
remove more specifics where they do not matter any longer for routing. 
The key is to adjust the removal/suppression location to the dynamic 
topology of the inter-network.

http://www.watersprings.org/pub/id/draft-marques-idr-aggregate-00.txt

Otherwise I think we can do more harm then good.

Best,
R.

---

From: William Herrin <[email-masked]>
Date: Thu, 30 Aug 2012 21:59:40 -0400

> Can people please voice their approval or disapproval.

Hi Peter,

What am I missing? The last few times this was discussed here or on
RRG, RIB aggregation fell apart on the details. For example, what
happens when:

AS1 announces 10.1.0.0/16 from network A via ISP 1 and 2
AS1 announces 10.1.33.0/24 from network B via ISP 3 and 4

If the answer is: AS1 disaggregates 10.1.0.0/16 in order to avoid
overlapping 10.2.33.0/24 because at least a couple folks implementing
overlapping-routes broke network B then what is there to discuss?

Regards,
Bill Herrin

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

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 30 Aug 2012 22:03:23 -0400

> What am I missing? The last few times this was discussed here or on

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.

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

---

From: William Herrin <[email-masked]>
Date: Thu, 30 Aug 2012 22:44:20 -0400

> contains/explains) should show up as a working-group work item.

Hi Christopher,

Well, unless one of the authors wants to step up and say, "Bill, we
anticipated the problem you posed and this is how we cleverly got
around everything like it," I'd have to say thumbs down on adopting it
for discussion and work. Recommend the authors pore through the RRG
archives for a history lesson in all the myriad approaches to RIB
aggregation that are known to not work. If aggregating overlaps isn't
the most popular non-working approach it's surely the second most
popular.

That, by the way, would make a great draft: a canonical list of the
approaches considered for RIB aggregation and the key faults
identified with each. So that the next guy doesn't have to pore
through the RRG archives and, when somebody does find a novel idea, he
can explicitly point out that, "This is why it doesn't suffer the
fault identified in RFC X section 8."

Regards,
Bill Herrin