On Thu, Dec 02, 2021 at 04:10:43PM +0100, Job Snijders wrote: > Hi Folks, > > Please take 15 minutes out of your day to review this *really short!* > internet-draft. The authors were kind enough to make it only 3 pages of > actual content :-) > > We'll extend this WGLC with another week (December 9th, 2021)
A few comments: 4.2: "value MUST be boolean" really isn't precise enough I suspect the intent is "0 is false, 1 is true". Spell that out. Some protocols the existence of a zero-length TLV as a presence node is sufficient to say "true". And perhaps some people's code says #define FALSE 0 #define TRUE !FALSE You may even want to be more limiting and require that the length of the TLV is one. 7 IANA Considerations: You're effectively defining a registry for route monitoring messages. That should likely be a new registry - see examples in RFC 7854 section 10. No TLVs are being defined for peer down. I still suggest creating a registry. The registry policies in section 10 probably aren't what you want. E.g.: : Information type values 0 through 32767 MUST be assigned using the : "Standards Action" policy, and values 32768 through 65530 using the : "Specification Required" policy, defined in [RFC5226]. Values 65531 : through 65534 are Experimental, and value 65535 is Reserved. I don't recall the status of changing of the policies. Wasn't there a draft on that circulating or am I remembering incorrectly? A final meta comment that probably belongs in an Error Handling section: For a route monitoring message, the new TLVs follow an encoded BGP Update message. BGP isn't a rigorous TLV protocol, as we know. And certainly, a BMP implementation MUST know how to decode a BGP PDU in order to do its work. That said, an implicit property for route monitoring optional TLVs is that the encapsulated BGP Update is well-formed! If it is not, then you can't seek into the optional TLV section and parse it appropriately. Related indirect property: If you want to have BMP as a channel for bad BGP PDUs, it probably needs to be via route mirroring. -- Jeff > > Kind regards, > > Job > > On Tue, Nov 16, 2021 at 05:33:39PM +0000, thomas.g...@swisscom.com wrote: > > Dear GROW WG, dear authors > > > > I have reviewed the draft. I think it is straight forward and ready for > > IESG. > > > > It is the next logical step to make the different BMP message types to be > > equal by supporting TLV's for BMP route-monitoring and peer_down messages > > as well. > > > > Best wishes > > Thomas > > > > -----Original Message----- > > From: GROW <grow-boun...@ietf.org> On Behalf Of Job Snijders > > Sent: Tuesday, November 16, 2021 5:16 PM > > To: Paolo Lucente <pa...@ntt.net> > > Cc: grow@ietf.org grow@ietf.org <grow@ietf.org> > > Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st > > 2021) > > > > Dear all, > > > > This starts the formal WGLC period which will run from November 16th until > > December 1st 2021. > > > > Please review > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06&data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3D&reserved=0 > > and provide comments or feedback on the grow@ietf.org mailing list! > > > > Kind regards, > > > > Job > > > > On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote: > > > Dear Colleagues, Dear Chairs, > > > > > > A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv > > > last week at the WG meeting. We authors believe there are no more > > > items to work on for this draft, received inputs were processed and > > > any questions / concerns were addressed. I'd hence like to ask to LC this > > > work. > > > > > > You may read motivation for this work in the draft itself, let me > > > supplement it saying that this is a key piece of work that would make > > > extensible every BMP message defined so far; this, in turn, would > > > bring BMP on par with other modern monitoring (/ telemetry) protocols (/ > > > stacks / solutions). > > > > > > Paolo > > > > > > _______________________________________________ > > > GROW mailing list > > > GROW@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7CThomas.Graf%40 > > > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee > > > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW > > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > > > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3D&reserve > > > d=0 > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3D&reserved=0 > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
