Wed, Mar 13, 2019 at 04:30:08PM +0100, Robert Raszuk: > In general of course. > > I was just describing the *local ISP customer's* inbound peering policy. > Sorry if that wasn't clear.
by "local ISP", do you mean Comcast? :) For a very small provider, existing policy language could be sufficient; we're all making due with what we have, but it really depends upon how pedantic they wish to be about A route's attributes and the volume. the more pedantic they wish to be, the larger the policy; the config becomes large and their devices may not have resources to handle it. That assumes that they have the information to be pedantic; see efforts of many to improve (speed, accuracy, etc) IRR data or utilize sidr data in other ways. More programability is needed, imo. IOS XR has made improvements here with parameterized RPL, for eg. as for the draft itself, isnt the origin case handled by sidr? and the transit case by proposed path validation? > Or do you see that even that has some limitations which may require extra > solutions ? If so pls elaborate on what those limitations are. > > Thx. > R. > > > > On Wed, Mar 13, 2019 at 4:26 PM heasley <h...@shrubbery.net> wrote: > > > Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk: > > > Each decently managed AS today has strong EBGP ingress policy permitting > > > only specific prefixes with specific AS-PATH which is applied in ingress > > to > > > ISP network. No more enhancement to this policy is required. > > > > I'm NOT speaking in support of this draft, I have not even read it. But, > > want to tell you that there are limitations to what filtering can be > > imposed inbound and not just when the peer is very large. effective > > solutions should be welcomed. > > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
