Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

Hi,

Regarding VRF/Table Name TLV:
Based on my understanding of RFC7854, I think the processing of VRF/Table Name TLV can be the same as Type 0 String TLV of BMP Initiation Message in RFC7854:
The VRF/Table Name TLV MAY be included multiple times.
If multiple strings are included, their ordering MUST be preserved when they are reported.

At the same time, this spec can also support processing multiple String Information into one composite String and then putting it into one TLV.

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Paolo Lucente
Sent: Friday, July 19, 2019 12:22 AM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

Hi Jeff,

Thank you for your feedback. Inline my comments:

> On 18 Jul 2019, at 14:55, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> Thanks for addressing my comments.  One final reply on this thread:
> 
> On Thu, Jul 11, 2019 at 12:30:53PM +0000, Paolo Lucente wrote:
>> Done. This opened a further consideration at my end. The document 
>> lacks a statement as in 
>> https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about “TLVs can be sent in any order.
> 
> While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by 
> their code point."
> 
> Many implementations that deal with TLV based protocols will 
> canonicalize data structures based on the TLVs using sorted 
> structures.  Having them sorted on the wire means the canonicalization step is cheaper.
> 
> Note that this is a general justification for the procedure and it's 
> not critical for something like BMP.

Suggestion accepted, thank you, i will include it in the next edit. 

>> Multiple TLVs of the same type can be repeated as part of the same 
>> message and it is left to the specific use-cases whether all, any, 
>> the first or the last TLV should be considered.”. In the specific 
>> case of VRF/Table Name one could have both a VRF id/name and a Table 
>> Name, hence the same TLV could be repeated twice (my take is that 
>> it’s a perfectly valid scenario). I’d tackle this case once i get 
>> green light from you that we are good about how your feedback was 
>> processed.
> 
> I suspect most vendors will eventually generate a composite name and 
> send a single TLV for the name.
> 
> It would not shock me at some point if this becomes sufficiently 
> vendor specific that we start seeing vendor specific TLVs here.

Totally, i agree on your both points. My line of thought was: there are two main approaches for using the standard VRF/Table Name TLV: stacking values in a single TLV (what you mention) and breaking values in multiple TLVs. The former method is a given; i was simply thinking why not allowing also for the latter: while it increases flexibility “it does not seem to produce any harm” (tm).

Paolo

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow