Welcome to PiratePad!
raft Agenda for the IRS BOF at IETF 85
Monday November 5, 2012
1740-1940  Afternoon Session III, Salon D

• Agenda-bashing and administrivia (chairs) 
  • IPR note-well was discuss
  • This is a working group forming BOF so Ross Callon will go through a potential charter
  • Dave Ward will go through the questions
    
    

Scope and purpose of BoF (Adrian Farrel)

•  Thank you for coming, those who have desires for elsewhere will be in the bof,
• (see slides) 
• Key elements (from slides) 
  • consensus there is work to be done,
  • clear focus on topics,
  • Work is "within scope" of IETF (it could go to routing and/or operations)
  • Critical mass commits to do work(more than 1 or 2 people)
• Now.. to chairs to run the meeting
  
  
• Overview of Problem Statement and Framework (Joel Halpern)
  • [see slides] 
  • related to but not the same as the use case. 
  • We are focusing on a problem where applications need to know dynamically
    • We are talking about a problem, and not a protocol.
  • What's needed 
    • Data modeling for Routing for Routing & Signaling State
      • SNMP is not a good data model for anything,
      • There is a challenge in modeling the policy and the models
      • (for models see slide)
    • We need a framework to integrate the external data into Roting
      • indirection, poicy, loop-detection
      • We need to provide the triage that is needed for the "red alert" stream
    • We are not starting at protocol - we have lots. 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, & identity
      • we must put it in at the beginning, Security people tell me it can be added on later.
    • It must scale to large sizes
  • (see diagram on slides)
  • PAL - slides (see slides)
  • IRS Interface Key Aspects
    • Multiple simultaneous asynch
      • long short, some short, parallel opertions
    • Configuration 
      • We need to interact with the changes of configuration
      • (Many implementations can handle interactions to configuration)
    • Must know about capabilties, The applications have to know whatyou 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,
    • Unfortunatey - 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
• Discussion
  • Kareeti - you are saying application? I see in the use cases that are app
  • Joel: The long term answer is both. We want data center orchestrator to do this eventually.  The short term may be the network-aware,
  • Kareeti - we should go back to Minneapolis for boiling lakes instead of oceans. 
    • I think your policy is different than your policy. 
  • Joel: The IRS policy is different
  • Joel: In static it may be possible. In my view it will be with routing protocols.
  • -----: IA2EXT - we had a bof to converge in Paris.  We were lloking.
  • Joel: We should look at the IA2EXT. 
  • Bombi: Please do ot use the work IRS. Try to come with the word IRS.
  • Bombi: Is it a network API or a router API? 
  • Joel: This is a control entity or a control commissioners.  It is talking between a control entity and the routers. 
  • Bombi: If you are familar with other things in the other SDOs, you should review it. 
  • Tom Nadeau: (Channeling Keyur Patel): IRS is suppose to augment not replace.
  • Peter: You are assuming multiple control planes talking to this. Have you looked into the arbirtration in time (yesterday and today).  
  • Joel: This is described in  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. The second comment is that you can replace routing protcols with this protocol.  Whether you intended or not.
    
    
