Minutes of the opsawg session in Berlin - Chair Scott Bradner Session started at 13:15 Wednesday 31 July 2013 Notes taken by Nevil Brownlee & Tom Taylor Jabber scribe - Wes George http://www.ietf.org/jabber/logs/opsawg/2013-07-31.html Notes and jabber log combined by Scott Bradner to produce minutes Status - Chair: No new RFCs, Scott: The OAM overview document (draft-ietf-opsawg-oam-overview-09) had received a number of "colourful comments" since leaving the Working Group. Tal Mizrahi reported that IETF Last Call had attracted ten reviewers, and two Area Directors had also commented. The authors believe they have revised the document successfully to respond to those comments. Scott advised them to get an advance view specifically from the former Area Directors who had made those comments. Carlos Pignataro acknowledged that the authors had been thorough in their work, but suggested that the document had changed so much it should go through Working Group Last Call again. Scott: opsawg work needs recognition/support from Operators, let us know of you have that. (1) CGN Deployment with BGP/MPLS IP VPNs draft-ietf-opsawg-lsn-deployment Victor Kuarsingh presented. Victor noted that they had received feedback from other operators about potential enhancements in particular circumstances. This innformation does not appear in the document because it involves more technical detail than the authors thought appropriate. Scott asks "anyone want to see technology-specific information in document?" No response, leave it out. Scott How many people have read the ID? ~4, Scott: Is the ID ready for last call? A little support, no objection. (2) Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks draft-ietf-opsawg-large-flow-load-balancing Ram Krishna presented. The authors are asking for Working Group Last Call. They say they have had good operator feedback. Scott: how many have read the ID? ~2. Scott: Ready for WGLC? - silence. Scott "Let it dance on the list a bit more." (3) CAPWAP Extension for 802.11n and Power/channel Reconfiguration draft-ietf-opsawg-capwap-extension Dapeng Liu presented. WG draft since Orlando mtg. Two reviews/coments. Changes made. IANA Consierations needs more work. Lots of other changes. New revision. The authors are asking for Working Group Last Call. Drothy Stanley , IEEE 802.11 liaison to the IETF, said she would review it again after the proposed updates had been applied. Scott How many have read the ID - ~2 Dan Romascanu said he would review it, and suggested that IEEE 802.11 should also do so. Benoit asks about 802.11 dates. Dorothy noted that if the updated document is available by Sep. 1, it would be possible to obtain a review from the meeting scheduled for 15-20 Sep. in Nanjing. Scott WGLC after new revision (4) Separation of CAPWAP Control and Data Plane: Scenarios, Requirements and Solutions draft-zhang-opsawg-capwap-cds Rajesh Zhang presented. Split traffic into two streams, control | data. Scott: how many have read the ID? ~6. Dan Romascanu verified that the authors intended to change the core specification, RFC 5415. Given so, this might stretch the competency of OPSAWG. Scott wondered if he meant to form a new CAPWAP group. Maybe, if the necessary people were in favour. Dorothy Stanley commented that the document is not sufficiently mature. She supports the idea of an independent data channel, bu the solution seems more complex than necessary. She suggests LTPv3 and GRE tunnels. Agreed that updates to RFC 5415 or 5416 would be needed for end point signalling, but the present proposal involves more work. Hui Deng (?) said that China Mobile had five vendors supporting implementation. Lucy Yong (?) said she supports separation, but wants to see more scenarios represented. Satoru Matsushima stated that separation of control and data plane is a general principle being applied to protocols beyong CAPWAP. He sees no problem applying it here. The presenter agreed that the draft is not ready. They are looking at scenarios beyond China Mobile. Dan Romascanu noted that requirements evolve in time. CAPWAP went through the full process. We need to do this again. Joel Jaeggli remarked that it does look like other places are working in this area too. The work needs coordination. Rajesh Pazhyannur expressed his concern that there is some urgency to the work, but interest in the original CAPWAP died when it came to to find reviewers. He urged caution. Benoit: needs more formal requirements, and/or a new wg? Sri: Delay is bad, new wg sounds good. Dave Harrington: CAPWAP wg had trouble getting reviews, be careful about starting a new one. Scott: clearly some interest. (5) Hybrid-MAC for CAPWAP draft-ietf-opsawg-capwap-hybridmac Hui Deng presenting. WG draft since Orlando. Updated after review by Dorothy Stanley. No changes to current CAPWAP RFCs needed. Should this be Standards Track? Scott: How many have read the ID? lots. Scott: Opinions? Sri: yes, supports the draft Dan: draft not clear enough about how the extensions would work. Needs more work before considering Stds Trk Dorothy Stanley: Split MAC doc gives you choices, i.e. its a profile. Is data tunneling from WTP and AC the problem here? Could publish this as "hybrid profile" RFC, that wouldn't need a new type. There's a tradeoff here. Scott: A profile would not requiring a new type China mobile guy: negotiations needed, different operators may use different options. Scott: if you want to negotiate rather than configure then a type is helpful Scott: Take this discussion to the list! Benoit -If you are going from info to standards track - you'll need to remove "different vendors.." standards, this says "you must do this" the document needs to be written with std track in mind. (6) Management Information Base for Virtual Machines Controlled by a Hypervisor draft-asai-vmm-mib H. Asai presented. Asai: VM-MIB. Presented in Orlando. -04 on 2 July. Lots of improvements. Scott: How much support from hypervisor vendors? A: our implementation supports open source (kvm) and another author is from VMware Scott: How many people have read the ID? ~5 Joe Clarke: found nits, but substantially found confusing - you say you don't want to be a configuration MIB, but you list things as read/write, esp cpu objects; network section needs a lot more work, what resources a VM is consuming, notifications for VM state changes, especially to 'suspended.' things like VLAN are missing Asai: we tried to reduce the hypervisor-specific info our model is the more generic one David Black: likes draft, it has a state machine for VM state, wants it to be wg item. Sri: is RAM covered? A: yes JS: explains they're only modeled as writeable, you don't need to implement them that way. Scott: How many people have read the ID? ~3. Scott: Do a next rev covering network issues. Scott - revise once more and then revisit wg adoption (7) IP Packet Loss Rate Measurement Testing and Problem Statement, Peng Fan draft-fan-opsawg-packet-loss Peng Fan presented. Carlos: How many providers use ping to measure packet loss? Fancy tools would be too complex to deploy for cross-domain use. Scott: Benchmarking (bmwg) or measurement (ippm)? A: ippm doesn't address operational issues, opsawg does. Carlos - if you're measuring, do you need to consider other measurements Scott: icmp certainly not a forwawrd-looking way Benoit: Confused, what's draft trying to achieve? Scott: what is the benefit , who would use, for what purpose, very close to the concept of telephony oam - measuring inband characteristics David Miles: two situations here, I use ping because there's nothting else. Some ambiguity in the draft, but there is a problem in characterizing cross-domain packet loss. Rudiger Volk: How do you know you're looking at an inter-carrier link? Who does such a problem affect? Who takes care of it? I would like to know how bad the overflow looks on the other side, and I don't have insight there, ping can tell me the order of magnitude Fernando: I think this is fundamentally flawed to use icmp to find packet loss since it's designed as basic connectivity check you will be affected by queuing, punt rate, etc on router your icmp packets may be going to wrong queue, and measuring the wrong queue David Miles: draft actually says ping is _not_ suitable in the case of private interconnect, esp ethernet - hard to determine bit error rate without loading the link might not mean monitoringg post-commissioning, may mean prior to turn-up, can be done without coordination to other party better ways to do it probably Carlos: try to better understand what problem you're trying to solve, what is your expected outcome with this document? just find problem, find a solution? goals and scope are a good places to start Scott: problems seem real, area that is valid for WG to look at , but try to make the document clearer about problem you're trying to solve (8) Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management Protocols, Tom Taylor. draft-schoenw-opsawg-nm-dhc Scott showed Tom's slides Scott: how many people have read the ID? 0. Scott: Please read it and discuss on list. Session adjourned at 14:50