That will certainly be the case most of the time.
However, the time when you really want to know will
invariably be the time when a peer did not get exactly what the rest
of the peer group got.
That's when the hurt starts and the standard vendor answer will be:
peer-groups are purely a configuration convenience.
"that's probably what was sent" doesn't cut it in troubleshooting.

Thanks,
Jakob.


> -----Original Message-----
> From: Gert Doering [mailto:[email protected]]
> Sent: Thursday, July 13, 2017 10:06 AM
> To: Jakob Heitz (jheitz) <[email protected]>
> Cc: Gert Doering <[email protected]>; Tim Evens (tievens) <[email protected]>; 
> [email protected]
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> On Thu, Jul 13, 2017 at 04:57:46PM +0000, Jakob Heitz (jheitz) wrote:
> > The problem with peer-groups is that today's high end routers
> > don't generate updates to peer-groups.
> > Peer-groups are only a convenience for configuration.
> > High end routers group peers automatically into update groups
> > and generate updates to the update group.
> > Even update groups have sub divisions to which the generated updates
> > may or may not be copied to.
> > This is done for efficient update generation with thousands of peers.
> 
> Which is an implementation detail, really.
> 
> If I configure 100 neighbours and one BMP exporter to be in "the same
> peer-group" (with the same export policy), I expect them to see the same
> prefixes, in general - except for those that are down, slow, and what
> other per-peer things might happen that shoves one of them into a different
> update groups.
> 
> If they have different export policies, I might want one "BMP exporter" per
> export policy - or inheritance group, or neighbour-group, or whatever.
> 
> ("100" is not an arbitrarily high number, it might actually be low, when
> talking about peers at major IXPs, that - with a few exceptions - all
> have the same export policy today, namely "our customer cone, except if
> the no-export-to-IXP community is set, prepend if prepend-to-IXP community
> is set")
> 
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

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

Reply via email to