Hi Maxence, I agree, assuming I understood correctly and you want to make the stateless parsing TLV for this capability also mandatory.
Sorry for the delay, took me a while to find time to check Cheers, Leonardo -----Original Message----- From: Maxence Younsi <[email protected]> Sent: Wednesday, 26 November 2025 04:04 To: Rodoni Leonardo, SCS-INI-NET-VNC-E2E <[email protected]> Cc: luuk <[email protected]>; Paolo Lucente <[email protected]>; Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; draft-ietf-grow-bmp-tlv authors <[email protected]>; draft-younsi-grow-bmp-snts authors <[email protected]>; grow <[email protected]> Subject: Re: [GROW] Re: [SPAM] Re: Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts, timestamps Be aware: This is an external email. Hi Leonardo, I think this flag actually has meaning only for RM but that should not be an issue since the Stateless Parsing TLV is made for RM messages right? Or am I missing something? Best, Maxence ----- Mail original ----- De: "leonardo rodoni" <[email protected]> À: "Maxence Younsi" <[email protected]> Cc: "luuk" <[email protected]>, "Paolo Lucente" <[email protected]>, "Thomas Graf" <[email protected]>, "draft-ietf-grow-bmp-tlv authors" <[email protected]>, "draft-younsi-grow-bmp-snts authors" <[email protected]>, "grow" <[email protected]> Envoyé: Vendredi 21 Novembre 2025 16:46:34 Objet: RE: [GROW] Re: [SPAM] Re: Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts, timestamps Hi Maxence, I'm not sure about it, from https://datatracker.ietf.org/doc/html/rfc7854#section-4.2the seems the flag has also meaning for RM messages e.g. when as_path is reformatted from 2 to 4-byte by the router, do I misunderstand something? Cheers, Leonardo -----Original Message----- From: Maxence Younsi <[email protected]> Sent: Thursday, 20 November 2025 10:01 To: Rodoni Leonardo, SCS-INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; Paolo Lucente <[email protected]>; Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; draft-ietf-grow-bmp-tlv authors <[email protected]>; draft-younsi-grow-bmp-snts authors <[email protected]>; grow <[email protected]> Subject: Re: [GROW] Re: [SPAM] Re: Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts, timestamps Be aware: This is an external email. Hi Leonardo, You raise a good point for the A flag, should that flag actually be removed in v4? I think this flag is just giving information about BGP Capabilities used to encode the BGP PDU. Shouldn't that be handled by the Stateless Parsing TLV only to avoid ambiguities? Maxence ----- Mail original ----- De: "leonardo rodoni" <[email protected]> À: [email protected], "Maxence Younsi" <[email protected]>, "Paolo Lucente" <[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é: Jeudi 20 Novembre 2025 17:10:36 Objet: RE: [GROW] Re: [SPAM] Re: Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts, timestamps Hi all, I agree with the idea of making the timestamp TLV mandatory while removing timestamp from the header. From a bmp collector perspective, it's clearer and makes our life easier as we do not need any fallback logic for the event time anymore. About also removing the flags however I'm skeptical, especially because they provide context for parsing the BGP pdu (AS_PATH format flag), and moving that down in the tlv list will be less ideal. Cheers, Leonardo -----Original Message----- From: Luuk Hendriks <[email protected]> Sent: Wednesday, 19 November 2025 12:34 To: maxence.younsi <[email protected]> Cc: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; draft-ietf-grow-bmp-tlv authors <[email protected]>; draft-younsi-grow-bmp-snts authors <[email protected]>; grow <[email protected]> Subject: [GROW] Re: [SPAM] Re: Re: draft-ietf-grow-bmp-tlv, draft-younsi-grow-bmp-snts, timestamps Be aware: This is an external email. 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://d/ > >> atatracker.ietf.org%2Fmeeting%2F124%2Fmaterials%2Fslides-124-grow-b > >> mp-v2-tlv-support-01&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com% > >> 7Cd9f54d9a99134cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b557 > >> a1%7C0%7C0%7C638991488701786215%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > >> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bOPqD6r%2FOt63XuZVBAbCEB7M%2Biuag > >> 3zq8hmqg3B4fI8%3D&reserved=0 > >> <https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> datatracker.ietf.org%2Fmeeting%2F124%2Fmaterials%2Fslides-124-grow- > >> bmp-v2-tlv-support-01&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com > >> %7Cd9f54d9a99134cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b55 > >> 7a1%7C0%7C0%7C638991488701825864%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > >> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bBlWECqHlXY8vHcgf56VlLFkH%2FmHyu > >> 8H7KvLs0o7wBM%3D&reserved=0>, 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://d/ > >> atatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-19%23sec > >> tion-6&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com%7Cd9f54d9a9913 > >> 4cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C6 > >> 38991488701877577%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > >> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > >> %7C0%7C%7C%7C&sdata=ndyQJEDJpKTtX16N7QMjwP%2FdZHTIAZlXMcMXYmICuG0%3 > >> D&reserved=0 > >> <https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-19%23se > >> ction-6&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com%7Cd9f54d9a991 > >> 34cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C > >> 638991488701892872%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > >> D%7C0%7C%7C%7C&sdata=RnEIsD5%2FjUVfGHP3WmtrSWy0vOyNSJXgUcaRENAY1yE% > >> 3D&reserved=0> > >> > >> 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://d/ > >> atatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-younsi-grow-bmp-snts-01%23 > >> section-1&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com%7Cd9f54d9a9 > >> 9134cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0% > >> 7C638991488701908007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > >> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > >> %3D%7C0%7C%7C%7C&sdata=TD%2Bo5wxtcPBI%2BMnTqsUN8KgEKxV8TiMmAy1V183z > >> Tgw%3D&reserved=0 > >> <https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-younsi-grow-bmp-snts-01%2 > >> 3section-1&data=05%7C02%7CLeonardo.Rodoni%40swisscom.com%7Cd9f54d9a > >> 99134cf2dca308de275f984e%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0 > >> %7C638991488701925633%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > >> D%3D%7C0%7C%7C%7C&sdata=fxJHGXIJnP3OTllb3pYhyfFC1cPew6CkvmYiBmwnNlk > >> %3D&reserved=0> > >> > >> 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] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
