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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks for all the responses, Alia.

Please find some follow-ups inline.

On Aug 13, 2013, at 2:44 PM, Alia Atlas <[e-mail]> wrote:

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

Perhaps simply by aligning with the problem statement wording, in terms of "routing and signaling". Or is the "signaling" piece confined to label distribution?

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

Thanks for the clarification -- this works.

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

Fair enough -- I agree it's not within the scope here, but I do thing that tunnels require some looking into.

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

Blanked Ack for all the edits and fixes. Thanks much!

-- Carlos.
PS: and thanks for not responding earlier, others were on vacation as well :-)

> 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
> 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs