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
