Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[Jeffrey Haas <[e-mail]>]

> On Oct 5, 2016, at 12:17 PM, Job Snijders <[e-mail]> wrote:
> 
>> I'll reiterate my objection to a mandatory representation format, but
>> other implementations that actually are impacted will make my point
>> for me.  Unless we're doing a yang module, IETF really has no business
>> specifying UI.
> 
> There are more examples where the IETF (for better or for worse) has
> specified canonical representations. For example, I'd be disappointed if
> a major implementation ends up representing Large BGP Communities as
> straight uint96_t's in the UI.

Some of your operational compatriots are quite happy to do decimal string character index operations already.  It wouldn't surprise me that at some point someone asks for 4:4:4 to be 4:8 to enable trickery.

Note: It's not been asked for. Yet.  But I have faith in customers asking after weird features.

> 
> A challenge here is that there might be two issues at hand: one is the
> canonical way to represent a Large BGP Community in a phone call, or in
> technical documentation which is provided by one operator to another
> operator. The second issue is what is actually typed/inputted into
> network element configurations.

I think the critical detail is already handled under section 2 of the draft: A large community is defined as 3 contiguous four octet values.  You want structure, you have enough of the document defining structure.  More importantly, the structured components have names: Global Admin, Local Data 1, Local Data 2.

Really, I think you're done.

> 
> The "Textual Representation" section should provide any implementor with
> enough freedom to use a prefix, suffix, or a separator of their
> choosing. Given the current text:
> https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232
> should we change the first three "MUST" to a "SHOULD" to alleviate your
> concern?

First, you talk about implementations.  Again, it'll depend on the implementation as to whether they find this reasonable or not.  We've already had input on-list from those who do things differently.

If your concern is really just to have a useful way to talk about these things in a portable way:

"For documentation purposes, it is RECOMMENDED that BGP Large Communities be represented as three unsigned decimal numbers separated by the colon character;  <Global Administrator>:<Local Data 1>:<Local Data 2>.  E.g. 65551:100:0."

> Do you consider my concern about a canonical format for inter-operator
> communication valid?

For communication, yes.  Conveniently, the recommendation also covers advice for those working on things like yang models.

-- Jeff