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