• Overview of Use Cases and Requirements (Shane Amante)
  • See list of documents for use cases + a few more produced. 
  • Caveat: There are going to quickly summarize contents of drafts. We are not suggesting that all use cases are being addressed first. 
  • Look and read the use cases drafts.
  • In my opinion across several use case drafts is the synthesis of the information that the routing control plane has it. I think Joel did a great job of highlighting this draft.
  • Draft 1: draft-amante-irs-topology-use-cases-00
    • There are inventory warehouse system that something like this is going to reach out and get information from.  
    • IRS needs to think about get interfaces into those systems.
  • Commonality: TE, VPN, Rapid IP & ASN renumber, 
    • Unique: Caapcity plannig, path cmputation element (PCE)
    • ALTO servers
  • Draft 2: draft-keyupdate-irs-bgp-usecases-01
    • BGP configuration largest in the box, MPLS-TP is second.
    • Having the ability to synchronize and migrate is extremely important, 
    • Consistent policy is critical
    • Traffic engineering - is important as shown by Russ White, 
    • Common
      • Flow spec(react to  DDOS attacks) similar to white-irs-use
      • Optimized ext 
  • Draft 3 Draft-white-irs-use-case-00
    • common
      • optimized extit control - bGP not fine grain control
      • reacting to DDOS 
      • dynamic optimize flows in hub & spoke network,
      • Inside DataCenterRouter 
    • Unique
      • Between Data Center routing - Bandwidth on Demand 
      • Fine grain tning of traffic fows in a network
  • Draft 4: Geoffrey Mattson's Draft
    • Optical are off-board, It is intriguing to be able to monitor bit error-rate be able to be monitored across a number of links,
    • It is important to move a number of traffic
  • Draft 5: Draft-medved-irs-topology-requirements-00
    • Looks at the north-bound API - 
    • This goes from the comissioner to the application 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
    • public-subscribe for Asynchroous notification fo events that occur
    • p2p transprot connection between client and a server,
    • In order, reliable data delivery in both dirctions,
    • Security requirement: server needs to validate identity of client, before allowing client
    • Important: from an application that sit 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/comon vocabulary to describe the functional network components in the IP Routing System within Standards-based data models,
    • Need "application friendly" Mechanisms 
  • Overall -critical need to make globally optimized routing/forwarding and configuration changesto entire network
    • When you trying to improve efficency or handle DDOs, there is no mechanism to be able to provide routing
    • 
      
• Discussion after Shane: 
  • Russ White: It may sound like we boiling the ocean.  You need to be able to look at these use cases to choose the right cup out of the ocean.
  • Russ White: No. 2, Peter ter thought we were looking to replace. We manage today to the exception.  
  • (missed section - tool lock out) 
  • Shane: I would 
  • Edward: The SNMP function is already there in many places.
  • Shane: I think you should address the comment the author.  You can now log into the CLI and make some changes. I hope that you can provide a bit better in the IRS. It is a gray area of policy.
  • Edward Crabbe: with regard to interfaces to structured time series datasource - seems quite broad.  
  • Shane: I am already using SNMP to collect data. What I want is a data model that sits on top of the data warehouse, that can give me 95% above utilization - then the IRS commissioner. 
  • Edward Crabbe: That is broad in scope.  
  • Shane: Some networks may not be as fancy as yours, and get to use SQL:   comment: this doesn't really have anything to do with fancyness - what we seem to be talking about here is a statistical macro language for performing all manner of *very common* basic operations (means, quantiles, IQR, smoothing of various types etc) ...  my main concern here is that the set of potentiatl operations here is sufficiently broad that it's not worth describing in a(nother) standardized statistical macro language -edc
  • Rudieger: Looking at the slides that Joel was showing shows ways to get network elements and access network controls. When I hear Shane, I hear multiple interactions.  Is the system to give my customized BGP usage.  Or do we have more modest goals. 
  • Shane: This something for the WG to decide. This is a taxonomy of the possible topics.
  • Potential Charter (Ross Callon)
    • (see slides) 
    • WG are best with limited defined charters, OK to do it later. 
    • Issue  - Fast path vs Slow path
      • this is realtive
      • we do not want to confuse  implementatio verus standards
    • Which protocol - an existing or define a new one protocol? 
      • WG needs to figure this out
      • Initial charter - looks at use caes, not change. 
      • I doubt we will define a new protocol, we will use another.
      • Only use cases
    • Issue -Use cases
      • Tightly scoped key use cases for operational use of IRS. 
      • These use cases wil include at least: 
      • Does this preclude other use cases? 
      • No-- but we need to focus, focus, focus to make progress (smile)
    • See charter for 
• Questions: 
  
  

Obvious Questions (Dave Ward)

• How big the community working on IRS? 
  • 408 members
  • 11 drafts, lots of authors 
  • 25% operators, 35% operators, 25% of academics,
• What about my use Case? 
  • the number of use cases being written up is greater than one, counting,
  • 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 Prograammign
  • IRS is a mechanism to learn state from teh ntework
  • (see slides) 
• IRS Concerns - a long lsit
• Role of netconf & Yang
  • 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)
• 
  
