[RTG-DIR] RtgDir review: draft-ietf-i2rs-architecture-09

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 05 June 2015 19:28 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2446B1A87C3; Fri, 5 Jun 2015 12:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id og6SYRgopOeB; Fri, 5 Jun 2015 12:28:00 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDF81A8769; Fri, 5 Jun 2015 12:28:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29478; q=dns/txt; s=iport; t=1433532481; x=1434742081; h=from:to:cc:subject:date:message-id:mime-version; bh=83BQGCOHgjXGleF7aGVwMFJYDnNwUgahp1twuO8Le0w=; b=WDtbv94WAKVUI36FThGNQeQ2+E/nmUeRiq6cdL4RnHkSnOqlUMUEBRLa VAWKjK5orXu8CqLRewRHa1MwlFLs5LWptMLP/9jpzRs7lHscbmCkWiDbs F3Bzbp4KLehcOiqRtyh+XUMuKzahYFT+0qK4tJSzrwJC2K2N0sITCZnn/ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,560,1427760000"; d="scan'208,217";a="422591918"
Received: from alln-core-8.cisco.com ([]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2015 19:28:00 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com []) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t55JRx11008289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 19:27:59 GMT
Received: from xmb-aln-x02.cisco.com ([]) by xhc-rcd-x04.cisco.com ([]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 14:27:58 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-i2rs-architecture-09
Thread-Index: AQHQn8W6rvwY+AJuVk+0B+kfuDjiVw==
Date: Fri, 5 Jun 2015 19:27:57 +0000
Message-ID: <184B72FD-2B4A-4BBA-956B-54AC32431C4C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_184B72FD2B4A4BBA956B54AC32431C4Cciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/LpK4hEDLRC8-TrQOmRE8oEIhbws>
Cc: "draft-ietf-i2rs-architecture.all@tools.ietf.org" <draft-ietf-i2rs-architecture.all@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: [RTG-DIR] RtgDir review: draft-ietf-i2rs-architecture-09
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 19:28:04 -0000


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-i2rs-architecture-09
Reviewer: Carlos Pignataro
Review Date: June 5, 2015
Intended Status: Informational


• I have some *minor* concerns about this document that I think should be resolved before publication.


This is an extremely well written document that describes the basic architecture, modules, and interfaces for interfacing with the routing system. Its status targets Informational. idnits reports no real nits, only some noise.

Thank you for this document!!! I hope you find these comments useful.

Major Issues:


Minor Issues:

An Architecture for the Interface to the Routing System

   This document describes an architecture for a standard, programmatic
   interface for state transfer in and out of the Internet routing

CMP: Is this “an architecture”, and there are other architectures for the I2RS? I have no issues with “an architecture”, but it invites these questions, including ‘is there an authoritative architecture, and is it this one? “The IETF defined architecture”? How about removing the “An” from the title, and qualifying the Abstract and Intro with “as specified in the IETF”?

1.  Introduction

   Network-oriented applications require
   easy access to this information

CMP: The concept of a “network-oriented application” is a super important piece of the whole picture. While the applications are outside the scope of the architecture itself, the network-orientedness nature is a key driver, unacknowledged as a key architectural property, and only revisited half way down the document in Section 5. One thought for your consideration: does it make sense to make this explicit in Section 1.2, Architectural Overview, which only defines “Application”, or as a driver in S1.1? Just a thought.


CMP: Models — wc says there are 18 instances of “data model” and 13 of “information model”. While there are statements in the Intro like “Fundamental to the I2RS are clear data models”, I think the text would benefit from a centralized small sentence that explains the requirements for information as well as data models for I2RS modules and services. The closest is the 1st sentence of S3.3, perhaps, but what’s required?

1.2.  Architectural Overview (and Figure 1)

   In the
   figure, Clients A and B provide access to a single application, while
   Client P provides access to multiple applications.

CMP: “Clients A and B provide access to a single application” this can be interpreted as a single Application “X” accessing both Clients A and B. I would add a “, respectively” for exampel to disambiguate.

CMP: Also, there is no text specifying whether an application can access I2RS services via more than one Agents.

6.4.1.  Routing and Label Information Bases

   Routing elements may maintain one or more Information Bases.
   Examples include Routing Information Bases such as IPv4/IPv6 Unicast
   or IPv4/IPv6 Multicast.  Another such example includes the MPLS Label
   Information Bases, per-platform or per-interface.

CMP: or per-context (instead of/in addition to per-interface)?

8.  Operational and Manageability Considerations

CMP: Might be useful to add traceability of interactions of I2RS as a consideration.


CMP: Some nits, small editorials, and suggestions for your considerations:

1.  Introduction

   Routers that form the internet routing infrastructure maintain state
   at various layers of detail and function.  For example, a typical

… [and]

   today's routed networks.  The I2RS is a programmatic asynchronous
   interface for transferring state into and out of the internet routing

… [and]

   Routing and Signaling:   This block represents that portion of the
      Routing Element that implements part of the internet routing

CMP: s/the internet/the Internet/ (or an internet? I think the meaning is “the Internet”)

1.1.  Drivers for the I2RS Architecture

   The I2RS architecture facilitates obtaining information from the
   router.  The I2RS architecture provides the ability to not only read
   specific information, but also to subscribe to targeted information
   streams and filtered and thresholded events.

CMP: s/streams and filtered and thresholded events/streams, filtered events, and events subject to a threshold/

1.2.  Architectural Overview

      *  An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a
         forwarding plane and associated RIB Manager,

      *  A server that runs ISIS, OSPF, BGP and uses ForCES to control a
         remote forwarding plane,

      A Routing Element may be locally managed, whether via CLI, SNMP,
      or NETCONF.

CMP: Some of these acronyms require expansion on first use. See https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

1.2.  Architectural Overview

   I2RS Agent:   See the definition in Section 2.

   I2RS Client:   See the definition in Section 2.

CMP: This section describes the architectural elements. Section 2, however, defines “terminology”. I would move the definitions of agent and client to this place.

   Static System State:   An I2RS agent needs access to static state on
      a routing element beyond what is contained in the routing
      subsystem.  An example of such state is specifying queueing

CMP: s/queueing/queuing/ ? Not sure :-)

   read scope:   The set of information which the I2RS client is
      authorized to read.  The read scope specifies the access

CMP: s/which/that/

   not yet available.  Instead, each router uses different information,
   different mechanisms, and different CLI which makes a standard
   interface for use by applications extremely cumbersome to develop and

s/which/, all of which/

   identity within NACM [RFC6536] can be specify as either a user name
   or a group user name (e.g.  Root), and this name is linked a scope
   policy that contained in a a set of access control rules.

CMP: Duplicate “a”

   scope policy.  Multiple identities may link to the same role (e.g
   ability to read I2RS RIB).

CMP: s/e.g/e.g.,/  Managing Variation: Object Classes/Types and Inheritance

  Clients which only want
   basic capabilities can operate purely in terms of base or parent
   classes, while a client needing more details or features can work
   with the supported sub-class(es).

CMP: s/which/that/

7.4.  Scope Policy Specifications

   As section 4.1 and 4.2 describe, each I2RS Client will have a unique
   identity and it may have a secondary identity (see section 2) to aid
   in troubleshooting.  As section 4 indicates, all authentication and
   authorization mechanisms are based on the primary Identity which
   links to a role with scope policy for for reading data, for writing

CMP: Duplicate “for”


CMP: s/data-model/data model/g (unless used as an adjective :-)

— Carlos.