I support I2RS adoption of this document. This is a very nice document. I also wanted to provide a small set of review feedback comments (marked with "CMP"):
Interface to the Routing System Problem Statement
draft-atlas-i2rs-problem-statement-01
Abstract
In order to enable applications to have access to and control over
information in the Internet's routing system, we need a publicly
documented interface specification. The interface needs to support
CMP: Where it says "In order to enable applications", I wonder if we need to
further qualify "network applications", to differentiate a custom routing app
versus a db query. Note this comment applies also to the Introduction.
This document expands upon these statements of requirements to
provide a detailed problem statement for an Interface to the Internet
Routing System (I2RS).
CMP: The acronym does not expand, "Interface to the Internet Routing System"
seems to be "I2IRS" (extra Internet).
2. I2RS Model and Problem Area for The IETF
Figure 1: I2RS model and Problem Area
CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS Agent.
For model completeness, would it make sense to add another "<-->" (i.e., within
scope) interface from the leftmost I2RS client into a different I2RS Agent?
Even something like "<-----> To another I2RS Agent".
3. Standard Data-Models of Routing State for Installation
There is a need to be able to precisely control routing and signaling
state based upon policy or external measures. This can range from
and
In addition to interfaces to the RIB layer, there is a need to
configure the various routing and signaling protocols with differing
dynamic state based upon application-level policy decisions. The
CMP: It is not clear to me what "signaling" specifically refers to here.
3. Standard Data-Models of Routing State for Installation
This means that, to usefully model
next-hops, the data model employed needs to handle next-hop
indirection (e.g. a prefix X is routed like prefix Y) as well as
different types of tunneling and encapsulation.
CMP: a nit: "indirection", or "indirection and recursion"?
5. Desired Aspects of a Protocol for I2RS
Multiple Simultaneous Asynchronous Operations: A single application
should be able to send multiple operations to I2RS without being
required to wait for each to complete before sending the next.
CMP: "via I2RS" instead of "to I2RS".
Duplex: Communications can be established by either the I2RS client
(i.e.: that resides within the application or is used by it to
communicate with the I2RS server), or the I2RS server. Similarly,
CMP: Should "I2RS agent" be used instead of "I2RS Server", for nomenclature
consistency?
5. Desired Aspects of a Protocol for I2RS
CMP: I think there are some aspects potentially missing. Specifically:
CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting for the
same route)
CMP: 2. Security (and specifically integrity)
CMP: 3. Accounting.
Thanks!
-- Carlos.
On Jul 24, 2013, at 11:53 PM, Alia Atlas <[email protected]> wrote:
> Please review draft-atlas-i2rs-problem-statement-01 and comment on whether it
> should be adopted by I2RS. Detailed technical conversation is also most
> welcome.
>
> Authors: Are you aware of any IPR that applies to
> draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed in
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
> details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
