Administrivia (E. Crabbe, 5') Note well. Chairs emphasized importance of having discussion on the list, and also warned against publication of skeletal drafts without quickly adding substance. Working Group Status (E. Crabbe, 5') A little behind schedule for milestones but overall not too bad. All agenda items but one are based on drafts except for Jan Medved's presentation on Netconf. Some important drafts did not request time for presentations at this meeting. Robin from Huawei: made comment about sending a draft. draft-ietf-i2rs-rib-info-model-01 (Jan Medved presenting) aligned info model with netmod-routing draft Q (Scandanavian sounding name): are there any persistent items in i2rs? A: No Joel Halpern made observation about specifying what is supported in an information model. Negotiation of support for options will be needed. Chairs agreed. Lucy Huawei: Any requirements for something related to interfaces (?) Jan answered no. Comment about BGP-info model draft ---------- draft-rfernando-i2rs-protocol-requirements-00 (J. Medved, 15') what do protocol requirements drive? Jamal Hadi Salim: Q: why is encoding part of requirements? A: (Jan) performance E.Crabbe: These requirements are extremely prescriptive, so read it and comment on the list about what you disagree with. Alia: read it. ----------- draft-clarke-i2rs-traceability-00 (J. Clarke, 10') Consider traceability early on as opposed to an afterthought to avoid screen-scraping later. Q: Jamal Hadi Salim: Why not use syslog? A: syslog could be used as transport, but syslog doesn't provide a format EC encourages more reading of draft and more discussion on list. -------------- draft-amante-i2rs-topology-use-cases-01 (J. Medved, 15') and draft-medved-i2rs-topology-im-01 Q to answer: Is network topology in scope for the WG? Chairs encouraging list discussion about topology, and resolution in the next few weeks. Present mode of operation for topology info is very fragmented. Proposing topology manager entity to abstract this. Joel Halpern argues that abstracting network topology is out of scope, not in charter. Quoting of charter. Linda Dunbar - how is this different from Alto? A: goal is somewhat similar, but YANG approach seems better. Ron Bonica: support Joel Halpern that WG should not take on too much work. EC: people are eager to work on it, so let them do it. Alia maintains that abstraction of topology information for application is in charter. Lucy from Huawei: Lots of different network types (virtual, overlay, etc.) Does this model support different A: Base model, then other models inherit characteristics. Observation from other WG chair: finite amount of cycles in WG, so need to prioritize. Eric Nordmark(?) - How do the device view and network view fit together? Jan: Network models are easier than device models. This work is network model. -------------- draft-medved-i2rs-topology-im-01 (Jan Medved) no questions specifically on this part. -------------- draft-swhyte-i2rs-data-collection-system-00 (S. Whyte, 15') this would potentially broaden the scope. 80-90% of work in Netconf and i2rs does not address bulk data collection. Maintains that basically all we have today is SNMP. All state is not created equal, but create a framework that can accommodate these different classes of data. Control plane will consume monitoring data in SDN and i2rs. Use case classes: retrieve large data sets, with high resolution, w/o consuming too much CPU and memory Synch and Asynch, streaming and one-off, push and pull. Get data off box quickly and let NMS be concerned about other requirements. Jeff Hass, Juniper, would like to see timeliness and atomicity addressed. May have a large impact on implementation. Robert Raszuk - why haven't you mentioned MRT (multi-threaded routing toolkit) Eric Nordmark(?) - what do you do if a subscription is not working. A: Problem of NMS. Tina, Huawei: why can't SNMP do this? A: SNMP can't do the desired functionality listed in the draft. Russ White, Ericsson: 1) concerns about protocols are early. 2) these are use cases to drive data models that i2rs adopts 3) requirements are important, but too early to A: not trying to prescribe protocols, but make sure that the framework. Example: Netconf and ssh and TCP, but monitoring doesn't necessarily need encryption. Alia: This is the kind of discussion going on in arch draft. Multiple channels. Feedback loop is good. Jamal: If some counters can get dropped, be careful about choosing the transport protocol. Q: what does streaming mean? Ed doesn't like streaming term either. Jamal suggests looking at FORCES. Jeff Haas: MRT gives snapshots for BGP. Why Ed likes MRT as much as the next guy, possibly more. Anon Q: Off-loading would allow better monitoring model. Anon Q: Are there authentication requirements? A: this draft doesn't say much. Chairs: arch has requirements. Take more discussion to list. ------------------------------ draft-ietf-i2rs-architecture-00 (A. Atlas, 20') review of issues: #1 indirect interactions: Leave as is. #2 persistence: agreement Side topic: agent failure: #3 operations immediate and continuous Support #4 templates for QoS and Policy #5 client redundancy Lively discussion. Added text. Seems to be good enough. Alia requested that people speak up if they want more changes and no one spoke up. Chairs will wait a few weeks for any more feedback to percolate. ------------- draft-krishnan-i2rs-large-flow-use-case-00 (R. Krishnan, 10') how to do good load balancing in the presence of long-lived large flows? Detect (network or application) Rebalance ( local vs. global) I2rs contribution to this use case would be policy-based routing, setting up LSPs, and possibly abstraction of ECMP weight configuration. Russ White, Ericsson, 1) Suggests not using just BW percentage. 2) Confusion about end-to-end vs. per-link 3) Changing weight on lag links should include directly modifying forwarding entries. 4) He likes this use case even if in the end i2rs decides not to address this. Linda Dunbar Q: will i2rs allow one to modify ACLs. A: policy-based routing is a form of ACL, so yes. Tina, Huawei: suggests that this can be solved with some other techniques, not using i2rs. Krishnan: Most of what we can do in i2rs can be solved with i2rs. Robin: what about entropy label? A: the hashing would take into account entropy label. Paul Amened (?): why the focus on large flows? A: for author, the large flows use the most resources. -------------- Netconf: a potential I2RS protocol (J. Medved, 15') Opendaylight update: Opendaylight is an opensource SDN-controller that hopes to be able to use protocols and information models produced by i2rs Opendaylight uses netconf and Yang heavily. Netconf and yang are doing most of what is required by i2rs arch and requirements, but there are some asks. Controller NB API: Application requirements: Netconf asks: Restconf: helps for automatically rendering APIs Efficient binary encoding. JSON encoding (popular with programmers) Rich query language for selecting info they want. Yang asks: YANG ODL Extensions have been proposed to make auto-generated code more human-readable Jamal Q: are you trying to get i2rs to standardize language bindings? A: no. Q: clarification on JSON and binary encoding requirements being separate. A: yes, they are separate. Binary encoding is for XML. ---------- draft-zhang-i2rs-mbb-usecases-00, draft-zhang-i2rs-mbb-usecases-00 (Z. Li, 15') Suggestion from Alia to separate out parts of controller functionality that would be appropriate for i2rs work.