One further thought to this: > On Dec 14, 2018, at 6:40 PM, John Scudder <[email protected]> wrote: > > Issue 1. draft-ietf-grow-bmp-local-rib says: .... > This doesn't make sense to me, since the definition of reason 2 in RFC 7854 > section 4.9 doesn't allow for any extra data: .... > An alternate fix, somewhat more involved but possibly useful in the long run, > would be to update RFC 7854 to permit Peer Down messages to carry additional > data beyond the reason code and its own associated data, and then to define > the format of that data. Probably the additional data would be TLVized. It > would obviously need to have a registry created for it.
It occurs to me that the main reason I can think of NOT to adopt this option would be that existing BMP server implementations might choke on new-style PDUs as described above, since they are illegal per the base spec. The fact RFC 7854 is underspecified as to what if any error checking and enforcement should be done, makes this maybe somewhat less of a concern (there's no mandated "you must reset the session upon protocol errors") but there's still no guarantee a server wouldn't experience an internal error. Whether the WG thinks this is a genuine concern or not, is a matter for discussion. Reasons to think it's not a big deal include, - I would hope most server implementations would be robust to this kind of malformation, but I don't actually know, I can just apply the "well that's how I would have done it" heuristic, which a pretty weak one. - Presumably the extra (nonconformant to RFC 7854) TLV would only be emitted when Loc-RIB functionality was configured, and presumably Loc-RIB functionality would only be configured if the server on the other end supported consuming it (otherwise why bother), Q.E.D. only a compliant server would see the new TLV. Reasons to think it is a big deal include reflexive conservatism, which is not always a bad thing in networking standards. By contrast, the other option I offered, allocating a new Reason code that includes a string field, is guaranteed to be backward-compatible with compliant implementations. And by "guaranteed" I mean "probably" since I see RFC 7854 section 4.9 doesn't explicitly say "you have to be tolerant of unrecognized Reason codes", however, I think this is a pretty good bet. It's certainly the more conservative option. $0.02, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
