As you may have seen from the planned I2RS agenda, Ed and I are planning on having two significant discussions during the WG. These are to help develop ideas and consensus around what types of use-cases we have (or need) and around what types of functionality (new or new combinations) that is needed to support those use-cases.
We have a deadline of THIS JULY to publish a high-level architecture. I expect that the discussion of the functional analysis of i2rs will drive what belongs in that architecture. Please come to the meeting with your thoughts, ideas, and concerns well thought through so we can have a very productive meeting. Towards that end, I am including in this email a list of the features whose combination I believe are driving the various new use-cases. These features come from the following drafts and I would strongly encourage everyone who is participating in the discussion to READ them beforehand, since the feature description given is, of necessity, merely a short-hand that lacks the details in the drafts. Note that the drafts may, of course, have differences between them. The drafts are: http://tools.ietf.org/id/draft-ward-i2rs-framework-00.txt http://tools.ietf.org/id/draft-atlas-i2rs-policy-framework-00.txt http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement The list of features I am sending is a first pass. I might have missed some that are in the drafts. I may not have included one that you think is needed (whether in the drafts or not). Please bring those up. At the end of discussions, we hope to have a list of agreed upon new functionality - AND pointers to the use-cases that explain why and how they are needed. The use-cases should be specific cases of those in the charter (though for future-thinking arguments sake, key new features could also be discussed). So - here's what I see as new features or combinations. 1. Support multi-headed control. This drives (at least) three sub-features. a. I2RS agent-based arbitration: I2RS uses policy associated with clients/roles to determine which state to install. Policy need not just be last-to-arrive (as with CLI/NetConf). This gives a way to handle/resolve conflicts when multiple clients touch the same configuration. b. Client Ownership: Written state is tracked by client who installed it (or owns it). This determines which client can delete it and, for some cases, indicates which client can modify it (for example, a sub-tree with multiple attributes) versus simply delete/replace it. c. Notifications when written state changes: An application can learn when its written state is overwritten by another client. d. Optionally garbage collect ephemeral state when that client goes away. e. RELATED USE-CASES: i. CLI writes something and an i2rs client wants to write the same data or vice versa. ii. 2 clients want to use ACLs to direct the same traffic-flow (one client policy-routes large flows and the second client identifies suspicious flows and directs them to a DoS mitigation box) - described in draft-atlas-i2rs-policy-framework-00.txt 2. Filtered thresholded subscriptions for notifications: Network Applications use notifications to learn about the network in a push model that can be more responsive and scale better than a pull model. Such events might be everything from a link over a particular threshold to a next-hop changing on a route of interest to a route being successfully installed into the forwarding plane. 3. Different Operation Models: a. Persistence: permanent survives reboots & ephemeral doesn't b. Start-time modes - immediate/temporal/triggered c. State Expiration - unbounded or temporal 4. Standard data-models for read/write: some may already be in progress in netmod (if YANG ends up being the selected data-modeling language) a. RIB interactions: static routes, redistribution to other protocols, varying admin-distance, etc. b. BGP policy c. IGP local policy: local link metrics, attached prefixes, etc. d. PIM local policy: local listeners, etc e. topology f. Etc - based on use-cases: framework suggests a number of different areas 5. Client limited authorization: Network applications have limited authorization to both read and write based upon role. In particular, for topology, a client should be able to learn a subset of topology and not need very high trust/testing to learn. (e.g. IGPs may provide active topology, but peers must be trusted & tested not to add in or modify data owned by other network elements). 6. Expose topology at different abstraction layers a. Service topologies (i.e. points of presence and connections) b. VPN topologies c. Potential/previously active links? 7. Multiple transport sessions: Allows multiple senders and receivers on the network element and on the client side. Allows different levels of encryption, replay, etc. as appropriate for the data exchange. a. USE-CASE: Sending lots of notifications (statistics, analytics) from line-cards directly. 8. Client has ability to prioritize its own operations: This supports ASAP vs. in-flight on a single transport channel as well as providing an aid for sending operations on multiple channels. 9. Role-based Client Identity not tied to a transport : A single network application can be distributed across multiple devices and for recovery, it's important for an application to identify as a particular client, even with a different IP address, different TCP session, etc. 10. Speed of programmatic interface - ability to react to operations in sub-second times. Fast is hard to tie down to a particular feature, but it clearly plays a role in what kinds of use-cases are possible. Any suggestions on how to better describe this would be useful. Other functionality that isn't "new" but we do need to decide upon are generally things like: i. Atomic operations: All the data sent to be read or written in a single operation is done only if all parts can be done (i.e. written). This may have size limitations to be discussed. It's not quite a full transaction model, where a client can send multiple operations and an explicit done. Exact details of what this means need to be specified. ii. Read Locks/Claiming Ownership: For data that can be written, a client may need to take ownership to prevent that data from being changed (by a lower precedence client). An example would be where a client makes a decision to write X based on a piece of data being Y (classic read and increment by multiple writers). iii. Rollback or expiring an operation: Is rollback done by the client (my assumption)? When an operation expires, does the state go back to either the default or the next highest client's stored operation (which might be CLI)? Please think and then jump in and start talking! Regards, Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
