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

[Jakob Heitz (jheitz)]

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).

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.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, July 12, 2017 8:14 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)
> 
> Tim,
> 
> On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> > The use-case to monitor Adj-RIB-Out for a peer-group is definitely 
> > something this draft
> > addresses but appears to need more clarification.
> >
> > 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.  I believe this can be addressed by adding "Other 
> > Considerations" section to
> > explain how one should go about using adj-rib-out.  For example, in the 
> > use-case of monitoring
> > peer-group egress policy advertisements, which is what I believe you are 
> > addressing with your
> > comment, the operator should configure at least two reliable peers in a 
> > group
> > to be monitored. This provides redundancy should one peer fail.
> 
> I had considered this as one of the possibilities.  However, if the actual
> use case is to simply see what's sent to the group, why not simply get rid
> of the per-peer need in the first place?  This avoids the somewhat hack of
> "picking reliable peers".
> 
> > This would easily provide peer-group
> > level conveyance of the egress policy. What's missing is the peer-group 
> > name so that on
> > the receiving side we can correlate (group) the peers that represent the 
> > same peer-group.
> > Providing we have the group name for the peer, the receiver can group the 
> > peers that have the same
> > group name.  If the use-case is only to monitor the peer-group policy, not 
> > specific overrides per peer,
> > then the receiver can easily de-dup the X (redundant) peers for a single 
> > representation of the peer-group.
> 
> This potentially gets to one of the case Jakob had mentioned wherein
> something might be part of a peer group, but may have radically different
> "per peer" behavior in some implementations.  By comparison, Junos does only
> minor alterations per-peer outside of the high level export policy.
> 
> If we consider two group cases: Pure group, some per-peer, then we have two
> possible ways of handling this as part of wire encoding:
> 1. Emit only per-group RM messages
> 2. If there's per-peer variance of sufficient interest, emit peer specific
>RM messages.
> 
> > This is use-case specific as there are use-cases where we need to still 
> > monitor each peer even if they are
> > part of the same peer/update group.
> >
> > In either case, this is really a receiver knob to correlate based
> > on intended operator configuration/deployment.  Although we do need the 
> > peer-group advertised as part
> > of the PEER INFO TLV, which we talked about at the BoF.  This was meant to 
> > be added, but I forgot to
> > add that.
> 
> Thanks. Since I wans't able to attend the full BoF, I don't recall if this
> had been part of the disucssion.
> 
> > Based on your proposal statements, it seems that this is only a method to 
> > correlate/map peers,
> > peers that still need PEER_UP/per-peer RM messages, into a group.
> 
> Largely correct.  Although I think you've made a good argument that a
> simpler way of providing the group mapping is to simply put it into the
> information message as part of the peer-up message.
> 
> >  IMO, this complicates
> > both the implementation (router/sender) and the receiver unnecessarily 
> > considering we can accommodate
> > this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
> > for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By 
> > adding
> > a PEER_UP info TLV to convey peer/update group name enables the receiver to 
> > easily correlate
> > peers that belong to the same group.
> 
> I'd find that a reasonable mapping mechanism.
> 
> >  How we treat and understand those peers is very much specific to the
> > operator configuration/deployment/implementation on the receiver side.   
> > The operator can
> > decide if they just need one peer per peer-group or if they want fault 
> > tolerance by including more peers.
> 
> I disagree with this case for the reasoning above.  I think if the per-peer
> case was kept as the per-group monitoring mechanism, it'd eventually
> degenerate down to the "fake peer" 

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

[Jeffrey Haas]

Tim,

On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> The use-case to monitor Adj-RIB-Out for a peer-group is definitely something 
> this draft
> addresses but appears to need more clarification. 
> 
> 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.  I believe this can be addressed by adding "Other 
> Considerations" section to
> explain how one should go about using adj-rib-out.  For example, in the 
> use-case of monitoring
> peer-group egress policy advertisements, which is what I believe you are 
> addressing with your
> comment, the operator should configure at least two reliable peers in a group
> to be monitored. This provides redundancy should one peer fail.

I had considered this as one of the possibilities.  However, if the actual
use case is to simply see what's sent to the group, why not simply get rid
of the per-peer need in the first place?  This avoids the somewhat hack of
"picking reliable peers".

> This would easily provide peer-group
> level conveyance of the egress policy. What's missing is the peer-group name 
> so that on
> the receiving side we can correlate (group) the peers that represent the same 
> peer-group. 
> Providing we have the group name for the peer, the receiver can group the 
> peers that have the same
> group name.  If the use-case is only to monitor the peer-group policy, not 
> specific overrides per peer,
> then the receiver can easily de-dup the X (redundant) peers for a single 
> representation of the peer-group.

This potentially gets to one of the case Jakob had mentioned wherein
something might be part of a peer group, but may have radically different
"per peer" behavior in some implementations.  By comparison, Junos does only
minor alterations per-peer outside of the high level export policy.

