Hi Paolo, Thank you for capturing my intent.
1. Yes, I agree on the first point about adding more code points to path marking TLVs. 2. For making BGP PDU TLV optional, I think that could be a good way to go .. but it just a hunch. The reason I'm still not sure is: Reading into the draft-ietf-grow-bmp-rel, it implies in Section 3.2 that the BGP PDU could be artificial, however in the parsing error cases, probably BMP Route Mirroring could a be a better approach to capture these malformed packets. I don't know yet how to make the best of these two approaches. Best, -Ahmed On 22.01.2024, 03:07, "Paolo Lucente" <[email protected] <mailto:[email protected]>> wrote: Be aware: This is an external email. Hi Ahmed, Thanks for your comment & agree on the importance of having these captured. I think Path Marking and REL are the places where these markings / events would be appropriately reported for. Also, being REL definition only at its beginning, we can adjust to fit any additional use-case. Should i properly decode your underlying ask, i may read a couple of things: 1) if some withdraws are issued, like for cases #2 and #3, we should have the code-points in draft-ietf-grow-bmp-path-marking-tlv 2) Probably the structure of the REL message should be made more flexible: it now requires a BGP PDU TLV for every event whereas maybe for certain events that would fall more under the feedback-loop use-case than the insight one (like #1 and #4), a BGP PDU may not be required Thoughts? Paolo On 12/01/2024 14:57, [email protected] <mailto:[email protected]> wrote: > Hello all, > > I’ve been going over draft-ietf-grow-bmp-rel and it does provide an > excellent way to provide additional visibility into the BGP process. > > However, I noticed it doesn’t cover the cases in RFC 7606. RFC 7606 > refines that update error handling in RFC 4271 and classifies update > errors handling approaches into 4 categories: > > 1. Session Reset (as original in RFC 4271 and that will be caught in > BMP using the BGP Notification message) > 2. AFI/SAFI disable > 3. Treat-as-withdraw > 4. Attribute-discard > > My guess for cases 2 and 3, if local rib monitoring is enabled BMP will > report a withdraw, without a reason of why. For case 4, not sure if that > will be reported in BMP. > > Probably these events need to be monitored by BMP, since they impact the > routing and can be silent (except vendor specific logging). I’m not sure > if draft-ietf-grow-bmp-rel is the best place or we need an additional > document to expand further the list of supported events, any feedback is > welcome. > > Best, > > -Ahmed > > > _______________________________________________ > GROW mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow > <https://www.ietf.org/mailman/listinfo/grow> _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
