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
