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

[Paolo Lucente <[e-mail]>]

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, [e-mail] 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" <[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>
> 
> 
>