Hi Med,
Thanks a lot for your additional comments, much appreciated.
Nothing would prevent to have multiple PENs as part of a single message
but, also seeing past experiences with IPFIX, this is almost guaranteed
never to be the case: an exporter from vendor X delivering BMP messages
to a collector would likely only use the PEN X.
Paolo
On 28/2/25 07:45, mohamed.boucad...@orange.com wrote:
Hi Paolo,
Fair points.
My purpose was that you look into alternative designs out their and pick
whatever useful in your context. Especially that these alternative designs do
not suffer from the backward compatibility issue with 7854. Noted that you have
a discussion about this specific point in the spec.
BTW, do you foresee cases where the TLVs with distinct PENs will be present in
the same message? I'm asking this because the other alternative designs (:-))
are explicit about this + multiplex under the same PEN.
Thank you.
Cheers,
Med
-----Message d'origine-----
De : Paolo Lucente <pa...@ntt.net>
Envoyé : mardi 25 février 2025 13:38
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; draft-
ietf-grow-bmp-tlv-e...@ietf.org
Cc : grow@ietf.org
Objet : Re: Review of draft-ietf-grow-bmp-tlv-ebit-06
Hi Med,
Inline:
On 10/2/25 07:36, mohamed.boucad...@orange.com wrote:
Hi Paolo,
[ .. ]
[Med] Great, looking forward to see the merged version.
Sure, i'll do as a last step after any conversation that may stall the
TLV draft is cleared out.
[Med] Some text is needed to better explain the rationale.
For the design itself, assigning a bit (and actually a full range)
is not the only option. Please refer to the design adopted by other
protocols and see how they manage to address this with one single
VENDOR_CLASS codepoint.
As noted in the document too, we did inspire ourselves to the design
of
other protocols -- namely IPFIX. I know there are multiple options,
including re-inventing the wheel, we went for one of existing ones
which
has proven to be solid and does the work.
The other side effect of your current design is that you
artificially created a dependency on the E-bit spec for all the other
TLV documents! This wouldn't be the case with a VENDOR_CLASS type/TLV
is used.
Documents defining a standard with IANA allocations are oblivious to
the
use of e-bit. When creating a new registry the topmost bit should be
reserved, equivalent to the current less flexible Experimental range
arrangement.
The current proposal achieves the goal to seamlessly allow for two
scenarios: 1) exporters to pass TLVs that are non-standardized at all;
2) exporters to pass TLVs that have been standardized but, for
example,
are extended by some proprietary nuance (ie. private path marking code
points).
The two scenarios can happen concurrently and standard and proprietary
TLVs can be interleaved as needed to either facilitate encoding for
the
exporter or decoding for the monitoring station without having to
dedicate a section exclusively for proprietary data -- which is a plus
in a highly verbose context like BGP synchronization.
Paolo
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
