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