[GROW] BMP local-rib and rib-out drafts (draft-evens-grow-bmp-local-rib/adj-rib-out)

[Jeffrey Haas <[e-mail]>]

Grow Working Group,

I see that we have some timely BMP documents being presented during today's
Working Group session in Chicago.  I had considered submitting something
very similar for next IETF but I'm quite happy to say someone beat me to the
work.  However, since the BFD session has been cross-scheduled against
today's session, I'll have to give my comments here.

The encodings are, I believe, quite reasonable.  I will, however, note that
the drafts all squat on code points at the moment.  Please work with the
chairs to go through early IANA allocation.  This is particularly critical
for the peer flags field, which has scarce bits.

I would propose that an additional rib-out encoding should be specified.
While rib-out is of interest in many cases, it will often be redundant and
quite noisy for several use cases.  In BGP implementations supporting
peer-groups/update-groups, all peers in the group will receive a copy of the
same route.  Thus, I think a new message covering peer-group may be
sufficient for those cases and would significantly reduce the noise in the
system.  In cases where it is critical to know *exactly* what a peer is
getting, the per-peer version could be used.

I can send my notes on such an encoding at a later date.

There has been some desire by BMP users to know whether a given rib-in route
is a multipath contributor for BGP ECMP.  While this is technically a rib-in
feature, the discussion about how loc-rib is specified suggests it's a good
time to raise the question.

One highly important issue that these changes raise is stability of
information in the BMP data stream and prioritization of the different
message types.  Rib-in learning is already very highly noisy in BMP.
Loc-rib incremental re-convergence events will generate a similar amount of
noise, even with some amount of state compression (or I hope we're
compressing!). And more importantly, the rib out will exacerbate the amount
of noise we see in loc-rib convergence.

In many BMP use cases, rib-in state may be more important than loc-rib or
rib-out state.  In other cases, loc-rib is more important.  Thus, finding a
way to prioritize the messages may become a critical piece of procedure.

There's also some matter raised operationally about not making inferences
about event ordering of rib-in to loc-rib to rib-out based on message
ordering.  The timestamp may be most appropriate, but as noted above some
implementations that implement peer groups may not maintain things such as
advertisement time of a given prefix to a given peer.  Rib-in learning time
seems to be pretty consistently kept by most implementations I'm familiar
with.

Final point is that the procedure for loc-rib changing from the RFC is
enough that it raises backward compatibility considerations.  Since BMP is a
write-only protocol and it's not possible to negotiate such behaviors this
change might necessitate a BMP version change.

---

I hope to be able to make the BoF after the session to discuss these things
further.

-- Jeff