• Discussion on the Charter 
  • Lew Berger: This theobvious comments and use cases that had lots of things in scope.  We need to be tighter.
  • Ross: Is this before the working group, or after the working list. 
  • Lew: I think it needs to be part of the chartering activity. 
  • Margaret: I think that it not clear that there is a incoherent set of work. 
  • Ross: This work will only be useful if there is one or more use cases that the network operators is there. At the same time the usecase needs to be small enough.
  • Margaret: it is tricky because operators have many types of use cases. Why would they want they want to have multiple interfaces?  
  • Ross: Operators are behind you in the line. 
  • Rudiger Volk: I was suggest to come back with an answered question.  I will stay out of answering Margaret.  This is tools for interactions for pieces between of system wide management.  
  • Dave: What I wrote was multiple signaling  .... (missed)
  • Rudiger: I write my system to write something to define my whole network - that is outside the whole network. Something within the manager for the interfaces.
  • Dave: The goal is to have a better control of the logical topology from a central control place. 
  • Rudiger: It is the tools for newly created manager.
  • Jamal: Why did we talk about netconf/yang?  
  • Ross: It is not a requirement. 
  • Jamal: I can write about my favorite protocol.
  • I____: The configuration protocols are slow path, and you 
  • Dave: The current slow path is "text" based script.  
  • ___: I can do this with my system.
  • Dave: Type make and see how much it impacts the system.
  • ___:  Why don't you have a manager to yang andnetconf. 
  • Dave: Even you have a agent that speaks a protocol and parsing. If you want
  • to put this in a routing network node?
  • Behcet: Is IRS equivalent to SDN?
  • DAve: Given SDN is everyting -- then it is SDN?
  • Chris L. :  What do we need to have on interfaceto go up? (north bound api)
  • Dave: Our first step was to determine 
  • Chris L: It would be a good test after we get the use case, to just be targeted. 
  • Dave: We will use, abuse, and co-op.
  • Shane: To respond, I'm not worried about rate of adoption. We are not looking for ew protocols.  To me as an operator, the most difficult time consuming protocol to put in the network is new forwarding protocols. It would be best to put new software on the existing forwarding plane. Even if we forgot something we can rev the software and put it out on the network.  If the operators want to make sure nothing gets left out. I'm here and I know there are others.
  • Dimitri: We were focusing on states and and information, and the going functions that will suggest going point. 
  • Dave: We can include states or going function. 
  • Dimitri: It is clearly that we should have functions that are equip by memory.  We should put this in the charter. 
  • Brian: Simple observation: Slow path versus fast path.  This is not a gateway to the CLI. The CLI could be a commissioner in the box.
  • Brian:  To address Margaret's concern, you might want to have some element of the bgp control plane managed across the control plane. 
  • Wes: You are trying to boil a body of water - you are looking a body of water on another platform. Just managing the rib is sufficient. Why can't this be segement? 
  • Rudiger Volk: Now I come to answering Margaret - the key issue is the data modeling. 
    • Let me answer Margaret was that the SNMP modeling was not convenient to be worked on. 
    • The work to get a unified model for SNMP has been long. The routing models is too much. The modeling to do too much is handling. 
    • It might be a use case models to present data models. 
    • This whole network is more complex that the simple element. 
    • It is dangerous to boil.
  • Dave: This is the charter is to focus on requirements, RIB, policy, IRS. This not a receipe for boiling the ocean. 
  • Rudigier: For the consideration - is this too slow or too fast?  This is potential issue.  But the too fast/too slow
  • [note taker: The request for Rudigier in the model]
  • PEter; What they need to in some of the use cases? 
  • 
    
  • Adrian: Bring it home. 
  • Dave:
    • Who will work onit: 30+ in room (?) 
    • who thinks should working group: most in + in room 
    • not working group: 4-6 people 
    • 
      
  • Adrian: 
    • I'm nervous that we need to nail the charter to my use caes?
    • Three question
      • Do you want this set of documents to charter? (5-10) 
      • Set of documents should be fewer? [not done] 
      • A wholly different: none: 
• Anyone ask about mutlicast? or IRS-TP? 
• Dave: We'll built it but not at this standard body? 
• 
  
• Adrian: It calls the difference between an informational and data model.  People should look at RFC3444 - find the abstract work. Not the encoding. 
• Dave: Thank you, we do understand the informational model is what you got scoped down to. 
• Keerti- Will there be IRS mib? 
• Dave: We'll take you to push this. 
• 
  
• Adrian: Talk and working on this on the mail list. Talk about on the mai list. 
  
  

Discussion (all)

Summary and Closure (chairs and AD)