Hi Ahmed,
Ack all. And to pick up about your feedback on #2: we did define some
boundaries between REL and Path Marking but, you are right, the same
work has not been done yet wrt REL and Route Mirroring - noted on my
todo list.
Paolo
On 22/01/2024 09:13, [email protected] wrote:
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
