Hi all,
Responding to
On Wed 19 Nov 2025, 03:42, Maxence Younsi wrote:
> I agree that if we're going to remove the timestamp of the per-peer
> header and make it a TLV
plus loosely quoting Paolo from his e-mail before Maxence's response:
> "making it a mandatory TLV"
If I'm interpreting both of you correctly, this would give us a
_mandatory_ TLV which _can not_ contain a timestamp of zero as per Section 2
of snts-01:
"the timestamp MUST NOT be set to zero to indicate
unavailability. The "Timestamp TLV" is optional, a timestamp
MUST NOT be included if it is not available."
Thus, implementations are forced to write at least one timestamp in the
message. Then why not keep it in the header?
Or, is the intention to allow for the flexibility as described in Sec 6
of bmp-tlv-19, where implementations can choose their best (/ most
accurate) available timestamp to put in the message? That could make
sense and presumably is an improvement over what we have today, but it
means we need to incorporate and adapt Sec 6 instead of removing it.
It might also be worthwhile hearing from vendors which types of
timestamps are feasible for them to include, and describe some
recommendations or at least considerations in the document.
> we might as well do that for the flags as well. I would actually quite
> like that. However, I think we already had some push back from Luuk
> about ignoring the flags field in v4 when we first described the Flags
> TLV in the snts draft. I'm not sure how removing it entirely would
> fly.
You guessed it, I'm not a fan of that =). To reiterate my reasoning here,
we use the currently defined flags combined with most of the other
fields in the Per Peer Header to distinguish between different rib views
(e.g. adj-rib-in post) per monitored BGP session. Having the flags local
to those other fields in the Per Peer Header, at a known position, is
more ergonomic and less error prone for us.
Thinking more generically, it's nice for a protocol to allow for quick
upfront decisions about incoming messages. Either to quickly discard,
put them in the right queue, etc. The scale of things will only go up,
and I'm afraid moving flags from a known position to a TLV 'somewhere in
the packet' might become problematic down the road.
I've been thinking whether flags could be categorised in 'key flags'
(like how we us them as per the above), and 'other flags'. If such a
distinction makes sense, I can see value in the Extended Flags TLV, but
mostly because it allows us to be explicit about that distinction, not
because of it's extending quality. For extending the size, which I fully
agree is necessary, bumping the size of the flag field in the Per Peer
Header seems easier to me. We could still have an X flag, to both be
future proof _and_ be able do the categorisation (if other people also
think that makes sense).
(Do we have a list of currently pending candidate flags btw? If not,
I'll try to inventory the active documents and think more about whether
this categorisation thing makes any sense.)
Thanks,
luuk
> Maxence
> ----- Mail original -----
> De: "Paolo Lucente" <[email protected]>
> À: "Maxence Younsi" <[email protected]>
> Cc: "Thomas Graf" <[email protected]>, "draft-ietf-grow-bmp-tlv
> authors" <[email protected]>,
> "draft-younsi-grow-bmp-snts authors"
> <[email protected]>, "grow" <[email protected]>
> Envoyé: Mercredi 19 Novembre 2025 04:14:48
> Objet: [SPAM] Re: [GROW] Re: draft-ietf-grow-bmp-tlv,
> draft-younsi-grow-bmp-snts, timestamps
>
> Hi Maxence,
>
> Indeed. One possibility could also be to remove the fields (peer flags
> and timestamp) from the common header and make them both mandatory TLVs,
> just like the BGP PDU TLV is right now.
>
> Paolo
>
>
> On 17/11/25 03:30, Maxence Younsi wrote:
> > Hi Thomas, Paolo
> >
> > Completely agree as well! If merged, what should we do with the existing
> > Timestamp field? Remove it or just deprecate and zero-fill it?
> >
> > Maxence
> > ----- Mail original -----
> > De: "Paolo Lucente" <[email protected]>
> > À: "Thomas Graf" <[email protected]>, "draft-ietf-grow-bmp-tlv
> > authors" <[email protected]>,
> > "draft-younsi-grow-bmp-snts authors"
> > <[email protected]>
> > Cc: "grow" <[email protected]>
> > Envoyé: Dimanche 16 Novembre 2025 21:26:05
> > Objet: [GROW] Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts,
> > timestamps
> >
> > Hi Thomas,
> >
> > Entirely with you on removing section 6 of draft-ietf-grow-bmp-tlv-19
> > merging the documents. +1
> >
> > Paolo
> >
> >
> > On 7/11/25 00:17, [email protected] wrote:
> >> Dear Paolo, Maxence and co-authors,
> >>
> >> Thanks for raising on the last slide at
> >> https://datatracker.ietf.org/meeting/124/materials/slides-124-grow-bmp-v2-tlv-support-01
> >>
> >> <https://datatracker.ietf.org/meeting/124/materials/slides-124-grow-bmp-v2-tlv-support-01>,
> >> the question
> >>
> >> Shall we merge draft-younsi-grow-bmp-snts?
> >>
> >> At its current stage, if been merged in the same document, we would have
> >> in BMPv4 implementation two possible variants. A BMPv4 per peer header
> >> carrying either the trigger or export timestamp or/and carry additional
> >> trigger and/or export timestamp in TLV's. None of the solution removes
> >> the timestamp from the per peer header.
> >>
> >> I suggest to remove
> >> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-19#section-6
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-19#section-6>
> >> when draft-younsi-grow-bmp-snts is being merged to reduce complexity and
> >> aim simplicity.
> >>
> >> Below the relevant references from the document.
> >>
> >> Best wishes
> >>
> >> Thomas
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-19#section-6
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-19#section-6>
> >>
> >> An event timestamp MUST always be defined. The observation timestamp
> >> SHOULD always be preferred as reference for its inherent maximum
> >> accuracy in reporting a given event; would that not be available in an
> >> implementation, the next accurate timestamp SHOULD be picked up to, as a
> >> last resort, the time at which the information was exported.
> >>
> >> https://datatracker.ietf.org/doc/html/draft-younsi-grow-bmp-snts-01#section-1
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-younsi-grow-bmp-snts-01#section-1>
> >>
> >> In this document, we deprecate the Timestamp field of the Per-Peer
> >> Header and define a Timestamp TLV that can carry multiple types of
> >> Timestamps. This allows implementations of BMP to export all the
> >> timestamps available while being explicit about the their meaning.
> >>
> >>
> >> _______________________________________________
> >> GROW mailing list -- [email protected]
> >> To unsubscribe send an email to [email protected]
> >
> > _______________________________________________
> > GROW mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> GROW mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
