OPSAWG IETF88 Minutes Minutes by Tom Taylor (tom.taylor.stds@gmail.com) Start time T=00:41:45 on the archived audio. The OPSAWG Working Group met between 9:00 to 11:30 am on Tuesday, November 6, following the Operations and Management Area meeting. All three co-chairs (Scott Bradner, Melinda Shore, and Warren Kumari) were present. Introduction ============ Slides at http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-10.pdf: 1. Note Well 2. opsawg/opsarea agenda 3. opsarea/opsawg agenda (2) 4. opsarea/opsawg agenda (3) Melinda Shore presented the agenda and WG status. She introduced the new OPSAWG co-Chair, Warren. Agenda bashing: virtual interim to be discussed at end. CAPWAP drafts are doing well, getting fairly aggressive reviews. Some small changes to RFC5066bis as a result of IESG review. The editor, Edward Beili , reported that he had submitted an update and was still committed to creating a companion document that had been agreed on the list, when he had time. CGN deployment draft went to the IESG and came back with a few comments. Editor Victor Kuarsingh reported, slides at http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-0.pptx. Parts of Section 3 need to be updated to take account of the creation of RFC 6888 as the base statement of CGN requirements since this document was first written. Victor plans to submit an update in the next week or two. Since the changes are basically editorial, no additional WG Last Call will be needed. Load balancing of large flows now in AD review. OAM overview: heavy criticism during IESG review, major rewrite done. Checking that reviewers are satisfied with resolution of their comments. Once that is done, will go through WGLC again. T=00:50:00 VMM MIB ======= draft-asai-vmm-mib-05 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-9.pdf: 2. [Architectural diagram] 3. Summary of changes from -04 4. Summary of changes (cont'd) 5. History of this draft 6. [Moving forward] Hirochika Asai presented a summary of discussion and changes leading to the latest version. Joe Clarke raised a clarifying question from Jabber regarding item "Joe-2" on slide 3: is there a need for any extension or modification of format for the addresses stored in the MIB, or is the Entity MIB now sufficient? After a bit of discussion Joe Clarke affirmed that the description is in the spirit of what he was asking for. Dan Romascanu pointed out that the example using the Bridge MIB should probably use the IEEE version rather than the cited RFCs because that MIB is now controlled by the IEEE. He will help the authors to make this change. *Action*: Dan and authors to rework example as indicated. Ning Zong (Huawei) asked a clarifying question about notifications generated when a virtual machine migrates from one hypervisor to another. The presenter responded that there was no intention to model hypervisor collaboration, just the point of view of a single hypervisor. Ning's point was not this, but rather, what would be the target of the notification, the agent for the initial hypervisor or the agent for the receiving hypervisor. The answer was that it would be the agent for the initial hypervisor. [inaudible] asked a question about modelling of virtual switches. The presenter described how they would be represented, using the VMM and other MIBs. The flavour of the question was whether the VMM MIB repesentation met all the requirements for representing the virtual switch, and the presenter's response was that, because the virtual switch (or router) could be located independently of the hypervisor, it was best to represent it by other MIBs. The question was not fully resolved, but the Chairs asked that it be taken off-line in the interests of time. The presenter asked for a statement of what needed to be modelled and was not currently available. *Action*: questioner to provide the information requested. The Chairs reinforced the call for review and indication of support or non-support for adoption as a Working Group document. They noted that the authors list is longer than the RFC Editor will normally allow, so one or more authors have to be removed from the front page. RFC Editor policy on this matter is stated at http://www.rfc-editor.org/policy.html#policy.authlist. The IESG enforces this policy. *Actions*: Working Group, authors. T=1:06:00 CAPWAP Extension for 802.11n and Power/channel Reconfiguration ============================================================== draft-ietf-opsawg-capwap-extension-01 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-3.pdf 2. Background 3. Progress 4. Next step 5. Request for comments Dapeng Liu was the presenter. Received comments from IEEE experts and updated the draft based on their comments. Received mainly editorial comments from the list. Dorothy Stanley , IEEE liaison, corrected the presenter: there was no general IEEE 802.11 review. Her personal opinion was that the draft should be brought into better editorial shape before it goes either to WGLC or to IEEE review. This is a matter both of the text and the organization of content. Dorothy finds the document difficult to understand in its present state, although improved over its original version. Dan Romascanu agreed, and noted that he had already made comments on the list. Given that there is an IEEE 802.11 interim meeting scheduled for the next week, would it be possible to nominate a couple of reviewers at that time? Dorothy said that was possible, or she could issue an open call for review. The Chair asked for volunteers to help review the document editorially. Tom Taylor volunteered. *Action*: Tom Taylor to provide marked-up draft to authors. [Completed and sent to Dapeng Thursday evening Ottawa time.] Dan suggested the WGLC period could be made longer than usual to make sure IEEE 802.11 had time to complete their review. Dorothy indicated she would have additional comments of her own. T=01:13:15 IEEE 802.11 MAC Profile for CAPWAP ================================== draft-ietf-opsawg-capwap-hybridmac-01 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-1.pdf 2. Problem Statement 3. Proposal 4. Discussion Rajesh Pyazhannur was the presenter. Dan Harkins asked how this related to the hybrid profile as the only remaining one if local and split are removed from the draft. Rajesh responded that they expect to rename that profile, and in fact intend to have two profiles, one for the AC to perform the functions, the other for the WTP to do so. Dan noted that one company's products operating in split mode do fragmentation/defragmentation and encryption/decryption on the WTP, many companies do it on the AC, and the hybrid profile in the current draft is the only one that splits the two functions between the WTP and AC. Rajesh said the intended interpretation was that one does fragmentation, the other defragmentation, without being specific about which end was which. It turned out the restriction to AC was a typo. *Action*: authors to correct typo. Dorothy Stanley said the draft was much improved and in her opinion ready for WGLC once the profile updates were done. Dan Harkins asked, given that the hybrid profile has the functions performed at the WTP, what would be the name of the profile where the functions were performed at the AC. The answer was that this relates back to the previously stated intention to define two profiles. Dorothy Stanley confirmed that the term "hybrid" is being dropped and these will be profiles of split MAC, used to disambiguate RFC 5416. T=01:23:20 Alternate Tunnel Encapsulation for Data Frames in CAPWAP ======================================================== draft-zhang-opsawg-capwap-cds-01 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-2.pdf 2. Problem Statement 3. Proposal 4. Discussion Rajesh Pyazhannur also presented this draft. [Note that the initial part of the presentation is almost indecipherable in the audio archive due to speaker overloading.] Zhen Cao , speaking on behalf of an operator, emphasized the draft's importance to them and urged its adoption. Dan Harkins stated that the problem had been solved in other ways, and did not need a new solution. He recommended that the work be abandoned. Dapeng Liu argued in support of the draft. Zhen Cao pointed out that the tunnel was already there in CAPWAP. This draft defines alternative encapsulations. John Kaippallimalil noted that he expressed his support for the draft and provided comments on the mailing list. He thinks the problem is important, and looks forward to seeing the text on AR discovery. [Inaudible: discussion amongst the Chairs?] T=01:32:40 Management of Networks with Constrained Devices: Problem Statement and Use Cases ================================================================================ draft-ersue-opsawg-coman-probstate-reqs-00 draft-ersue-opsawg-coman-use-cases-00 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf 2. COnstrained MANanagement 3. draft-ersue-opsawg-coman-probstate-reqs 4. draft-ersue-opsawg-coman-probstate-reqs (ctd.) 5. draft-ersue-opsawg-coman-use-cases 6. draft-ersue-opsawg-coman-use-cases (ctd.) 7. Related work 8. The way forward 9. [Contributors] Mehmet Ersue presented. The Chair asked how many people had read the documents. [Apparently not many.] The presenter noted that although there was little comment in OPSAWG, members of the COMAN mailing list had been quite active in their discussions. [Ulrich Herberg? ] asked what the relationship the draft had with the COAP protocol draft currently in the RFC Editor's queue. The presenter indicated that there is little relationship with the protocol itself, but Carsten Bormann and others involved in that work were very interested in the COMAN drafts as guidelines for management. As a contributor, the questioner supported this work, but has not read the latest version. The presenter indicated that the updates in the latest version were in response to comments from the COMAN list. Juergen Schoenwaelder indicated that one of his Ph.D. students had read the draft a couple of weeks ago. So they just have to review the changes to the latest version. The Chairs indicated willingness to take the next step, which according to the guidelines under which the WG now operates, call for a sufficient number of reviews before new work is formally undertaken. A call for volunteers drew one or two responses. More will be sought on the list. *Action*: Chairs to call for reviewers on the list. T=01:43:35 Chair introduced the next segment, concerning work being done at ETSI and the IETF. ETSI Network Function Virtualization (NFV) Management and Orchestration - An Overview ===================================================================================== Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-6.pdf 2. Virtualization as a Paradigm 3. Network Function Virtualization Components 4. Example of an E2E Network Service with VNFs and nested VNF Forwarding Graphs 5. Management and Orchestration (MANO) Functional Blocks 6. NFV Management and Orchestration Architecture 7. NFV Entities to deploy and manage 8. Overview of MANO Descriptor Files 9. Overview of MANO Descriptor Files (ongoing work) 10. Overview of MANO Descriptor Files (ongoing work) (ctd.) 11. VNF DESCRIPTOR MODEL (ongoing work) 12. Current Development in NFV MANO WG 13. Timeline for ETSI NFV Work Programme 14. References Mehmet Ersue presented. Slide 9: There was a quick question what the difference is between the VNFC and VDU. The answer is that the difference is only on the semantic level. The VNFC is the architectural component, while the VDU is the construct information model. T=01:58:18 Service Function Chaining (SFC) BoF =================================== draft-quinn-sfc-problem-statement-01 and others Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-13.pdf 1. SFC Background 2. Service Function Chaining (SFC) 3. Service Function Chaining (cont.) Thomas Narten presented. Service providers want to change deployment time scale from weeks down to minutes. [Mehmet Ersue?] What exactly is the protocol they plan to use for management? Thomas: not really clear yet -- have to have a better understanding of what they need to manage. Need to develop the high-level framework and requirements. Thomas's recommendation was that they start with that, then recharter in 6-9 months to go into detail. Benoit Claise , speaking as AD, noted his concern with how the Area shares its knowledge, and asked what SFC would need: management people to come to the BoF, charter review, a management adviser, the flow charts he proposed in his Area meeting presentation? Thomas responded that the flow charts would be generally useful and useful to SFC, the charter is really under control, and it is premature to seek a management adviser. He sees it as the job of the Chairs to reach out for help when they see the need. [Shankar?] Could he give an example of how a particular service, such as parental control, might work. The service operates by delivering some packets but not others. Thomas suggested that at some point in the data path a packet would be identified as subject to parental control and diverted to a different service chain. The identification could be made based on, for example, the subscriber. T=02:06:40 The Problems of Virtual Network Function Configuration ===================================================== draft-song-opsawg-virtual-network-function-config-00 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-8.pdf 2. NFV Basics 3. [segment title] 4. History 5. Lack of Remote Provisioning 6. Lack of Remote Dynamic Configuration 7. Standardization Space 8. [] 9. Next Step Haibin Song presented. As introduction, he reported on the NFC configuration and modelling meeting held Monday evening. Sixteen people met for two hours. Determined that they did not want to cover the full spectrum of management for NFV, but would focus on aspects of configuration and information models. Some [??] as liaison for ETSI in the IETF. Thomas Narten indicated that he saw work there that had to be done somewhere, but he was not sure where, yet. Melinda Shore as Chair said that discussion was what they hoped to get started with the presentation today. Thomas repeated that it was completely unclear in his mind how the work should be split up. Benoit Claise interjected that we certainly want to avoid overlapping work. Mehmet Ersue could see Ops area working on configuration and fault management, but the details need sorting out. Warren Kumari asked Thomas where all the work on architecture and requirements is being done. Will some of that be coming to the IETF? He noted that the architecture work seems detailed enough that it is in effect standardization, despite Mehmet's opening statement that ETSI MANO was not doing that. Mehmet responded that work is being done in a lot of other organizations besides ETSI, and the IETF needs to decide for itself what is important. Haibin asked if the gap analysis done by ETSI would be useful to the IETF. Thomas replied that the gap analysis was done by NFV, and it is provoking work in a bunch of other organizations. Naturally an identified gap relating to the IETF should be done here. Mehmet: the IETF has to decide for itself, and cannot give excessive weight to a gap analysis done by another organization. T=02:17:50 Virtual Network Function Configuration Architecture =================================================== draft-zhou-opsawg-vnf-config-arch-00 Slides at http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-7.pdf 2. NFV Configuration 3. Principles 4. User-Controller Interface 5. Software Vendor-Controller Interface 6. Controller-VNF Interface 7. Controller-Infrastructure Interface 8. Security 9. Next Step 10. [] 11. POC Prototype (screen shot) 12. POC Prototype (screen shot) 13. POC Prototype (screen shot) Haibin Song presented. On Slide 2, Mehmet Ersue questioned the controller, since it is different from ETSI. Haibin suggested there is a gap between ETSI work and real-life deployment. Mehmet's concern was the placement of both the OSS and the VNF in the same box. Haibin responded that they could be in different boxes. Dan Romascanu suggested the work presented in the last few drafts, dealing with a new technology, is premature until some operational experience is gained. T=02:26:20