On 11/11/16 8:12 AM, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote: >>> right, ok - I misunderstood. So you're suggesting that the control >>> plane correlates asns to interfaces and does something like >>> creating a higher cost alternative path out each candidate source >>> interface (based on ASN, as determined in the control plane) to >>> allow the urpf mechanism handle this using its normal lookup >>> method? >> >> Yes, that is correct. > > I can't help feeling that the use case looks a bit contrived. The sort > of situations that could benefit from urpf that I've seen on production > networks don't generally involve inconsistent prefix sets being > announced via different connectivity providers, where there is a > requirement for urpf away from the leaf network. > > If it's any help, the most usual situation where urpf would be handy but > can't be done, is where you have an interface facing an upstream and you > want to receive prefixes (and send traffic) via that interface but not > announce anything (or receive traffic).
The case where routine maintance creates temporary blackholes is basically ubiquitious were you attempting to use urp strict. > Nick > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
