Hi John,

Inline:

> On 07 Feb 2019, at 21:06, John Scudder <[email protected]> wrote:
> 
>> 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?

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.

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

Paolo
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to