Randy Bush writes: > at this afternoon's sidr ssion, i presented two open issue with > draft-ietf-sidr-pfx-validate-04.txt > > 1 - Should updates learned via iBGP be marked? > > 2 - Should updates injected into BGP on this router be marked? > > i think yes because: > o i want support of incremental deployment > o i do not want to find out I am announcing garbage when my > neighbor$,1ry(Bs > NOC calls, mis-originations should be stopped at the source > > there was fear that, if used at other than edge routers, this allowed > creation of loops, as setting local pref etc, do. > > i think there was general agreement that this was ok on edge routers > and the point of injection, as that is logically an edge router. > > would like to see convergence on this
I could not hear the discussion in the room today because the utter webex fail prevented my remote participation. So let me ask about today's discussion. Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just at ingress edge routers, and if the policy is broken it can result in loops. It's something to watch out for when designing a policy, but I am thankful that this kind of flexibility exists, because not all policies that manipulate attributes other than at ingress edges are broken. Regarding pfx-validate: I hope the agreement in the room was that a sane network design would probably involve setting a local 'origin has been checked' community on the first router inside the AS where that check occurred. I hope the agreement was _not_ that pfx-validate implementations should be hard-coded to assess validation state only at the ingress edge router.
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
