Re: [GROW] RR reflection to clients

[Gargi Nalawade <nalawade at redback.com>]

Hi Danny, All,

I agree that there are/could be efficiencies in some implementations or could be made.
We are still bound by the #BGP updates on the wire though.

Consider 3 RR-clients R1, R2, R3 advertising 3 prefixes P1, P2, P3 respectively to an 
RR. Further, R1 & R2 advertise P12, R2 & R3 advertise P23 and R3 & R1 advertise 
P31 to the RR. 

In the case you describe where the RR advertises the client routes back to the clients,
all the prefixes - P1, P2, P3, P12, P23 & P31 would be advertised in 1 packet which
gets replicated to all 3 clients (assuming all 3 are in a peer-group and the rest of the
attributes are same).

Now if we change it so that the RR does not advertise the client's own routes back to it,
the RR would end up formatting & sending - in the best case, 3 BGP updates instead of 1.

My point is - no matter what efficiencies we build into an implementation - mandating
that the RR not advertise client routes back to clients, would increase the #BGP updates 
processed by the RR and all the "n" RR-clients as well as on the wire by n-fold in the worst 
case.

-Gargi

________________________________________
From: grow-bounces at ietf.org [grow-bounces at ietf.org] On Behalf Of Danny McPherson [danny at tcb.net]
Sent: Thursday, March 26, 2009 6:23 PM
To: Iljitsch van Beijnum
Cc: grow at ietf.org grow at ietf.org
Subject: Re: [GROW] RR reflection to clients

On Mar 26, 2009, at 4:24 PM, Iljitsch van Beijnum wrote:

>
> Then again, this is only an issue for the prefixes the router itself
> sends to the RRs and then are reflected back. You mentioned some
> really large numbers in your talk which seem atypical to me: in a
> network large enough to have RRs I would assume that most routers
> are only responsible for a relatively small number of best prefixes
> in the global table. Yes, this multiplies by the number of RRs but
> then again so do all the prefixes that the router isn't considered
> best for, which require significant more resources.

Those numbers are likely to be reflective of the aggregate
set of unique prefixes (best routes) from ALL external peers
in an Internet table, as the local eBGP route is _usually
the best.

> In the case where a router would indeed get back 100k if its own
> prefixes from RRs it would make more sense to make that router a non
> client peer of the RRs and make the problem go away in that way.

I don't grok that?

> Considering all of the above and the fact that avoiding
> backreflection means breaking groupwise processing on the RRs which
> means extra processing for ALL prefixes times ALL clients for each
> RR I'd say that we shouldn't make changes here, but limit ourselves
> to documenting the issue so that vendors and operators can make sure
> the additional processing for backreflection is reduced.

So I've taken a few minutes to illustrate the problem in
a couple slides in more detail.  The PDF is available here
at the link below, and I've attached (I hope this doesn't
cause problems for anyone):

http://www.tcb.net/rr-thing.pdf

To summarize some more thoughts on this, and best
illustrated in slide 3 in the deck above:

1) all best paths learned from the client are reflected
back to the client

2) this is multiplied by the number of RRs to which that
client peers

3) client processing of updates results in placement of ALL
updates in [serialized?] BGP input processing queue with ALL
other updates {m, 1..n}

*Input processing queue typically scheduled in round robin model

4) if n is sufficiently large, many of these updates may
very well still be in the process of being learned from
the external peer(s) (r) and initial convergence function,
and processed behind extraneous reflected routes

5) Serialized processing means all Address Families likely
effected.

6) Reflected route MAY be legitimate withdraw if alternative
best previously advertised from RR - therefore it must be
processed normally IF received - this is likely one of the
more interesting bits for the RR implementer.

I believe this is AN issue that implementers should
look at.  I understand that there may be efficiencies
in some implementations to copy and it's more complex
to not reflect to client IF Originator == client RID.

-danny