Minutes from IRS BOF 2012.11.05, Altanta Agenda: Agenda-bashing and administrivia (chairs) Scope and purpose of BoF (Adrian Farrel) Overview of Problem Statement and Framework (Joel Halpern) Overview of Use Cases and Requirements (Shane Amante) Potential Charter (Ross Callon) Obvious Questions (Dave Ward) Discussion (all) Summary and Closure (chairs and AD) 0. Administrivia - Ross Callon Note Well was discussed. This is a WG forming BOF, so Ross will go over draft charter later in BOF. Dave will go through some questions that have been asked. No questions I. Purpose of bof - Adrian Farrel Thank you for coming. Key elements that we need to address: consensus that there is work to be done, clear focus on topics; determine if work is within the scope of the IETF (eg in either routing or operations); a critical mass of people commit to doing the work (not 1 or 2 people). No questions II. Overview of Problem Statement and Framework - Joel Halpern This is related to but not the same as use cases. We are talking about a problem, not a protocol. What is needed: - data modeling for routing and signaling state - SNMP is not a good date model for anything, - there is a challenge in modeling policy - (for models see slides) - We need a framework to integrate the external data into Routing - indirection, policy, loop-detection - we need to provide the triage that is needed for the red alert stream (ie, aid when one outage causes flood of alerts) - we are not starting on defining a protocol ? we have lots of protocols. We are starting on data models. Main concerns: - Standard Models - clear self-describing semantics - sufficient coverage for use cases needing fact - Applications are not routers - Security, authorization, and identity - we must put it in from the beginning. - It must scale to large sizes. (see diagram on slides) PAL - slides (see slides) IRS Interface Key Aspects - Multiple simultaneous asynch - some long, some short, parallel operations - Configuration? - We need to interact with the changes of configuration - (Many implementations can handle interactions to configuration) - Must know about capabilities, The applications have to know what you can do.? What IRS is not - not config, not router/signaling, not the only way,? - not to replace bgp or ospf pll out? - Not to a specific devices or not a specific case Start with a Focused Scope - small set of data-models (RIB layer) for control, - Set of events to support related use-cases, - Data-model for topology,? - investigate protocol options for the interface - define?a set of motivating use-case to drive this scope - We will fail if we try to do all if it!!!! - We have to make extensible,? IRS Policy Framework - discussion of diagram? - It has to be many-to-many, - Unfortunately - we can make the simplification of 1 to many, Policy Framework Topics - Identity? - Role - Scope - what I can read - Influence - what I write? - Resources - that persist and may consume things - Policy? - implicit policy - exists within protocols, some routers choose between - explicit policy - read and write in the configuration - Both must be represented in the protocol - Policy Actions - We came up with a start-up - We would like review Questions / Discussion - Kireeti Kompella - Are all applications network related? Joel: Long term both (network related and not). Short term focus on applications that are network aware. - Kireeti - we should go back to Minneapolis for boiling lakes instead of oceans.? Policy ? is this routing policy? Please make this clear. Joel: Two types: Policies of IRS ? IRS affects routing policy - Kireeti: Third, IRS is not a direct replacement for routing protocols. Does this mean indirect? JH: In a static (e.g. static routing - maybe) but, the assumption is that dynamic routing and signaling is in operation - Vijay Gurbani: In Paris, we had a BOF I2AX which is related to this but focused on a protocol. Don't remember this discussion there. I co-chaired. JH: We should look at the IA2EXT.?Please send info on this to the list - Bhumip K: Please do not use the term ?IRS? (this is a well known acronym for ?internal revenue service?) - Bhumip K: Is it a network API or a router API?? Joel: This is a control entity or a control commissioner.? It is talking between a control entity and the routers.?A control entity (client/commissioner) talks to one or more network nodes (e.g. routers). - Bhumip: If you are familiar with other related work in other SDOs, you should review it.? - Tom Nadeau: (Channeling Keyur Patel via jabber): IRS is supposed to augment not replace routing protocols. - Peter Lothberg: You are assuming multiple control planes talking to this. How do you arbitrate and deal with coherency? Joel: This is discussed in?the Policy document.? - Edward Crabbe: The 'application' terminology we're using is a bit confusing; ultimately all the things we're talking about are control systems and should be treated as such. Also you can replace routing protocols with this protocol, whether you intended or not. Joel: Intent is always limiting. III. Use Cases and Requirements - Shane Amante See list of documents for use cases + + a new draft will be published by Geoff Matson, after I-D window reopens. Caveat: Shane will quickly summarize contents of drafts. We are not suggesting that all use cases need to be addressed initially.? Please look at and read the use cases drafts. In my opinion, across several use case drafts, what you really will find is the synthesis of information that are outside the routing control plane, e.g.: Netflow, to ultimately help direct routing protocols to make more globally optimal forwarding decisions. I think Joel did a great job of highlighting this in his talk. Draft 1: draft-amante-irs-topology-use-cases-00 - There are existing inventory & statistics warehouse systems that something like this is going to reach out and get information from. - IRS needs to think about how to extract information from those systems. - Commonality: TE, VPN, Rapid IP & ASN renumber, etc. - Unique: Capacity planning, path computation element (PCE) - ALTO servers Draft 2: draft-keyupdate-irs-bgp-usecases-01 - BGP configuration largest in the box, RSVP-TE LSP's are second. - Having the ability to synchronize consistent BGP policies across an entire AS is extremely important, - BGP Traffic Engineering is important, as shown by Russ White in his draft. - Common - Flow spec (react to DDOS attacks) similar to white-irs-use - Optimized exit control Draft 3 Draft-white-irs-use-case-00 - Optimized exit control - BGP does not allow fine grain control - Need to react quickly to DDOS attack - Dynamically optimize flows in hub & spoke network - Inside DataCenter - Between Data Center routing - Bandwidth on Demand - Overall use cases are about: fine grain tuning of traffic flows in a network Draft 4: Geoffrey Mattson's Draft - If optical transponders are offboard, it is useful to be able to monitor bit error-rate degrading over time and tell, through IRS, IP/MPLS routers to react to that, i.e.: shift traffic away from a bad link, in order to repair it. Draft 5: Draft-medved-irs-topology-requirements-00 - Concentrated look at use case & requirements for the north-bound API - This goes from the commissioner to the application(s) above it - Clear need for a data model that can provide a common vocabulary to describe the elements IRS handles - This use case has protocol requirements Draft 6: draft-rfernado-irs-framework-requirement-00 - publish-subscribe for asynchronous notification of events that occur - p2p transport connection between client and a server, - In order, reliable data delivery in both directions, - Security requirement: server needs to validate identity of client, before allowing client to read or perform read-write actions - Important: from an application that sits above it - the application shouldn't have to worry about the mechanisms to provide services. There should be templates that can be abstracted from the network. Requirement Summary - Need standard/common vocabulary to describe the functional network components in the IP Routing System within Standards-based data models - Need "application friendly" mechanisms to retrieve information from network elements and push configuration/policies/etc. back into groups of network elements. Overall - Critical need to make globally optimized routing/forwarding and configuration changes to entire network - When trying to improve efficiency or handle DDOS attacks, need fine- grained influence over routing/forwarding mechanisms Questions / Discussion: - Russ White: Although it sounds like we are trying to boil the ocean, we are trying to list an ocean of requirements and then take a cup of ocean to solve. This isn't about replacing the routing protocols but, opening up the control plane of routers that we tweak everyday in a coordinated way. - David Lampeter: Two example use cases (changing IGP metric and ASN changes). NETMOD is modeling the routing system. When do you use NETMOD vs IRS? Shane: Need to have routing information available in a policy form, then IRS can retrieve that in NETMOD templates so that IRS can act on it. - Someone Hussein from Infinera: Feels like you are proposing a solution first and then a use case, need use cases first Shane: It's important to recognize that there are existing systems out there now (e.g. stats collections and inventory systems) that haven't been first class citizens, but need to be from PoV of IRS. This is just a straw man proposal. - SH (not sure who this was): Briefly mentioned optical enhancements, will you be looking at optical topology? Shane: Eventually, that would be nice. To get started, that's most likely too much to bite off, so am willing to focus just on IP/MPLS networks for now. - Ed Crabbe: Sounds like you are confusing what's available from SNMP Shane: There are existing protocols to talk with transponders and if we can reuse them, great but, what's missing is the coordination mechanism. Can do something very simple today via the CLI but, I hope we get beyond that. - Ed: Seems dangerous to talk about replacing all known protocols Shane: Not saying that. Saying that I want a data model, not TL1 or CLI. - Rudiger Volk: I?m confused. JH's slides showed interfaces that exercise more control. What I?m hearing from you Shane is that I want to do all control of the system and download policies. Is the goal to build multiple interacting commissioners or do we have somewhat more modest goals here. Shane: This is an entire taxonomy of use cases. Should discuss that when we discuss what is charter of WG. IV. Charter Overview - Ross Callon WGs do best with limited defined charters, OK to postpone some work to later.? Issue?that came up in discussion of draft charter that had been mailed to the irs-discuss list: Fast path vs Slow path. Fast versus slow is relative. We do not want to confuse implementation versus standards. Which protocol - an existing protocol or define a new one protocol?? - The WG needs to figure this out Initial charter ? focuses on use cases, not protocol.?I doubt we will define a new protocol, more likely we will use an existing protocol. Issue with regard to Use Cases - Tightly scoped key use cases for operational use of IRS.? - Text in draft charter states ?these use cases will include at least? (see more detail in draft charter sent to IRS-discuss list). Question has been asked: Does this preclude other use cases?? - No-- but we need to focus to make progress (Q&A postponed until after Dave Ward?s talk) V. Obvious Questions - Dave Ward How big is the community working on IRS?? - 408 members of mailing list - 11 drafts, lots of authors? - 25% operators, 35% vendors, 25% academics or other What about my use Case?? - The number of use cases being written up is greater than one - Evaluation of use case is to be considered example not canonical design - They are to make sure we have reasonable targets not the only targets for the technology, My encoding is the prettiest - No it isn't? - None are perfect today, - First we start with the data model, and encoding Recap: IRS and Programming - IRS is a mechanism to learn state from the network - (see slides)? IRS Concerns - (long list, see slides) Candidates for session and data modeling Pros: (see slide) yang, modular,? Gaps: operational state, state persistence, state ownership, HA semantics, pluggable on-the-wire, Topology tools - Current team investigating Netconf/yang applicability to IRS - Rex ferando (rex@cisco.com) - Martin Bjorklund (mbg@tailf.co) - Bruno Rijsman (Brijsman@juniper.net) VI. Open Discussion Lou Berger: Definition of topology too broad: OTN, WDM, L2, MPLS, VPN, everything. What's in scope or out of scope I can't tell. Either expand on definition or "pick this use case" Should be part of the charter for proper scoping. Margaret Wasserman: We tried a lot of time how you are going to manage devices. All have had similar problem ? if you can only manage only a subset of functionality on a piece of equipment and therefore run another "thing" to control the rest of the equipment. Why is this situation different? Why is a common subset useful now? Margaret W: Very afraid that it was stated so many times "not boil the ocean" that this causes concern. Rudiger Volk: Jamal: We are not talking about protocols, why are we talking about NC/Y? Can I write a draft on my favorite protocol? Ross: Yes David Lampeter: Classic config protocols are slow path, what is the fast path? ?: Is this SDN? A: It is related. Chris L: What are Northbound APIs on top of the commissioner and that might define what we need southbound. What can we use/abuse in the IETF Shane Amante: She may be concerned with rate of adoption ? this work is using existing forwarding and control plane protocols we have today. The most time consuming effort is deploying new control and forwarding plane protocols. The reuse of existing protocols and augmenting them is critical. Dmitri: concern of the modeling work. It should be not limited to information model first. A definition of an agent that was used by Joel may limit the work. Function and memory and need state Brian Dixon: The slow path vs fast path. Vendors should not implement this by making a gateway to the cli and the commissioner could be a CLI. The best way to view this is as not as a protocol integration but, a horizontal integration across elements across an entire network. Not all of the functions but, all the classes of behavior. Wes Hartiker: I don't think you are trying to boil an ocean but rather, a body of water on a distant planet. The body of work is bigger than behave. To avoid the design by committee is to think about: do we have to do all of this at once? Managing the multiple RIBs is hard enough. Rudiger Volk: What is the absolute key issue is the data modeling. To answer (didn?t get rest) Margaret: the work for getting a more unified solution to get to managing a device has taken decades and the data modeling for all the usual features ? to do everything (model) and request new ways for changing everything. Use cases defining data models. Working too slow or too fast ? that should be potential optimizations Peter Lothberg: Very happy to see that modeling optical devices is in there. Today they have to do 2k transactions a second. Shows of hands: People interested in helping with this work: ~40 interested in this work Should we form a WG: ~60 for WG formation ~6 for not a WG to be formed Compared to current draft charter, how many deliverables should we have: current set: 12 fewer docs: 30 wholly different: 0 Comment: Please add security ADs / Chairs: Next step is to continue to discuss charter, what docs to drop, etc. Thanks.