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

[John Scudder <[e-mail]>]

Thanks for your reply, Paolo. My remarks below.

On Jan 23, 2019, at 9:04 AM, Paolo Lucente <[e-mail]> 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 <[e-mail]> 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