Hi Robert,

I think you have answered your own question quite nicely already. 16:16
allows one to put a 2-byte AS number into the first two octets, and
another 2-byte AS number into the last two octets, if so desired. If we
went with 32:16 we can't replicate RFC1997 functionality with 4-byte AS
numbers because we could only enter a 2-byte number into the second half
of the community tag. This in turn creates a feature disparity (a
downgrade even) between the good ol' RFC1997 system and the new one.

Furthermore - even if we lived in a world where nobody used 4-byte AS
numbers we could do with more space in the second half of the RFC1997
communities for reasons I will outline below. That means there are other
motivations for a swift implementation of a new community standard and
while the "Wide" communities standard seems to have interesting
properties, vendors have previously indicated it is relatively difficult
to implement which is evidenced by 6 years spent as a draft with zero
examples of running code. "Large" fits my requirements as well and even
though it's only two months old there are already several working
implementations today, thanks in no small part to its very simple design.

As promised, I'd like to share some background information on how we
operators use the RFC1997 communities in the real world so you can
understand why we're asking for a third set of octets in the "Large"
communities standard resulting in the 32:32:32 format. These were part
of the design considerations for our own AS49544 BGP action community
system [1]:

1) We should never confuse the end user as to which network is being
targeted by the community tag. Though RFC1997 is entirely opaque, we
tend to avoid using anything but our own RIR-allocated ASN or RFC1930
private AS numbers in the first two octets for externally visible BGP
communities.

2) The target of my action could be a specific AS number - like my
upstreams AS2914, AS3320, AS3356, etc - or an entire Internet exchange
for which I've typically allocated a number from the RFC1930 range.
Because we'd prefer not to use another operator's AS number in the first
two octets as per item #1, and we don't want to create confusion [2] as
to which ASN we're targeting, we have decided to put the target
information into the last two octets.

3) We typically implement at least four actions per target - prepend
once, prepend twice, prepend thrice, and do not advertise. This means a
format like "49544:target" can't cover all the actions, and again as per
item #1 we don't want to confuse the end users, so we have to resort to
using numbers from the RFC1930 range to define my routing policy
actions. We have chosen a format of 65501:3356, 65502:3356, 65503:3356
to signal one, two, and three prepends and 65500:3356 to signal do not
advertise to our direct interconnections with AS3356.

4)  Unfortunately there are nowhere near enough bits to avoid collisions
in the first two octets because we're all competing for the small chunk
of RFC1930 space where we can use the last digit to signal our desired
action of 0, 1, 2 or 3. AS49544's own design happens to collide with the
one in use by our direct upstream AS2914 [3] and the real-world impact
is that we have to strip such action communities before exporting to our
BGP neighbors to avoid unintentional routing table segmentation. An
example which comes to mind is using 65500:3356 to stop AS49544 from
exporting a prefix to AS3356, but since AS2914 will take the same action
that means AS3356 and its single-homed customers would no longer hear
that specific prefix via any path if we didn't strip that community
before exporting to AS2914. In turn, this means information as to why
AS49544 is doing something to the routing table is lost in transit.

What I've described above is a very common design philosophy amongst
major backbone operators - one that should be preserved as much as
possible while still tackling the aforementioned problems. We need to
avoid having to re-educate the majority of the operator community, so a
ton of new "knobs and twiddles" are quite simply put undesirable when
the same could be achieved with a much simpler "more of the same" design
that everyone who's familiar with RFC1997 should intuitively grasp.

Coming back to the question as to why 32:32:32 would be desirable - if
we could signal something like 49544:3356:0 instead we can tackle item
#4 to clarify that only AS49544 should take action, we can tackle item
#2 because we have the ability to put any operator's 2-byte or 4-byte AS
number into the set of octets which our network has defined as target,
and we can tackle item #3 to signal an action which could now achieve a
lot more than just a simple prepend or don't export. Use cases which
come to mind are AS286's beautifully engineered "extended regional Black
Hole" system that even lets the end user target specific PoP's within a
single metro area for a blackhole.

Best regards,
Martijn Schmidt

[1] http://noc.i3d.net/bgp-communities/ - we need to update this
document to account for some changes in routing policy / upstream
providers, but the general idea is still the same.
[2] https://onestep.net/communities/as3549/ - as you can see in this
operator's real-world example, the former GlobalCrossing network used a
format like 3549:8122 to prepend twice on peerings with AS2914. However,
2914 does not show up in the action community tag 3549:8122 and that
could be quite confusing for an end user such as myself.
[3] https://www.us.ntt.net/support/policy/routing.cfm
[4] http://as286.net/AS286-erBH.html

On 09/15/2016 01:50 PM, Robert Raszuk wrote:
> Nick,
>
> Many times folks on this list quoted RFC1997 which allows 16:16. 
> First two octets were usually ASN second two octets usually agreed
> semantics. 
>
> Example: https://onestep.net/communities/as3356/
>
> No doubt that 32:32:32 would be nice to have, but there is difference
> between nice to have and absolute must have - especially considering
> the requested urgency. 
>
> If the only reason for large communities are 4 byte AS numbers I am
> just asking why 32:16 would not cut it ? 
>
> Please do not interpret this as any attempt against Large Comms ... it
> is just a question how Large Comms are to serve the same as RFC1997
> except accommodating 4 octet ASNs ?
>
> Thx,
> R.
>
> On Thu, Sep 15, 2016 at 1:36 PM, Nick Hilliard <nick@foobar.org
> <mailto:nick@foobar.org>> wrote:
>
>     Robert Raszuk wrote:
>     > All implementations support that already in all deployed gear so
>     you can
>     > get 32:16 essentially now - even without any IDR and IETF process.
>
>     people have repeatedly said going back many years that 6 octets is not
>     enough.  We need more than 32b:32b:
>
>     - 32 bits for subject ASN
>     - 32 bits for object ASN
>     - enough bits for semantics
>
>     Nick
>
>     _______________________________________________
>     Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr