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 protected]> 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. > > 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. 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
