Thanks for all the responses, Alia. Please find some follow-ups inline.
On Aug 13, 2013, at 2:44 PM, Alia Atlas <akat...@gmail.com> 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) > <cpign...@cisco.com> 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 <akat...@gmail.com> 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 > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
