[sidr] Question about draft-ietf-sidr-pfx-validate-03

Danny McPherson <danny@tcb.net> Sat, 12 November 2011 16:54 UTC

Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2368F21F8713 for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 08:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.541
X-Spam-Level:
X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqs3afWS+F8s for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 08:54:50 -0800 (PST)
Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8093621F86FF for <sidr@ietf.org>; Sat, 12 Nov 2011 08:54:50 -0800 (PST)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 2641A1900FE for <sidr@ietf.org>; Sat, 12 Nov 2011 16:54:50 +0000 (UTC)
Received: from [172.16.7.31] (unknown [122.147.35.3]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 828B6320245 for <sidr@ietf.org>; Sat, 12 Nov 2011 16:54:46 +0000 (UTC)
From: Danny McPherson <danny@tcb.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-17--787699501
Date: Sat, 12 Nov 2011 11:54:44 -0500
Message-Id: <E3CAD10A-758F-435F-B79F-62171DD373CC@tcb.net>
To: sidr wg list <sidr@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [sidr] Question about draft-ietf-sidr-pfx-validate-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Nov 2011 16:54:51 -0000

My read of the current draft suggests that if there's a route generated by the 
local AS in BGP it could never have a "Valid" state, and by definition would 
either posses a "Not found" or "Invalid" state -- even though the local 
AS may well have a "ROA" and reside in the mapping table as well(!).

I do not believe the current text is Section 5 is sufficient to address this case, 
specifically with either this:

"Considering invalid routes for BGP decision process is 
a pure local policy matter and should be done with utmost care."

or this:

"In some cases (particularly when the selection algorithm is 
influenced by the adjustment of a route property that is not 
propagated into IBGP) it could be necessary for routing 
correctness to propagate the validation state to the IBGP 
peer.  This can be accomplished on the sending side by setting 
a community or extended community based on the validation 
state, and on the receiving side by matching the (extended) 
community and setting the validation state."

I could think of a number of way to address this, but for there to exist the 
possibility that an internally generated prefix (for which a ROA may well exists)
could NEVER have a "Valid" state needs to be corrected.

Also, S 4:  s/to rest of the network/to the rest of the network/

Thanks, 

-danny