Subject: Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

From: John Scudder <[email-masked]>
Date: Wed, 16 Jan 2019 21:50:49 +0000

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-masked]> wrote:
> 
> One further thought to this:
> 
>> On Dec 14, 2018, at 6:40 PM, John Scudder <[email-masked]> 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-masked]
> 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=

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 23 Jan 2019 15:04:45 +0100

Hi John,

[shared text] Ideally, i would like every BMP message type to have a (optional) TLV section, each with a own namespace. If the idea is shared, i’d look forward to see how to get there.

> On 15 Dec 2018, at 00:40, John Scudder <[email-masked]> wrote:
> 
> [ .. ]
> 
> One fix, I think the more expedient one, would be to request a new reason code ("TBD3"), whose format includes both the content carried in reason 2, and a VRF/Table Name. Then if you want to send the table name, you use the new reason code.
> 

If i get you correctly, updating RFC7854 is what would get to the ideal scenario above. I feel, for the reasons you explain, this is the kind of change that would require a version bump in order to make it clean. Perhaps a longer term plan, where we do also tackle the subject of TLV & Route Monitor message?

Although not going in the ideal direction, for shorter-term I was thinking about somewhat a mix of the two solutions you propose, to work as a Charon: use a new reason code (or perhaps two, one for local terminated session, one for remotely terminated session) since, as you said in your follow-up email, it is the more conservative and would give the most hope against what has been already coded. And make this/these new reason code(s) carry "additional data [that] would be TLVized. It would obviously need to have a registry created for it” so not to make all too “expedient” and revolving around the specifics of VRF/Table Name and draft-ietf-grow-bmp-local-rib. 

Paolo