On 04/11/2023 15:37, Paolo Lucente wrote:
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.
I like the idea of this.
Maybe there could be a single TLV for 'Stateless Parsing' but it
contains a new sub-type registry that is easy to add new items to
without having to rev the protocol every time there is a change, rather
than a fixed length of various reserved bits?
Also, speaking of registries and code points:
3. TLV encoding
TLVs SHOULD be sorted by the sender by their code point.
and
4.2.3. Stateless parsing TLVs
> This document also defines the following new code points to help
> stateless parsing of BGP Update PDUs:
It is recommended that any Stateless Parsing TLVs are encoded
preceeding the BGP Message TLV in order to ease parsing of the Route
Monitoring message at the BMP station side.
The document is recommending that the stateless parsing TLV should come
first, but then also says that the TLVs should be sorted by code point.
Does this mean there should be some instruction in the IANA
considerations to tell them that the stateless parsing TLV(s) must be
first in the registry list? TBD4 must be earlier than TBD1?
- Colin
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
