Hi Paolo, ACK.
Please echo your clarification in the spec. Thanks Cheers, Med > -----Message d'origine----- > De : Paolo Lucente <pa...@ntt.net> > Envoyé : lundi 3 mars 2025 12:48 > À : 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, > > 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. ____________________________________________________________________________________________________________ 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
