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

From: Randy Bush <[email-masked]>
Date: Thu, 15 Dec 2011 15:56:44 -0800

[ people whacked me to resend to sidr list ]

I am not sure if this is an architectural misunderstanding V a red
herring.

As you say, NetConf is for *configuring* routers.  RPKI-rtr is not used
for router configuration, but rather dynamic data, a la IS-IS or BGP.
In fact, the RPKI-rtr payload data go into the same data structure as
the BGP data.

Of course, the configuration of the RPKI-rtr relationship to cache(s) is
router configuration, similar to configuring BGP peers, and presumably
can be done by NetConf on those platforms which support NetConf.

Bottom line: NetConf 'replaces' the CLI, not BGP.

FWIW, two or three years ago, not wanting to reinvent the wheel, we
looked at NetConf-style payload packaging.  After all, Bert and I
chartered NetConf back in the day.  I still owe a dinner to the two
NetConf folk who helped try.  Unfortunately the mismatch was
non-trivial, though nowhere near the mismatch of DNSsec, at which we
also looked (as the Tonys and I had published in 1998, Lutz in 2006,
etc., of which I presume you are unaware).

When we evaluated the data bloat for NetConf-style packaging we were not
cheered.  While probably not important for a CLI replacement, for a
continuous dynamic protocol the overhead of unpacking XML and decoding
the contained ASCII payload drew unhappy whining from the router
hackers.

NetConf is not ideal for a long-session back-and-forth protocol, with
RPKI-rtr's serial number exchange which leaves the router in control of
the exchanges and enables incremental update of the data.  You *really*
do not want the cache to send the full data set to the router every
time.  And you definitely do not want a cache trying to keep track of
the state of O(100) router clients which may or may not still think they
are its friend.

And, sadly, NetConf is not available on significant platforms where
RPKI-rtr is already running today.

So, all in all, being lazy, of course we tried.  But it was not a good
fit.  Of course, if you want to have a go at it, I am sure we would be
willing to at least kibitz.  But first you might want to talk to the
vendors who have already implemented RPKI-rtr to see if they would be
willing to re-code.

randy

---

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Dec 2011 09:21:35 -0500

On Nov 29, 2011, at 5:51 PM, The IESG wrote:

> 
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'The RPKI/Router Protocol'
>  <draft-ietf-sidr-rpki-rtr-19.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-12-13. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

Support.

I have (carefully) read and reviewed this document and support publication….

W

> 
> Abstract
> 
> 
>   In order to formally validate the origin ASs of BGP announcements,
>   routers need a simple but reliable mechanism to receive RPKI
>   [I-D.ietf-sidr-arch] prefix origin data from a trusted cache.  This
>   document describes a protocol to deliver validated prefix origin data
>   to routers.
> 
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>