Considering that it takes on average two years to develop, test and ship a knob (not to mention that you need to write a check with sufficient amount of zeros in it) I think much better option would be just to have a parametrized policy language.
Good news is that if I am not mistaken some vendors already support what you are asking today :) It just requires a little bit of in depth scripting ... I am sure your vendor of choice will be happy to support you. Cheers, Robert. On Mon, Oct 27, 2014 at 11:20 PM, Owen DeLong <[email protected]> wrote: > What would be nice would be to have a BGP knob from vendors that could be > set on a per-peer basis (or per peer-group basis) that allowed us to > discard covered specifics with identical attributes on ingress. > > Owen > > > On Oct 26, 2014, at 2:51 PM, Iljitsch van Beijnum <[email protected]> > wrote: > > > > On 26 Oct 2014, at 21:17, Mark ZZZ Smith <[email protected]> > wrote: > > > >> Regarding controlling how far a more specific travels, I've attached > 'no-export' to more specific routes for TE purposes when advertising them > to an upstream provider to limit their reach. Of course the trouble is that > 'no-export' has a very limited scope. This discussion reminded me of this > draft, which encodes an AS level hop count that can be used to limit route > propagation, perhaps it or something similar needs to be revived: > > > > Setting an AS hop limit makes some sense if you assume the origin AS > wants to limit propagation of the advertisement. However, in many cases the > origin AS would probably like to see a deaggregate propagate as far as > possible, as this allows for the shortest paths and the highest level of > redundancy. > > > > Third party ASes, on the other hand, may want to limit how many of those > deaggregates they carry, but an AS hop limit wouldn't really give them any > tools to do that. > > > > But if you think that it makes sense to specify a community like this, > perhaps it would be a good idea to combine that one and the ones I'm > proposing here and possibly others into a single document. That would > probably make reviewing the document(s) an implementing those communities > easier. > > > > Or maybe not... > > _______________________________________________ > > v6ops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
