Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12)

[Alia Atlas <[e-mail]>]

Hi Carlos,

Thanks for the review and comments.  I apologize for the delay in
responding.  I took some vacation after IETF.


On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> 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?
>
[Alia] True - I've removed "and forwarding data"


> 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.
>

[Alia] I see them as grouped into "routing and signaling" and definitely
part of I2RS.  The problem-statement draft (not a WG draft yet) clearly
states:
"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." and the framework draft
that this architecture replaces had a slightly larger section on use-cases
and examples.

What is your specific concern and how would you want to see the reach and
scope confined in the architecture draft?


>
>    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".
>

[Alia]  First, the I2RS clients should be I2RS agents.  I've fixed that.
 Second, these are a bit further reaching.  For instance, learning about
link up/down events, subscribing to counters for when they go over a
particular threshold, etc.  Basically, to provide the information necessary
for a network application's feedback loop, information outside of the
routing system may be necessary to read/learn.  The exact details will
depend on the use-cases and proposed info-models.

Do you think that a text change is needed?  If so, what would you suggest?


>
> 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.
>

[Alia] Sure, it's clear that the broker model is of interest.  I'll add in

   secondary identity:  An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example use is when
the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has
requested a particular operation.


> 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).
>

[Alia] Yes, tracking the attribution of operations allows aspects like
accounting and troubleshooting.  I've modified the sentence to end:

...identifier that can be provided by the I2RS client to the I2RS agent for
purposes of tracking
attribution of operations to support functionality such as 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"?
>

[Alia] Sure - I'll upgrade it to "should indicate".  This is a question of
supporting the broker model of an I2RS client for ease of troubleshooting.


>
> 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?
>

[Alia] Tunnels aren't interfaces - but the details of what should be in the
topology depends on the topology info-model and isn't specified in the
architecture.


> 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.
>

[Alia] BGP is already mentioned as a protocol that will need an info-model.
 I guess I think of this section as discussing the transport LSPs and
associated protocols as compared to the MPLS services.  The MPLS services
are part of routing and should be included too.  I've changed the text in
Sec 5.4.3 to read:

"The I2RS agent will need to interact with the protocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc)."




> 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?
>

[Alia] There may be cases of data streams that don't require a reliable
underlying transport.  I'm thinking about providing statistics streams.   I
am concerned about the issues with timely delivery that can arise with TCP
- but I think that what transport protocol is appropriate will depend a bit
on what data is being delivered.

Thanks again for the detailed review and questions,

Alia

Thanks,
>
> -- Carlos.
>
>
> On Jul 24, 2013, at 11:52 PM, Alia Atlas <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i2rs
>
>