Hi Paolo, On Wed 25 Oct 2023, 10:55, Paolo Lucente wrote: > > On 24/10/23 12:12, Luuk Hendriks wrote: > > Sec 4.2.3: > > > > Type TBD4 regarding ADD-PATH: with values 0/1 representing false/true, > > what would it mean if this TLV is not present in the message? > > Note that in the implementation notes added in path-marking-tlv-00 , one > > of the mentioned options to implicitly signal 'no path status' is to > > omit the marking TLV altogether. If we opt for that, it might be nice to > > be consistent with it here and only attach a TBD4 of length 0 (so no > > value) if a route is ADD-PATH. > > For me - and this is currently under specified - if a specific stateless > parsing TLV is not present, one should fall back to look at the BGP Open > message in the Peer Up (just like today); because this TLV is optional and > it may be that - while the implementation does support TLVs - it opts to not > support stateless parsing TLVs. > > If we agree on the above, then we need a 3 states outcome (which is not the > case for the Path Marking draft): TLV not present, fallback; if TLV is > present then explicitly say whether, for example, ADD-PATH is enabled or not > with 0/1 values. > > Thoughts?
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? Curious to hear what other people think about this. Thanks, luuk _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
