Hello Stephen, > which I recognize are reasonable for *some* use cases > beyond mine
Different networks have different requirements - that is true. However IETF usually attempts to address broader requirements pool.
Few comments ...
It almost adds no value in comparison with sending full BGP table without any outbound policy by add-paths option ALL so in that light it is just a duplication of different ways to accomplish the same.
>
I feel that it does add value in that my receiver application in the BMP case does not need to be a BGP protocol speaker with risk of impact to the control plane.
I wasn't proposing one. Today to parse BMP as is you need to understand attribute formats already. Adding ability to to be able to recognize BGP messages seems like an afternoon project. Same for sending the BGP OPEN with add-path capability.
If you are really concern there are hooks already which can safely drop anything what such essentially passive peer would attempt to send you.
It wasn't ignored. It was discussed, and as the proposal grew to try to encompass error cases and include timestamps, and the lack of clarity around potential for duplication of the same information between the proposed optional type and existing required types,
The existing "required" types are required by the BMP draft. Clearly it should be up to the operator to specify which types he is interesting in receiving on his monitoring station. If particular implementation does not offer such selection on what to send such implementation would need to be fixed. (And it is a very minor fix).
I preferred to recognize the progress we have made and address new requirements - which I recognize are reasonable for *some* use cases beyond mine - in a new draft.
My suggestion does not put at risk the progress made so far. It only allows operator to choose if he wants to rebuild the Adj_RIB_In and send it towards monitoring station or if he would rather select to get all information received from his peers as original BGP PDUs.
Yes we have talked about the new draft - but I completely do not see this as good idea if we are just about adding new type to entire existing BMP mechanism. Based on my IETF experience and guidelines such draft would be subject to be merged with existing BMP draft.
Best regards, R. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
