Hi Jeff,
Thanks for your support! Agree with you that lots of work is still
needed, including further detailing each of the reason codes, which will
probably require additional TLVs (like we are doing for policy discard
and you were proposing for malformed update).
Inline:
On 4/11/23 10:29, Jeffrey Haas wrote:
- 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?
Like per the draft-ietf-grow-bmp-tlv, index zero (0) does apply to the
entire update. There we have the 3 main cases covered: we can address
individual NLRIs, groups of NLRIs or all of them.
- 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.
Good point. So Reason TLV set to malformed code point (0x0008), index
set to zero (all NLRIs). Then a Malformed TLV with stringy space for
commentary, how does it read?
- Log action seems likely to say 'here's a trace message appropriate to this
update'. Is a string TLV for that forthcoming?
Sure, totally! This is a case where I was being incremental with the
text in the draft, starting from where the most interest seemed to be
(Policy Discard) but, yes, Log Action was an easy one to attack as well.
- 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.
Thanks for opening the floor to this conversation, it is exactly one of
the items on which i would have solicited feedback on Monday & currently
total open to input and ideas. So input taken & surely i will relax the
current limit on the string length.
- Validation failure is likely to need some level of overlap with validation
in the path marking draft.
Totally, agree.
Paolo
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
