Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

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.Graf@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-bounces@ietf.org> On Behalf Of Job Snijders
> > Sent: Tuesday, November 16, 2021 5:16 PM
> > To: Paolo Lucente <paolo@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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3D&amp;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&amp;data=04%7C01%7CThomas.Graf%40
> > > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> > > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> > > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3D&amp;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&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3D&amp;reserved=0
> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow