Job, On Wed, Oct 25, 2023 at 12:57:08AM +0200, Job Snijders wrote: > The authors of draft-lucente-grow-bmp-rel asked whether GROW > working group could consider adoption of the internet-draft. > > This message is a request to the group for feedback on whether this > internet-draft should be adopted.
I support adoption of the draft. The draft needs a lot of work. A few quick comments for the authors: - As I'm reading it, the format is intended to be "per NLRI", where that NLRI may be a group, correct? If so, how are things to be encoded when we're talking about the entire update? - Related: If we're sending a malformed update in the field, the ability to parse the NLRI may not be feasible. This impacts not only whether the BGP PDU should come first or not, but also the prior comment about having the type "malformed update", perhaps with commentary; e.g. one or more string TLVs. No indexed operations will be possible. - Log action seems likely to say 'here's a trace message appropriate to this update'. Is a string TLV for that forthcoming? - While I agree with Thomas that the policy discard information is helpful, a simple string is unlikely to be quite enough. Minimally I'd suggest relaxing the length limit to permit a better qualifier, or perhaps consider a vector of strings. Juniper example, consider a policy "match-bad" where "term evil-guys" is the failure position where the "then reject" occurs. (Or perhaps a new "then reject-and-complain".) Should this be solely encoded as "match-bad" even when this may be tens of thousands of terms long? Perhaps as "match-bad/evil-guys" in XPath style? Etc. - Validation failure is likely to need some level of overlap with validation in the path marking draft. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
