Hi Luuk,
Inline:
On 1/11/23 14:48, Luuk Hendriks wrote:
[ .. ]
That makes sense, but I am a bit on the fence about this TLV being
optional and the fallback scenario. Is there enough incentive to
implement this TLV on the router side, or will this be a nice idea on
paper while in reality BMP station software will have to use the
fallback 99.9% of the time so there is none of the envisioned benefit and
perhaps even an increased computational cost (albeit small)?
Moreover, all of this applies to the Multiple Labels capability (TBD5)
as well. When these both are optional, the BMP station has to check for
their presence individually, and do the fallback trick for zero, one, or
both of them.
But making these TLVs mandatory feels a bit too strong and/or
inflexible. I'm wondering whether TBD4 and TBD5 should be combined in a
single, optional TLV: if present, it contains all information you need
for stateless parsing (i.e. for now that's ADD-PATH and Multi Label);
without such TLV, fallback, for everything.
It is a bit less flexible than separate TLVs, but probably more
straightforward to implement (presumably on both sides of the BMP
stream) and reason about?
I am total open to such an idea, the one TLV of Stateless Parsing where
we assign bits as needed to capabilities we want to track down. It will
reduce the flexibility a bit like you say - which is not necessarily a
bad thing, as it would reduce complexity on the encoding / decoding side.
Me too i am curious if there are any different opinions about if; if
not, i'd go for this resolution in the next revision of the draft.
Paolo
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
