Dear Sriram, In section 3, the border router which received Q1, might not be the same border router which received Q2 and Q3, these two border routers might not have the same view on the routing table: each could have a partial routing table (and reach the other through a default route).
In the above configuration, if Enhanced Feasible-Path uRPF would be enabled on the interface between these two border routers, it would result in blackholing, correct? Kind regards, Job On Tue, Nov 01, 2016 at 12:18:19AM +0000, Sriram, Kotikalapudi (Fed) wrote: > This work has been submitted to OPSEC WG. > Posting here also since it may be of interest to GROW WG members as well. > Comments/suggestions on this draft are welcome -- here or on the OPSEC list. > Thank you. > > Sriram > > ________________________________________ > From: Sriram, Kotikalapudi (Fed) > Sent: Monday, October 31, 2016 7:45 PM > To: [email protected] > Cc: [email protected] > Subject: Fw: New Version Notification for > draft-sriram-opsec-urpf-improvements-00.txt > > We (the authors) would like to request comments/suggestions on this draft. > We would like to request the chairs for time on the agenda > for presenting this work in the Opsec WG meeting in Seoul. > Thank you. > > Sriram > ________________________________________ > From: [email protected] <[email protected]> > Sent: Monday, October 31, 2016 7:32 PM > To: Montgomery, Douglas (Fed); Sriram, Kotikalapudi (Fed) > Subject: New Version Notification for > draft-sriram-opsec-urpf-improvements-00.txt > > A new version of I-D, draft-sriram-opsec-urpf-improvements-00.txt > has been successfully submitted by Kotikalapudi Sriram and posted to the > IETF repository. > > Name: draft-sriram-opsec-urpf-improvements > Revision: 00 > Title: Enhanced Feasible-Path Unicast Reverse Path Filtering > Document date: 2016-10-31 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-sriram-opsec-urpf-improvements-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sriram-opsec-urpf-improvements/ > Htmlized: > https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-00 > > > Abstract: > This document identifies a need for improvement of the unicast > Reverse Path Filtering techniques (uRPF) [BCP84] for source address > validation (SAV) [BCP38]. The strict uRPF is inflexible about > directionality, the loose uRPF is oblivious to directionality, and > the current feasible-path uRPF attempts to strike a balance between > the two [BCP84]. However, as shown in this draft, the existing > feasible-path uRPF still has short comings. This document proposes > an enhanced feasible-path uRPF technique, which aims to be more > flexible (in a meaningful way) about directionality than the > feasible-path uRPF. It is expected to alleviate ISPs' concerns about > the possibility of disrupting service for their customers, and > encourage greater deployment of uRPF. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
