Thanks for your reply, Paolo. My remarks below. On Jan 23, 2019, at 9:04 AM, Paolo Lucente <[email protected]> wrote: > > 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.
This is clearly an idea all right-thinking people will support and the reason we don't see more "+1" replies is because everyone assumes it obviously a good idea. :-) >> 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. While there are ways to do it without a version bump, I agree with you that bumping the version keeps it clean. > Perhaps a longer term plan, where we do also tackle the subject of TLV & > Route Monitor message? As in Henk's earlier (and still not dead!) proposal? > 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. If I understand you correctly this seems fine to me. I guess the easiest way to be fully clear would be to rev the draft, and then we can have a look at the new text? Thanks, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
