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

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 14 Dec 2011 23:25:39 +0100

Randy Bush response to that comment that I firwarded just a minute ago.

Bert
----- Original Message ----- 
From: "Randy Bush" <[email-masked]>
To: "Shane Amante" <[email-masked]>
Cc: "IETF Disgust" <[email-masked]>
Sent: Wednesday, December 14, 2011 10:42 PM
Subject: Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The 
RPKI/RouterProtocol) to Proposed Standard

>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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 14 Dec 2011 23:24:31 +0100

I don't think that our Netconf protocol was intended for this.

But I am forwarding this to the WG, so that people are aware.

Bert
----- Original Message ----- 
From: "Shane Amante" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 14, 2011 4:27 AM
Subject: Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The 

> [Resending to [email-masked]]
>
> I am curious why an IETF WG (SIDR) has endorsed a wholly new protocol through 
> which to configure policy information on routers (as proposed in 
> draft-ietf-sidr-rpki-rtr), particularly when the IETF already has existing 
> standards to do so, namely: NETCONF [RFC4741] & YANG [RFC6020]?  In addition, 
> given that NETCONF + YANG were designed for extensibility, they would allow 
> operators to take it upon themselves, if they wish, to easily enrich and/or 
> extend RPKI-validated data before it is sent from an RPKI cache to routers, 
> (compared to a binary protocol like RPKI-RTR).  I don't see any discussion in 
> draft-ietf-sidr-rpki-rtr as to whether: a) consideration was given to develop 
> a YANG model, for validated RPKI data, which then would use NETCONF to 
> securely transport that from an RPKI cache to the router; and, b) if it was 
> considered, what were the reasons that approach was not pursued.
>
> In the short-term, I am concerned that, from an architectural point-of-view, 
> the IETF has not chosen to re-use the existing set of very successful 
> configuration protocols, namely NETCONF & YANG, for the task of configuring 
> validated policy information from the RPKI to/within routers.  This could not 
> only cause confusion in the industry, but also lead to additional operational 
> costs to operators who would have to maintain two protocols for configuring 
> policy on their network: RPKI-RTR and, separately, NETCONF/YANG, particularly 
> when those same operators already have to use NETCONF/YANG for other router 
> configuration tasks anyway.  Furthermore, NETCONF is in shipping & deployed 
> implementations today vs. RPKI-RTR which is likely still several years in the 
> future before it starts shipping in GA SW releases, not including the time it 
> will take to qualify it before it sees actual network deployment.
>
> Longer term, development of a new configuration protocol, (namely RPKI-RTR), 
> likely has architectural implications given the discussion that occurred at 
> IETF 82 in the SDN "informational-gathering session", held on Thursday 
> afternoon.  Although it is a too early to tell where the discussions at that 
> SDN meeting will ultimately lead to, there did seem to be a significant amount 
> of interest in the architectural concept of looking at the problem of 
> attempting to configure networks using a top-down methodology and, in 
> particular, re-using those existing IETF protocols, e.g.: NETCONF/YANG, SNMP, 
> etc., southbound from an SDN Orchestrator toward various network elements.  As 
> such, it may be useful for the IESG and IAB to collaborate on the long-term 
> architectural implications and additional complexity that another "southbound 
> protocol", specifically: RPKI-RTR, could have on future efforts such as those 
> discussed in the SDN meeting.
>
> -shane
>
>
> On Nov 29, 2011, at 3: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.
>>
>> 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
>