I understand the scenario. That scenario is a problem for strict or feasible path uRPF, as well as the enhanced FP uRPF. If you add one further generalization to enhanced FP uRPF, namely, allow any prefix learned on any customer peering to be included in the RPF tables for *all* customer interfaces, then the enhanced FP uRPF still works for this scenario.
Sriram ________________________________________ From: Job Snijders <[email protected]> Sent: Tuesday, November 15, 2016 3:26 AM To: Sriram, Kotikalapudi (Fed) Cc: Gert Doering; [email protected] Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt On Tue, Nov 15, 2016 at 05:38:57AM +0000, Sriram, Kotikalapudi (Fed) wrote: > > Does this technique make routers self-aware? What exactly is meant > > with the word 'intelligence' in this context? > > 'Logic' may be a better choice than 'intelligence' in this context? > For a brief description of the algorithm, please see: > https://www.ietf.org/mail-archive/web/grow/current/msg03699.html Thank you for the clarification. I have a second scenario that might be a challenge for Enhanced Feasible-Path uRPF. ASCII ART: +---+ +-+AS1+--+ | +---+ | | | | | +-+-+ +-+-+ |AS2| |AS3| +---+-+ +--++ | | | | +-+-+ | |AS4+---+ +---+ AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from both AS2 and AS3 (and as such as two paths to AS4). A common traffic engineering practise visible in the Default-Free Zone is to block unbounded propagation of one's prefixes. For instance, AS4 might use a BGP Community provided by AS2 to block propagation of the AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches NO_EXPORT on the announcements to AS2, but not on the announcement to AS3. AS1 will receive traffic sourced by the prefixes from AS4 via both AS2_AS4 and AS3_AS4. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
