Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard

Christopher Morrow <morrowc.lists@gmail.com> Sat, 04 February 2012 19:03 UTC

Return-Path: <christopher.morrow@gmail.com>
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 64A4121F848B for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 11:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 cmyWsG3NDemv for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 11:03:12 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6E21F8473 for <sidr@ietf.org>; Sat, 4 Feb 2012 11:03:12 -0800 (PST)
Received: by iagf6 with SMTP id f6so7729961iag.31 for <sidr@ietf.org>; Sat, 04 Feb 2012 11:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6eMq6lQn4h7ZTewzh4fR1Jv4NYHyF1FPSqeOFx/O8vQ=; b=TNswDsXpSSBtq16zzRXz0P7N/9LKR9AoPoezS7UeGmKcSOJEIW1LHA+ego6nG8dEYQ SnWagIRmlfF2XEwUBFyjBhT7zURGvnnJ3XlghyrmfMrF1nCvisXc2stuROXu9ey0oQW8 UJ9Lfz57EqNaw2vlck2ITi7+pKCv2BctrDX0A=
MIME-Version: 1.0
Received: by 10.43.44.197 with SMTP id uh5mr13488986icb.34.1328382192126; Sat, 04 Feb 2012 11:03:12 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.231.93.141 with HTTP; Sat, 4 Feb 2012 11:03:11 -0800 (PST)
In-Reply-To: <0lehuaiiky.fsf@wjh.hardakers.net>
References: <20111129225106.25323.811.idtracker@ietfa.amsl.com> <FF8D803A-4C2D-4A3A-B274-70A9FB514F5C@castlepoint.net> <m239cls81v.wl%randy@psg.com> <0lehuaiiky.fsf@wjh.hardakers.net>
Date: Sat, 4 Feb 2012 14:03:11 -0500
X-Google-Sender-Auth: 0BXNrX-ntPZXngN_DsnhmsZSqu0
Message-ID: <CAL9jLaZKjoe4LRT6mqeqxpfSxa8z0AU7ohRr-3qOL6PeR74LUg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
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, 04 Feb 2012 19:03:13 -0000

On Sat, Feb 4, 2012 at 1:01 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
>>>>>> On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush <randy@psg.com> said:
>
> RB> As you say, NetConf is for *configuring* routers.  RPKI-rtr is not used
> RB> for router configuration, but rather dynamic data, a la IS-IS or BGP.
> RB> In fact, the RPKI-rtr payload data go into the same data structure as
> RB> the BGP data.
>
> Having finally read through the rtr-25 document, and having some
> background in following the Netconf work, I finally am in a position to
> give my opinion on this thread.  The thread is a bit old, but consensus
> never seemed to be "full there" so I figure one more opinion might be
> helpful.
>
>
> The short summary: Randy is right (this time; don't let it go to your
> head Randy :-) )
>
>
> The longer explanation:
>
> Could netconf be used to send this type of data over?  Yes.  But...
>
> Routers, operating in the defacto state of doing what they're supposed
> to be doing (routing), need to be fast and efficient.  And that's an
> understatement.  The rpki-rtr protocol is clearly designed to make sure
> this is the case.  It's a cache-query protocol designed to keep a fairly
> large, complex and constantly changing data set in sync with the router
> that actually needs to use it.  It's binary in nature (ironically
> written by some people that used to stamp on the ground about how
> annoying binary protocols are) because it needs to be in order to be
> efficient and fast.  Especially when the data is large and changing at a
> rapid rate.
>
> Now, lets compare those needs against netconf.  Netconf was designed to
> be a protocol that operated on a data storage full of configuration
> data.  The configuration data is likely to be static, except when rarely
> manipulated through CLI, netconf or some other actions.  But those
> modifications will be rare, not frequent.  The language is verbose (lots
> of commands/pdus/operations), large (XML encoded) and complex to parse
> (XML is easy-ish for humans and easy-ish for machines, but not fast for
> either).  And it's designed not for operational data, but for
> configuration data, which is an entirely separate beast.
>
> Could it be used?  Yes, but with the drawbacks hinted at above: a
> reduction in speed and an increase in stealing the memory CPU cycles
> from what the router really should be doing (routing).  Certainly the
> data isn't the same vein as the normal netconf data, so it would likely
> need a separate storage container running on a separate port even if the
> same protocol was used.
>
> So if it could be used, should it be used?  No....  it's just not a good
> fit.
>
> I can shoe-horn the rpki-rtr protocol into a number of other shoes, but
> none of them are right either.  Consider tftp, snmp, http, or even bgp
> itself.  They all could be used in theory, but none of them really meet
> the operational needs either (so don't get any ideas!).  Could they be
> used?  Yes.  Should they be?  No.
>
> [and I'd argue that at least one of them might be a better choice than
> netconf itself].

part of what you (wes) are getting at, and what terry/shane had
pointed at before is that there are other options. the current
rpki-rtr protocol is the first of potentially many (like sending
config to a router, you can use snmp, scp, tftp, ftp, http,
netconf...).

Maybe the real answer is, if you don't like rpki-rtr for your
deployment/environment, look to your vendor with $$ and requirements
and get them to build you a better mousetrap? This worked well for
lots of other 'solutions' on routing platforms in the past.

-chris