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

From: John Scudder <[email-masked]>
Date: Thu, 7 Feb 2019 20:06:32 +0000

Thanks for your reply, Paolo. My remarks below.

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

---

From: Paolo Lucente <[email-masked]>
Date: Sun, 10 Feb 2019 19:45:14 +0100

Hi John,

Inline:

> On 07 Feb 2019, at 21:06, John Scudder <[email-masked]> wrote:
> 

Yes. While i was and i still am a super-fan of the draft, there is what i’d define a small inconsistency that i would fix in that draft: the BGP UPDATE message is TLV’d itself, ie.:

A BMP Adj-RIB-In route-monitoring message can look like:

   o  generic bmp header, 6 bytes
   o  per-peer bmp header, 42 bytes
   o  tlv-header, type = BGP update message TLV
   o  [ .. ]

This is different from the other existing BMP messages where a TLV section follows the BGP message.

> 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 for your feedback on this. I will then produce some text soon for everybody review.  

Paolo

---

From: Paolo Lucente <[email-masked]>
Date: Sun, 10 Feb 2019 19:48:56 +0100

(re-sending, not sure what happened to the Subject of the email in my previous post)

Hi John,

Paolo

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 20 Feb 2019 07:49:03 +0100

Hi John,

> 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?

I contributed some text in section 5.3 (and updated IANA considerations in section 8), see:

https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/blob/master/draft-ietf-grow-bmp-local-rib.txt

Look forward to your thoughts.

Paolo