Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Nick Hilliard <nick@foobar.org> Sat, 14 January 2017 21:53 UTC

Return-Path: <nick@foobar.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07C2129408; Sat, 14 Jan 2017 13:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj6vk12gtNkc; Sat, 14 Jan 2017 13:53:52 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DBB126579; Sat, 14 Jan 2017 13:53:51 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0ELrkXl037108 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 21:53:46 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <587A9DE9.1000608@foobar.org>
Date: Sat, 14 Jan 2017 21:53:45 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.9 (Macintosh/20161202)
MIME-Version: 1.0
To: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <c55845cc-ca06-45c8-9b2e-075421d0447c@Spark> <58795A0B.6000009@foobar.org> <alpine.WNT.2.00.1701141045460.14048@mw-PC> <587A03CF.3010001@foobar.org> <alpine.WNT.2.00.1701141619550.14048@mw-PC>
In-Reply-To: <alpine.WNT.2.00.1701141619550.14048@mw-PC>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/NJEg75YAHcfsNXohlHQU-ZruXO4>
Cc: "Carlos M. Martinez" <carlosm3011@gmail.com>, sidrops@ietf.org, GMO Crops <grow@ietf.org>, job@ntt.net
Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jan 2017 21:53:54 -0000

Matthias Waehlisch wrote:
> the current discussion makes clear that documentation of 
> origin-validation-signaling in IXP context is needed

rpki is conceptually no different to any other type of signaling
mechanism: it's simply another input into the BGP decision engine
process, just like communities or meds or as-path.

What we're losing sight of here is that it's the route server which
calculates the best path for each route using the routing decision
engine, and then sends a _single_ best path to the client. Conceptually,
it doesn't matter whether the tie-breaker on the route server is
communities, meds, as-path or rpki: the point is that the policy
decision mechanism needs to be configured on the route server itself,
because the route server is the device which is calculating the best
path.  If the route server operator doesn't do this, the clients will
end up with path hiding (see 2.3.1 in rfc7947).  I.e. it's nothing
specific to rpki.

This is already extensively documented in rfc7947 and rfc7948.

Nick