If we consider two group cases: Pure group, some per-peer, then we have two
possible ways of handling this as part of wire encoding:
1. Emit only per-group RM messages
2. If there's per-peer variance of sufficient interest, emit peer specific
   RM messages.

> This is use-case specific as there are use-cases where we need to still 
> monitor each peer even if they are 
> part of the same peer/update group.  
> 
> In either case, this is really a receiver knob to correlate based
> on intended operator configuration/deployment.  Although we do need the 
> peer-group advertised as part
> of the PEER INFO TLV, which we talked about at the BoF.  This was meant to be 
> added, but I forgot to
> add that.

Thanks. Since I wans't able to attend the full BoF, I don't recall if this
had been part of the disucssion.

> Based on your proposal statements, it seems that this is only a method to 
> correlate/map peers, 
> peers that still need PEER_UP/per-peer RM messages, into a group.

Largely correct.  Although I think you've made a good argument that a
simpler way of providing the group mapping is to simply put it into the
information message as part of the peer-up message.

>  IMO, this complicates 
> both the implementation (router/sender) and the receiver unnecessarily 
> considering we can accommodate
> this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
> for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By 
> adding
> a PEER_UP info TLV to convey peer/update group name enables the receiver to 
> easily correlate
> peers that belong to the same group.

I'd find that a reasonable mapping mechanism.

>  How we treat and understand those peers is very much specific to the 
> operator configuration/deployment/implementation on the receiver side.   The 
> operator can
> decide if they just need one peer per peer-group or if they want fault 
> tolerance by including more peers.

I disagree with this case for the reasoning above.  I think if the per-peer
case was kept as the per-group monitoring mechanism, it'd eventually
degenerate down to the "fake peer" case that is always up.  Such a hack
could easily be done today but is clumsy for operators to analyze since
they'd have to track that said "fake peer" is in fact not real.
(E.g. use a class E address.)

-- 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)

[Paolo Lucente]

> On 12 Jul 2017, at 02:57, Tim Evens (tievens)  wrote:
> 
> [TE] IMO, limitations around transmission of X number of peers with *-rib-* 
> monitoring should be BMP
> sender implementation specific.  I do not believe anyone in their right mind 
> would configure a platform/sender
> for *-rib-* on all peers, but you never know. This is why limits should 
> exist, a line in the sand,
> for the platform.   Limits that apply to one platform are not necessarily 
> required to be applied to another.
> We want to enable the ability to monitor the five collection points of BGP 
> (Adj-RIB-In/pre, Adj-RIB-In/post,
> Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the 
> platform can't restrict combinations.

I indeed support this. We should de-couple standardisation, which should take 
into account the different possibilities (which appear to be on the low 
numbered side anyways), from implementation, where things will hit 
platform-specific limits, constraints and caveats (.. and, well, customer 
demand). Connecting all of this to the ongoing per-peer vs peer-group 
discussion, i’d say there should not be a “vs” but provision for both 
alternatives in the draft - then implementors will figure out the specific bits 
to their platform(s). Why choose upfront and make this one yet another nice 
effort but with “some limits"? It seems to me we are precisely coming from that 
and trying to fix it.

Paolo


___
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)

[Job Snijders]

On Wed, Jul 12, 2017 at 12:57:31AM +, Tim Evens (tievens) wrote:
> On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas"  on behalf of jh...@pfrc.org> wrote:
> > In such cases - use the per peer rib-out.  I do believe it has good
> > use cases.  However, discussions with our customers have suggested
> > that in most cases it's excessively chatty and threatens to swamp
> > the rib-in portion of the control channel they're actually
> > interested in.  For them, a general indication of rib-out content is
> > sufficient, even when there's some minor variations with
> > specifications they may be comfortable with.
> > 
> [TE] IMO, limitations around transmission of X number of peers with
> *-rib-* monitoring should be BMP sender implementation specific.  I do
> not believe anyone in their right mind would configure a
> platform/sender for *-rib-* on all peers, but you never know.

I wouldn't be so quick to dismiss that from happening, nor frown upon
it. It actually might be one of the first things I'd do when debugging
an issue. And since quite some debugging is 'after the fact', it makes
sense to permanently monitor at least Adj-RIB-In and Adj-RIB-Out for
each peer.

> BGP is big data, like IPFIX in that sense, and therefore should get
> some engineering love, not willy-nilly turn it on everywhere and hope
> for the best. 

I agree with you that BGP might be 'a lot of data' but storage space is
cheap, so if the edge routers can send it I'll store it and keep it. I'm
tired of flying blind. Also, I am not sure how I can select up front
what BGP data I will keep, aggregate or throw away. To do proper triage
on BGP hijacks we'll need per-prefix per-update granularity.

Kind regards,

Job

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