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

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 15 Dec 2011 15:28:04 +0100

FYI

-------- Original Message --------
Subject: Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
Date: Thu, 15 Dec 2011 00:25:04 +0100
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
To: Randy Bush <[email-masked]>, Shane Amante <[email-masked]>
CC: IETF Disgust <[email-masked]>

Let me observe that there could be middle ground to both sides here.

While I am very well aware that few of the commercial routers support
inline origin validation and rpki-rtr protocol to retrieve the abstract
of RPKI data needed for validation it seems also very clear that this is
just one possible deployment model.

Let's observe that there are going to be orders of magnitude more BGP
implementations which will never get the BGP origin validation code into
their branches yet which will still happily run in many production
networks for years to come which may be a significant obstacle to the
deployment of this functionality.

Therefor I would consider an alternative deployment model where the
validation happens (even if a bit delayed) at few distributed BGP prefix
validators around given AS then the outcome of such validation is
distributed in the form of BGP policy configuration (via Netconf) to all
legacy BGP speakers.

While perhaps risking to say unpopular comment my personal preference
would be for the latter deployment model. With this in mind I do agree
with Shane that in general IETF should try to reuse existing protocols
to accomplish the goals by recommending such deployment models which
allow one to do so rather then keep inventing more and more protocols to
address point solutions.

Best,
R.

> 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
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf