/* Adding GROW as most of this discussion is applicable to GROW WG */ Nick,
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 implemented. - - - - Hi Brian, > 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 ? Many thx, R.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
