/* Adding GROW as most of this discussion is applicable to GROW WG */
There is complexity, yes, but I don't quite see why you claim that "no
> one except a handful of backbone operators" understands how to use the
> current communities system, because that is glaringly not the case.
The problem with 16:16 and now with endorsing 32:32:32 is that it still
requires an external oracle to manually translate encoded magic number into
set of actions.
Let me provide an example:
I have 400 PEs and I want to do 10 different length of prepends depending
on the peering AS.
So today when I advertise the prefix I need 10 different communites for it
and 10 different policies on each out of my 399 egress PEs to translate
such magic number into an action.
While injecting 10 communities is not a big deal maintaining 10 different
policies across all 399 PEs adds-up and this is what makes the current BGP
policies very long and difficult to maintain.
And if we just add simple integer which will indicate the size of prepend
and within given AS make one magic number to indicate this is prepend
request we are neatly done.
If you have concrete proposals on how to define an algebra which can
> simplify this - even better, with sample grammars so we can understand
> how it might work in real life - then feel free to put a draft on the
There is IDR WG doc -wide-communities as well there is written but not
posted yet simple idea of 32:32:tlv.
We do not need algebra for that. Algebra was discussed to inject not 10
but 1 community to accomplish the above example. Without algebra just
properly building the community fields is all what is needed to simplify
your policy configuration.
There is no free lunch ... why operators would highly benefit - vendors
need to add code to current policy language to handle new fields. And this
is where the crux of the issue is why -flex or -wide was not yet been
- - - -
> To those who really really want TLVs, please do so using the
> following method:
> - reserve specific 32-bit ASNs from the reserved block(s)
I have DC and 15,000 CEs (multihomed customer sites across 3 global ASes).
I want per each application address I advertise from DC inject a community
which will do AS_PATH prepend from my 399 PEs to CEs based on the *IPv6
peering address* of the CEs.
Please tell me how said IPv6 prefix will be able to fit into -large
community such that I do not need to touch any of the 399 PE each time I
want to steer traffic to go via North or via South CE from each customer
site depending on central logic ?
GROW mailing list