Subject: [GROW] Comments on draft-ietf-grow-va-06

From: Russ White <[email-masked]>
Date: Thu, 17 May 2012 08:21:10 -0400

Y'all:

I finally got around to rereading this draft, so I could make some
intelligent comments on it. But before I begin, let me make a comment on
the process here...

There are three drafts I know of in this space. Two of them have
expired, but I've recently received emails about reviving them. None of
these drafts require changes to BGP's operation on the wire, however. It
seems, to me, that there's no reason for GROW to actually prefer one
solution over another. In fact, it seems like there's no reason not to
publish all the "non-overlapping" ideas, and let vendors and operators
choose which one they prefer to implement & deploy.

I'll leave this point open for discussion, and move to my comments on
this draft in particular.

==
The first thing to note is this draft specifically attacks FIB table
size without modifying the routing table size. Since I'm not convinced
that FIB size, as opposed to the on-the-wire table size, is a problem
that needs to be addressed, I'm not certain about the overall utility of
the mechanism outlined here.

Is there any reason to suspect that forwarding table size is "the"
problem in hand?

==
The core idea behind
FIB suppression is to run BGP as normal, and in particular to not
shrink the RIB, but rather to not load certain RIB entries into the
FIB.  This approach minimizes changes to routers, and in particular
is simpler than more general routing architectures that try to shrink
both RIB and FIB.

Is this really a good idea? I will now have two different control plane
tables, one ostensibly built from the other, which do not match. While
this might not be a problem for the router, it would be a wee bit of a
problem at 2am when I'm trying to troubleshoot some network traffic flow
problem, or a routing problem. Ping and traceroute are no longer
reliable indicators of forwarding table state through the network --not
a good thing, IMHO.

==
On the increase in stretch...

While I realize aggregation always causes increases in stretch, it seems
like this draft would increase stretch precisely where other drafts are
trying to reduce it by increasing the amount of information BGP sends. I
suppose different situations might call for different design parameters,
but I don't see how this draft would allow for shorter paths through
multiple BGP advertisements in parallel with reduced state (both
deployed at the same time).

Maybe the authors would care to add a section discussing how these
things would work together.

==
In other words, even if an ingress
router is not an APR for a given sub-prefix, it MAY install that sub-
prefix into its FIB.  Packets in this case are tunneled directly from
the ingress to the BGP NEXT_HOP.  These extra routes are called
"Popular Prefixes", and are typically installed for policy reasons

I'm not certain how these "popular prefixes" will actually work in
practice. Wouldn't it be a requirement that every router in AS have the
same list? It might be worth addressing this situation in some way
within the draft.

==
How would this interact with traffic engineering? Since this uses MPLS
tunnels to get traffic around to aggregation points, wouldn't this at
least overlap with other uses of MPLS in the same network? Again, it
seems like it might be worth making some comments on this in the draft.

==

I find this draft introduces a lot of complexity for the amount of gain
it provides. While the end result in theory might be a really high level
of aggregation within the provider's network, the reality of increased
stretch would probably mean most networks end up only gaining some lower
amount of savings in real forwarding table size reductions --and I'm not
certain the savings are where providers really need them.

I suppose this might be a good fit for some L3VPN deployments, but there
a provider might find the increased stretch causes his network to be
much slower at the savings of a small number of control plane entries,
and and the cost of increased TE complexity.

So, overall, I'm not certain of the value for complexity tradeoff here.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 May 2012 20:21:10 +0700

On May 17, 2012, at 7:21 PM, Russ White wrote:

> Is there any reason to suspect that forwarding table size is "the" problem in hand?

The are concurrent and inter-related problems, IMHO - the idea behind any proposed solution(s) should be that solving for one will also solve for the other, to the extent(s) applicable and possible.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 May 2012 14:35:01 +0100

> Is there any reason to suspect that forwarding table size is "the"

As an operator who needs to juggle between upgrade costs and actually
running a network, I'd tend to be of the opinion that it sucks to retire a
router from dfz operation because of fib size constraints.

There are hacks to deal with on-the-wire size.  They are probably uglier
that virtual aggregation, and certainly messier to maintain.

Nick

---

From: Russ White <[email-masked]>
Date: Thu, 17 May 2012 09:59:24 -0400

> There are hacks to deal with on-the-wire size.  They are probably
> uglier that virtual aggregation, and certainly messier to maintain.

Are you familiar with IRS, or any of its variants? Do you think the
operational aspects of this draft, in terms of MTTR, are okay?

Russ

-- 
<>< Scripture Alone, Grace Alone, Faith Alone
http://thinkinginchrist.com/

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 May 2012 15:49:02 +0100

On 17/05/2012 14:59, Russ White wrote:
> Are you familiar with IRS, or any of its variants? 

Nope - can you provide a reference?  My google-fu is failing.

> Do you think the

I can't answer this question until I see the protocol in operation.  Given
suitable visibility into what's happening with the collapsed routing
structure, I don't really see a problem.  Like most other things, what's
important is how much visibility the operator gets into what's going on, so
that problems can be debugged.

Nick