I support I2RS adoption of this document. This is a very solid start with a very well written individual draft.
I also take the chance to share some questions and provide some review feedback
(with "CMP"):
An Architecture for the Interface to the Routing System
draft-atlas-i2rs-architecture-01
1. Introduction
The I2RS, and therefore this document, are specifically focused on an
interface for routing and forwarding data.
CMP: "and forwarding data"? Ultimately the interface will influence forwarding,
but is it focused on it?
1.2. Architectural Overview
Routing: This block represents that portion of the Routing Element
that implements part of the Internet routing system. It includes
not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM,
RSVP-TE, LDP, etc.), but also the RIB Manager layer.
CMP: Things like LDP and RSVP-TE are counted as "routing". It is not clear to
me that we might want to lump it together here, and frankly what the scope for
these things is. I suspect it might be worth clarifying the reach and scope of
these.
I2RS Client: ... It interacts with the I2RS clients to collect information
from the routing and forwarding system.
CMP: I also wonder whether these references to interaction with the "Forwarding
system" refer to MPLS dataplane encap or are further reaching, and how. For
example, creating a Tunnel would not be "forwarding".
2. Terminology
identity: A client is associated with exactly one specific
identity. State can be attributed to a particular identity. It
is possible for multiple communication channels to use the same
identity; in that case, the assumption is that the associated
client is coordinating such communication.
CMP: It seems to me that the "client identity" is necessary, but sometimes not
sufficient. I recall seeing an "Application Identity" somewhere in this
document, and wonder if that concept should not be elevated in the requirement
priority.
3.4. Authorization and Authentication
I2RS clients may be operating on behalf of other applications. While
those applications' identities are not need for authorization, each
application should have a unique opaque identifier that can be
provided by the I2RS client to the I2RS agent for purposes of
tracking attribution of operations.
CMP: It seems to me that the identity of an application is also critical for
Accounting (and troubleshooting).
4. Network Applications and I2RS Client
When an I2RS Client interacts with multiple network applications,
that I2RS Client is behaving as a go-between and may indicate this to
the I2RS Agents by, for example, specifying a secondary opaque
identity to allow improved troubleshooting.
CMP: Should this be stronger than a "may indicate"?
4.1. Example Network Application: Topology Manager
One example of such an application is a Topology Manager. Such an
application includes an I2RS client which uses the I2RS protocol to
collect information about the state of the network. The Topology
Manager would collect device and interface state from devices it
interacts with directly.
CMP: Tunnels are some times key elements in a topology. Are tunnels considered
as "interfaces" or should those be called out explicitly?
5.4.1. Unicast and Multicast RIB and LFIB
Network elements concerned with routing IP maintain IP unicast RIBs.
Similarly, there are RIBs for IP Multicast, and a Label Information
Base (LIB) for MPLS.
and
5.4.3. MPLS
The I2RS Agent will need to interact with the knobs that policy
attributes that control LDP operation as well as RSVP-TE based LSPs.
CMP: While I think that programmatically interfacing with MPLS information is
useful, the case is not clearly described in the problem statement, nor it
seems to be captured comprehensively here. Section 5.4.3 includes only a big
broad statement, but it's not clear which elements of label distribution
protocols (i.e., BGP also seems missing here) are relevant to I2RS.
6.1. Protocol Structure
protocol. That protocol may use several underlying transports (TCP,
SCTP, DCCP), with suitable authentication and integrity protection
CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP?
Thanks,
-- Carlos.
On Jul 24, 2013, at 11:52 PM, Alia Atlas <[email protected]> wrote:
> Please review draft-atlas-i2rs-architecture-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-architecture-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
