[j-nsp] Junos BGP update generation inefficiency -cause for concern?

[Saku Ytti]

On (2015-05-18 10:04 +0000), Adam Vitkovsky wrote:

Hey Adam,

> I'd like to ask if the "90's" way of BGP generating updates per peer-group is a cause for concern on a modern gear.
> And if not then anyways am I the only one missing some flexibility in BGP peers configuration in Junos?
> It's really annoying that every time one needs to adjust something for a peer, might even be something session related, a new peer-group has to be carved up.

Is there some efficient 2010's way you're thinking about?

Spamming same TCP datagram to multiple hosts has great efficiency benefits,
but to be able to capitalize this, you need to group neighbours who are to
receive same set of routes, or TCP messages.

Making 1 peer == 1 update-group would be easy, but it would make already hella
slow rpd lot worse.

It is best to optimize advertised routes to as few sets as possible, to gain
best benefits. I would recommend not setting export filters on per-neighbour
basis, only on group-level.
(i.e. not micro-optimize neighbours to receive exactly what is needed, if
extra routes are not actively harmful)

-- 
  ++ytti