Hi Mike,
Thanks for your comment & i just now realize i missed your previous
email - apologies for that. Thanks for your support to the draft, much
appreciated.
Thanks also for your input about supplementary information for the
"Policy Discard" code / use-case for REL. Would you be happy with just
the routing policy? (And leaving as an exercise for me to understand how
to best identify a routing policy [name, id, other]). Like you said,
doing something useful yet remaining generic enough, is the key here
(for example previous drafts tried to get into the nuts and bolts of
routing policies resulting in a complex and non-generic proposal that
failed to get traction).
Paolo
On 8/9/23 10:23, Booth, Mike wrote:
Hi,
After seeing Paolo’s talk at IETF117 on BMP REL, I have some comments:
I like the idea of adding RPKI status to the BMP message, currently its
possible get the same functionality by adding the RPKI status in post
processing eg. in PMACCT.
The RPKI status is checked against a route on the router as a routing
policy, between Adj-Rib-Pre and Adj-Rib-Post. I would also like to see
more generic supplementary information in the BMP such as which routing
policy caused a rejection stopping a route being accepted.
This seems to me similar to adding the RPKI-OV status to the BMP.
Michael,
On 08/03/2023, 00:55, "Paolo Lucente" <[email protected]> wrote:
Hi Luuk,
Thanks for your feedback & support to this draft. Inline:
On 17/1/23 10:54, Luuk Hendriks wrote:
> [ .. ]Hi Paolo, all,
>
> Having said that, some thoughts on the -00:
>
> Sec 3.2:
> Do we need to reuse the entire BGP UPDATE PDU, or can we only reuse NLRI
> encoding? The overhead of especially the 16 byte marker, but also the
> message type, (perhaps the message length), the Withdrawn Routes Length,
> that all seems a bit excessive and unnecessary.
> I do agree we should not reinvent the wheel when it comes to the NLRI
> encodings and their existing support in BGP. We'll need the AFI/SAFI for
> that, so the MP_REACH_NLRI attribute format seems like a good choice,
> though perhaps without the Next Hop and the Reserved byte? (I think in
> MRT something similar happens, but I'd have to double check.)
My thinking with going for the entire BGP Update PDU was that we can
re-use existing / validated code on both the export and collection
sides, making it easier to adopt this in practice. Sure, at the expense
of being slightly less optimal on the wire.
Indeed, would you have some proposal / example from MRT, i'd be more
than happy to familiarize with it. Although probably before getting
concrete about optimizations, we should first nail down where we want to
take this draft to.
> Re point 2 in your mail, you mention that we perhaps want to be able to
> export other message types besides the UPDATE PDU. Whichever way this
> goes, I think we need to minimise possible confusion between what is
> exported verbatim (i.e. an exact copy of a PDU that has been observed on
> the wire), vs a synthesized/constructed message, mimicking a BGP PDU
> that looks like it could have been sent over the wire but actually never
> was.
Ack & agree.
Paolo
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
