Dear Jeff, > My point is that the FCFS range, in combination with the proposal for ebit, > REQUIRES the use of ebit.
I understood now your point. That draft-ietf-grow-bmp-tlv-ebit uses the experimental range 65531-65534 for the e-bit marker and 32768-65530 for enterprise code points. 32768-65530 has been classified prior to RFC 9515 as "Specification Required" and now is "First Come First Served". draft-ietf-grow-bmp-tlv-ebit basically obsoletes RFC 9515. Correct? I think both documents, RFC 9515 and draft-ietf-grow-bmp-tlv-ebit aim to lower the bar for implementations however by with two different aims. With both approaches we have coordinated code points. With IANA administered "First Come First Served" it is publicly visible where in draft-ietf-grow-bmp-tlv-ebit it is only visible which company issued the code point. From a network operator, users, point of view I prefer draft-ietf-grow-bmp-tlv-ebit since IANA administered "First Come First Served" lack the documentation of the semantics which is the main benefit of having a public registry. With https://mailarchive.ietf.org/arch/msg/grow/rSkjGSefcC1crt0UkG8ExTrUVM4/ we have a good example. This is a implementation specific counter. BGP protocol specific counters in my opinion are always "Standards Action". I fully agree with you assessment that we need feedback from the mailing list to understand different few points. What is your preference? Best wishes Thomas -----Original Message----- From: Jeffrey Haas <[email protected]> Sent: Sunday, March 23, 2025 9:13 PM To: Graf Thomas, INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [GROW] bmp ebit and rfc 9515 Be aware: This is an external email. Thomas, On Sun, Mar 23, 2025 at 02:51:24AM +0000, [email protected] wrote: > The sentences are hard to parse. Sorry for my difficult English. > Let me summarize my current understanding: > > RFC 9515 updated the following BMP registries at IANA from "Specification > Required" to "First Come First Served": > > BMP Statistics Type 32768-65530 > BMP Initiation Information TLVs 32768-65530 BMP Termination Message > TLVs 32768-65530 BMP Termination Message Reason Codes 32768-65530 BMP > Route Mirroring TLVs 32768-65530 BMP Route Mirroring Information Codes > 32768-65530 BMP Peer Up Message TLVs 32768-65530 > > That lowers the bar for adding additional information's into the existing > IANA managed BMP message types. See > https://datatracker.ietf.org/doc/html/rfc8126#section-4.4 vs. > https://datatracker.ietf.org/doc/html/rfc8126#section-4.6. This is all correct. > While draft-ietf-grow-bmp-tlv-ebit introduces enterprise managed BMP message > types by suppressing the experimental > (https://datatracker.ietf.org/doc/html/rfc8126#section-4.2) code points of > IANA managed BMP message types. > > Taking https://datatracker.ietf.org/doc/html/rfc7120#section-2 into > consideration, that would mean the following: > > - RFC 9515 enables without an IETF document to add additional > information's to existing BMP message types This continues to be correct. RFC 9515 makes it easy to get FCFS. > - draft-ietf-grow-bmp-tlv-ebit enables enterprises to add additional > information's to existing and future BMP message types > - > https://data/ > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc7120%23section-2&data=05%7C02%7CTho > mas.Graf%40swisscom.com%7C2fd89a15abc941c1655708dd6a14d2d4%7C364e5b87c > 1c7420d9beec35d19b557a1%7C0%7C0%7C638783359861108926%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x1IzuZLDB89oUejk5AoFk > pDUIx%2BREjvOE3HgpHawfqo%3D&reserved=0 governs at which stage code > points from the "Standards Action" range can be allocated > - experimental code point allocation is not supported anymore > > Quoting from: > https://data/ > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc3692%23section-1&data=05%7C02%7CTho > mas.Graf%40swisscom.com%7C2fd89a15abc941c1655708dd6a14d2d4%7C364e5b87c > 1c7420d9beec35d19b557a1%7C0%7C0%7C638783359861116401%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FBAt%2FZXg3lxM6ZMjaC0 > %2B4whnpNmwekGFoQMp8qO%2BxGs%3D&reserved=0 > > By definition, experimental numbers are not guaranteed to be > unique in any environment other than one where the local system > administrator has chosen to use a particular number for a particular > purpose and can ensure that a particular value is not already in use > for some other purpose. > > We understand that enterprise governed and IANA experimental code points are > very similar. The only difference is that the company who issued the code > point is now identifiable. > > To summarize, both documents together lowers the bar for IANA code point > allocation in above mentioned ranges and enables enterprises to register > their own code points in favor of supporting experimental code points. > > This mechanism has been proven well for IPFIX and experimental code points in > BMP appears to be not being used since introduction of the protocol. > > If I understood correctly you are raising the point wherever the working > group understood that experimental code points are no longer being supported > with draft-ietf-grow-bmp-tlv-ebit anymore and the role of RFC 9515 correct? No. My point is that the FCFS range, in combination with the proposal for ebit, REQUIRES the use of ebit. The fundamental proposal for the ebit draft is the top bit of the uint16 (2 octet field) is now leveraged for "this uses the enterprise encoding". Since the top bit is all values > 32767, this implies that all FCFS code points, if we were to use the ebit rules, MUST use enterprise encoding. -- Jeff
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
