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

[Jared Mauch <[e-mail]>]

On Thu, Sep 15, 2016 at 01:50:23PM +0200, 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 ?

	Because I may have a 32-bit ASN and want to encode a policy that
targets a 32-bit ASN.

	eg: 232232:655000

	Suppress my route to 32-bit ASN 655000.

	
> 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 ?

	There is some operational elegance in having something like


232232:655000:1

	To say :for my value of 1, this has an action of supress, prepend, drop
or whatever that common action is.

	This way when I innovate with my new policy that says the :8675309
tagged route will supress my route to Unroutableastan, I can have a simple
iBGP policy that just matches on ingress in Unroutableastan that drops
routes with $a:$b:8675309

	This operational nuance doesn't seem captured in any of
the existing work, so may seem new to those in IDR and why something
like draft-ietf-idr-as4octet-extcomm-generic-subtype-03.txt does not
seem to capture the actual use case of passing what inherently are opaque
policy variables and code through as communities.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.