Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jakob Heitz (jheitz) 
Then the same is true for RIB-in.
Since every RIB-out matches a RIB-in somewhere else,
the input must equal the output in the aggregate.
Unless BGP leaks... :)

Thanks,
Jakob.


> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Thursday, July 13, 2017 7:16 PM
> To: Jakob Heitz (jheitz) 
> Cc: Gert Doering ; grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> On Thu, Jul 13, 2017 at 08:43:27PM +, Jakob Heitz (jheitz) wrote:
> > 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.
> 
> Two observations:
> - This argument eventually degenerates into "you need to monitor the rib-out
>   of every single peer".
> - Due to state compression of the BMP feed vs. the BGP feed, you're going to
>   lose stuff anyway.
> 
> I believe anyone expecting *any* implementation of BMP for rib-out to be a
> perfectly stateful match for their announced BGP has unrealistic
> expectations.
> 
> -- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jeffrey Haas 
On Thu, Jul 13, 2017 at 08:43:27PM +, Jakob Heitz (jheitz) wrote:
> 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.

Two observations:
- This argument eventually degenerates into "you need to monitor the rib-out
  of every single peer".
- Due to state compression of the BMP feed vs. the BGP feed, you're going to
  lose stuff anyway.

I believe anyone expecting *any* implementation of BMP for rib-out to be a
perfectly stateful match for their announced BGP has unrealistic
expectations.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jeffrey Haas 
On Thu, Jul 13, 2017 at 04:57:46PM +, 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.

I did note potential distinctions in implementations when I kicked off this
mail chain. :-)

By direct comparison in Junos, peers A, B and C may be part of the same
configured group, but may be split into distinct groups if they don't share
policy.  Thus, in our implementation, they're report those distinct
mappings.  In our case, distinct group IDs sharing the same group name.

Whether this is applicable for your implementation is unclear.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jakob Heitz (jheitz) 
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:g...@space.net]
> Sent: Thursday, July 13, 2017 10:06 AM
> To: Jakob Heitz (jheitz) 
> Cc: Gert Doering ; Tim Evens (tievens) ; 
> grow@ietf.org
> 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 +, 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 AGVorstand: 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Gert Doering 
Hi,

On Thu, Jul 13, 2017 at 04:57:46PM +, 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 AGVorstand: 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


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jakob Heitz (jheitz) 
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.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Gert Doering
> Sent: Thursday, July 13, 2017 1:02 AM
> To: Tim Evens (tievens) 
> Cc: grow@ietf.org
> 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 Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> > Noisy and likely duplicate/wasteful, yes??? if one configures every peer to 
> > send Adj-RIB-Out
> > for peers that convey the same data, to which is likely not what folks will 
> > do or what I would
> > recommend doing.
> 
> The use case I have is "I want to see how routes from customer  end
> up being sent to DECIX" - which technically is a peer-group with 100+
> peers in.
> 
> Monitoring a given peer is not really useful here (that peer could be
> down) - monitoring *all* peers will give way more data than I want (I can
> collapse it again afterwards, but why eat up CPU etc. for no benefit).
> 
> So "peer group" is exactly matching my use case.
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jeffrey Haas 
On Thu, Jul 13, 2017 at 01:27:38PM +, Jakob Heitz (jheitz) wrote:
> What is this "approximate state"?
> Why does a sample peer not give you approximate state?

You just gave multiple examples of when the peer might not be good enough.
I'm unclear why you're asking the question.

Simple examples:
Basic ibgp, no policy.  Monitoring the rib-out per group is likely good
enough.  Same for reflection.  Likely the same for ebgp confederation peer.

Basic ibgp for L3VPN.  Monitoring the rib-out per group is probably good
enough, even with rt-constrain.  Can you tell which peers got the update or
not?  Not with the encoding discussed.  But you can tell what the state
advertised is.  But in such cases you're really better off looking at rib-in
state on the receiver anyway.

For ebgp in the same peer group?  Possibly good enough as long as you don't
care about the per-nexthop or potentially community changes.  If the ebgp
peers are also yours to monitor, the rib-in is sufficient.  If they're not,
then go per-peer.

> Why does loc-rib not give you approximate state?

Because it doesn't give you the results of export policy on your peer group?
(Otherwise we wouldn't be discussing a rib-out feature...)

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jakob Heitz (jheitz) 
What is this "approximate state"?
Why does a sample peer not give you approximate state?
Why does loc-rib not give you approximate state?

Thanks,
Jakob.


> On Jul 13, 2017, at 3:51 AM, Jeffrey Haas  wrote:
> 
> Jakob,
> 
>> On Wed, Jul 12, 2017 at 10:48:28PM +, Jakob Heitz (jheitz) wrote:
>> Here are some more factors that cause different updates to peers in the same 
>> peer-group:
>> - RT Constraint: This filters different updates from different peers.
>> - Refresh requests: Only the peer that sent the request receives the updates.
>> - Nexthop SAFI (future).
> 
> You missed simple BGP loop detection such as RRs with cluster list or
> originator ID suppression for iBGP or AS_PATH for eBGP.
> 
>> IMO, the point of BMP is to take the guess work out of figuring out what was 
>> sent.
>> Peer-groups will add more guess work.
> 
> Much of my point is that even without complicated features, if you care
> about per-peer state, you have to monitor *ALL* of the peers.  Otherwise,
> you're going to miss things.  There's no "monitor one or two sample peers".  
> 
> You either care about the approximate state of the peers in the group or you
> care about the exact state.  The use cases are different.
> 
> -- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Jeffrey Haas 
Jakob,

On Wed, Jul 12, 2017 at 10:48:28PM +, Jakob Heitz (jheitz) wrote:
> Here are some more factors that cause different updates to peers in the same 
> peer-group:
>  - RT Constraint: This filters different updates from different peers.
>  - Refresh requests: Only the peer that sent the request receives the updates.
>  - Nexthop SAFI (future).

You missed simple BGP loop detection such as RRs with cluster list or
originator ID suppression for iBGP or AS_PATH for eBGP.

> IMO, the point of BMP is to take the guess work out of figuring out what was 
> sent.
> Peer-groups will add more guess work.

Much of my point is that even without complicated features, if you care
about per-peer state, you have to monitor *ALL* of the peers.  Otherwise,
you're going to miss things.  There's no "monitor one or two sample peers".  

You either care about the approximate state of the peers in the group or you
care about the exact state.  The use cases are different.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

2017-07-13 Thread Gert Doering 
Hi,

On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> Noisy and likely duplicate/wasteful, yes??? if one configures every peer to 
> send Adj-RIB-Out
> for peers that convey the same data, to which is likely not what folks will 
> do or what I would
> recommend doing.  

The use case I have is "I want to see how routes from customer  end
up being sent to DECIX" - which technically is a peer-group with 100+
peers in.

Monitoring a given peer is not really useful here (that peer could be 
down) - monitoring *all* peers will give way more data than I want (I can
collapse it again afterwards, but why eat up CPU etc. for no benefit).

So "peer group" is exactly matching my use case.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow