Re: [GROW] draft-ietf-grow-bmp-rel - Handling RFC7606 events

[[e-mail]]

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" <[e-mail] <mailto:[e-mail]>> 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, [e-mail] <mailto:[e-mail]> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>