Ahh no - I should have said first hop ISP for eBGP connected end customers.
I was not talking about validating Comcast uplinks - for those indeed origin validation and when it ever get's seriously implemented BGP path validation may be rigth solutions. This draft to the best of my understanding proposes to check anywhere in the EBGP transit if listed AS-PATH sequences of ASes are valid ie possible based on real peering data. Cool idea ! There is only one little problem I asked authors about ... there is no such data to validate it against :) On Wed, Mar 13, 2019 at 6:24 PM heasley <h...@shrubbery.net> wrote: > 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
