Hi Jeff,
Thanks very much as always for your comments.
Ack about the boolean part. That adds up very well to a similar comment
Ben's made in his email. Will fix that.
Ack also about the creation of Route Monitoring and Peer Down
registries. There is another in-flight draft from John Scudder about
splitting Init and Peer Up registries - is it the one you were thinking
to? Upon reviewing LC feedback, we determined an interference between
that draft and the Loc-Rib one; we decided, with the agreement of John,
to let Loc-Rib draft go ahead first then work on the other one (and i
did volunteer myself to help John with that).
Agree & ack your final remarks about properties of introducing optional
TLVs in Route Monitoring messages. Would you like to see them mentioned
in the draft?
Paolo
On 8/12/21 12:57, Jeffrey Haas wrote:
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, [email protected] 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 <[email protected]> On Behalf Of Job Snijders
Sent: Tuesday, November 16, 2021 5:16 PM
To: Paolo Lucente <[email protected]>
Cc: [email protected] [email protected] <[email protected]>
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 [email protected] 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
[email protected]
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
