[Resending to ietf(_at_)ietf(_dot_)org]
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
ietf(_at_)ietf(_dot_)org mailing lists by 2011-12-13. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf