Now that the holidays are safely (?) over, I'm bumping this topic (and the previous message to it, which I assume everyone can find for themselves).
--John > On Dec 17, 2018, at 4:37 PM, John Scudder <[email protected]> wrote: > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=utvYcoebXr3QSPs9cdM9P7Cv6pScVERGzE35h9RAf40&s=RVl2YX_bCdXH2LUx2OZdc2Ys8WBT_vt3Mcfe3clvKtU&e= _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
