Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

[Jeffrey Haas <[e-mail]>]

Robert,

On Fri, Sep 09, 2016 at 06:13:07PM +0200, Robert Raszuk wrote:
> As far as common header details there were three points which privately
> Jakob and I were not able to solve. Hence as recommended by chairs we moved
> the discussion to IDR list.
> 
> 1. IANA registered or private indication.
> 
> As you pointed out that can be a flag or it can be embedded within the
> type. I was fine with any of those - Jakob said no to both.

In the case of 4:4, that's the choice of the discussion for that format.  I
don't think there's a lot of call for it in that mechanism.

For wide, we have a use case.  I don't think Jakob gets any more say there
than the rest of WG for consensus.

> 2. Size of type field
> 
> Original wide had two octets, Jakob locked his position on single octet. I
> offered compromize with 12 bits. The compromize was rejected. Maybe 255 is
> enough - maybe not ... but today we already see need for 4 or 5 (ext. comm
> successor). It really does not cost that much to leave extra room IMHO.
> Especially that tomorrow someone may come with brilliant idea to steal most
> significant bit or two of type field for some other use.

I'm a fan of 2 octets for any new type field in any proposal myself.  I'm
not going to stress over it too much.  It appears the motivation for sizing
is more for alignment of the following context AS field on a word boundary
for implementations that care about such things.

> 3. Size of flags
> 
> That one was not that much of contradiction - I guess one octet or 12 bits
> for extra space would be fine too.

Bits tend to be the thing that get burned fastest, but since this needs to
be common container-wide, a constrained space may have to make sense.

Probably the best analogy for this headache is covered by
draft-ietf-idr-bgp-attribute-announcement.  

> Rest of the elements in common header are context AS - here we agreed
> easily that what it means is a local matter and will be described in a
> given type. Length of two octets (in octets) also seems fine to everyone.

I'd like to see context AS get some level of standardization as "who these
communities are addressed to, and their interpretation of how they are
used".  I believe that's the semantic we have today.

-- Jeff