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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
