------------------------------------------------------------------------------- Network Virtualization Overlays (NVO3) Working Group IETF 85 - Meeting Minutes Location: Salon D, Hilton Atlanta, Atlanta, GA, US Time: 08-Nov-2012, 0900-1130 Agenda: https://datatracker.ietf.org/meeting/85/agenda/nvo3/ Chairs: Benson Schliesser (bensons@queuefull.net) & Matthew Bocci (matthew.bocci@alcatel-lucent.com) Note-taker: Giles Heron ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Opening Intro - Chairs ------------------------------------------------------------------------------- http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-0.ppt Prioritised discussions based on December milestones. Some drafts not being presented today as they have early 2013 milestones - so still need to make progress. 2 WG drafts (framework and problem statement) - goal is to get them to WG last call. Reminder - we have 4 december milestones. Fairly sure will miss some. Problem statement and framework may go through in time. Want audience to give specific feedback on whether those 2 are in good shape. Interim in late Sept. Good turnout - 50 people? All-day. Minutes online. ------------------------------------------------------------------------------- Problem Statement - Thomas Narten ------------------------------------------------------------------------------- draft-ietf-nvo3-overlay-problem-statement http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-1.pdf Revised post interim. Harder and harder not to use same terminology as framework. Trying not to say "VLANs have limitations" etc. That's not why doing overlays - other benefits to IP layer. Paragraph on forwarding table size. Changed it not to talk about l2 but about l3 (flat routing with /32 etc.) Introductory paragraph making it clear this is overlay over L3. Various other changes/cleanups. Believe addressed all outstanding comments. One email since did slides but still think essentially done. No new comments since posted -01. So goal is to WG Last Call to flush out any remaining issues. Lou Berger - do you think security considerations are adequate? Says "we're not going to deal with it". Had expected it to talk about partitioning of VNs, separation of traffic etc. Thomas Morin - is this more for framework? Problem statement is high level. Lou Berger - high level statement of problem statement (e.g. don't mix traffic between different VNs is good). I should send text. Benson (as chair) - our intent is to Last Call. Possibly as early as next week. ------------------------------------------------------------------------------- Framework - Marc Lasserre ------------------------------------------------------------------------------- draft-ietf-nvo3-framework http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-2.ppt Quick update on changes in -01. Basically addressed most comments raised during interim meeting. Clarified terminology - some words were contentious. Tenant End System is now Tenant System for example. Please review these definitions and comment. Discussed impact of NVE (co-located with tenant system or remote - impacts on CP as much easier to communicate VM state via API if local whereas if remote need some DP, CP or MP mechanism). 2 new sections on distributed vs centralised CP and multihoming (e.g. what does multihoming mean). Clarification on MAC learning via DP or via CP distribution. Added security text - addresses Lou's questions on Problem Statement. No specific issues as no new protocol. But discussed tenant isolation via separate FIB tables etc. Examples of where NVE sits and distributed vs centralised CP. In centralised case have controller/"oracle". Routing protocol runs at controller and then agent on NVEs talks to controller. Gateway still typically runs routing protocol locally. Can have hybrid distributed/centralised of course. Kireeti Kompella - the distributed picture confuses gateway function and controller function. Choices are single controller with agents or multiple controllers with multiple NVEs. Marc - agreed, this picture isn't in the draft. Discussion of multi-domain controllers. So multiple DC underlays. Need for the controllers to talk to each other. Next step is to get feedback on new sections in -01 (not much feedback) and to add section on NVE gateway. Benson - intent is to last call this one real soon now too. So please send substantive comments ASAP. Lucy Yong - confused about tenant system vs end device. can you explain? Marc - what's not clear. these are definitions that we all agreed amongst several people so let us know if it's misleading. Lucy - will take that offline. Another issue is tenant service interface. shown in diagram but not described in text. Marc - are you talking about the Virtual Access Point? Lucy - yes between tenant and NVE. Marc - we stay very high level in framework. data-plane draft describes VAP in more detail. Lucy - can't have in diagram if no text to explain. Puneet Agarwal - comments on push vs pull before. Have you given up on pull model now. Marc - I don't see where we highlight one model vs the other? Puneet - I don't see a directory service in there. if you have a pull you need on. Marc - we could clarify what the controller does, whether is push or pull. but we can clarify. Thomas Narten - my question is does it say anything about push vs pull? But for framework might want to say can do one, the other or both. Benson (as chair) - the framework should be neutral. Thomas - neutral is right but lay out possibilities too. Silence doesn't help us. Marc - this was new text waiting for feedback and we can clarify it. ------------------------------------------------------------------------------- Data Plane Requirements - Nabil Bitar ------------------------------------------------------------------------------- draft-bl-nvo3-dataplane-requirements http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-3.ppt Changes in -02: Aligned terminology with framework (TES -> Tenant System). Diagram on encapsulation stack. Clarified outer underlay header and NVO3 overlay header. outer underlay is IP or MPLS. NVO3 overlay has VNI context and potentially optional fields. Next steps: Got comments from Larry and Marc already responded and need changes in draft. Need changes to make entropy requirements more generic. Update on multicast and dual-homing. Want WG to send further comments. Would like to get WG adoption by Orlando IETF. Thomas Narten - I'd like to be more aggressive than Orlando. Nabil - yes, not waiting to Orlando. Marc Lasserre - Nabil and I will post new version in next few days (addressing Larry's comments and making those other adjustments). so goal will be to progress that to WG adoption. Matthew - want to adopt in next few weeks and target WG last call around Orlando. Lucy Yong - I think you mention hierarchical NVE. needs a clearer description for the future. Nabil - if you have precise comments on that then we'll take them in and try to address them (updating if required). Please do it soon given the time window. Lucy - I don't feel there's a concrete indication in the draft. Nabil - we had no comments before. So if you can articulate comments that will help us address Benson - call for adoption is different from last call. So for the problem statement and framework it's your last chance to comment. On this one we have more time - adoption is just making sure on right track. Lucy - problem statement says underlay is IP. This says can be MPLS. Nabil - we do say IP is mandatory but MPLS is an option. If there are comments we need to clarify. Lucy - VPN label is different from LSP tunnel. Nabil - yes, MPLS is an optional tunnel. Marc - to clarify on hierarchical NVE. The requirements say that solution should allow hierarchical NVE but it isn't a must. Himanshu Shah - when VM moves and you extend reachability you need attachment circuit to move? Nabil - this is not the right draft for this. there's a Kireeti/Thomas Morin draft related to the protocol from hypervisor to NVE. that's where this ought to live. David Black - wanted to expand on what Nabil said. Kireeti's draft now has 4 authors. Also another draft on the same space. will get to those later in the agenda. Will provide opportunity to explore that issue in great depth. ------------------------------------------------------------------------------- Discussion of Operational Requirements - Chairs ------------------------------------------------------------------------------- draft-ashwood-nvo3-operational-requirement http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-4.ppt Individual draft (ashwood-nvo3-operational-requirement) that provides high level view of OAM framework. Needs to be more specific and needs more operator feedback. Chairs intend to find some "volunteer" operators to help. Will issue WG adoption call soon (might be before next rev). Would like substantive feedback soon. Apparently new authors already identified. Matthew - sense of room - about a dozen people have read this. Benson - do any of you feel draft is on the wrong track? no hands… Anoop Ghanwani - I feel the draft is too high level. Doesn't go into detail of what failures need to be protected against etc. Benson - I encourage you to send text to authors or mailing list David Black - I agree with Anoop in general, but I think this is a good starting point. Benson - to misquote John Hudson from interim meeting. OAM "is the solution" from an operator's point of view as that's what they interact with. This is more important than we tend to give it credit for. ------------------------------------------------------------------------------- Discussion of Control Plane Requirements - Larry Kreeger ------------------------------------------------------------------------------- draft-kreeger-nvo3-overlay-cp draft-kreeger-nvo3-hypervisor-nve-cp http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-5.ppt Taken out text on hypervisor to NVE (separate draft). Want to adopt this cut-down draft as a WG doc. Benson - again this is a December milestone but not adopted yet so we'll call for adoption in the near future. May wait to adopt the first couple of drafts before that. Comments would be appreciated. ------------------------------------------------------------------------------- Network-related VM Mobility Issues - Linda Dunbar ------------------------------------------------------------------------------- draft-rekhter-nvo3-vm-mobility-issues http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-6.pptx Combined draft (raggarwa and dunbar) now called rekhter. Requested WG adoption. Chairs asked Qs and we have responded and explained why it needs to be a standalone. Benson - I should give some background here. We have a set of presentations starting with this one that don't map directly to milestones but do align to them. So we may want to have docs that are companions to e.g. problem statement/framework etc. Will only allow one per topic, and only if it adds value. You may see other drafts later that you think are similar. That's the point. Linda is responding to questions we sent and we're trying to get a sense of what the right next step is. Authors want to get WG adoption. David Black - specifically why is it important to publish this one as an RFC. This is useful. there's a long IETF tradition of writing drafts to raise issues and ensure that they get discussed. but what's the value of this becoming an RFC? Linda - we want to identify the problems/issues as this WG is chartered to describe problems. This draft emphasises details of mobility issues. Some of them aren't that obvious and do need documenting in a WG doc. David - so then I wonder if this ought to just be in the problem statement. Do we want to spread that across 5 drafts? How much needs own draft vs needs to be incorporated into problem statement. Eric Gray - I support having a draft that becomes an informational RFC on mobility. I'd also agree with chairs and Linda that this doesn't belong in problem statement as while it's a difficult problem it's not the most important or overwhelming. If we put this in the problem statement draft it may look more important than it is. It's not the most important but is hard to explain. Thomas Narten - this doc is very L2-focussed. Problem Statement we got pushback on being too L2 focussed. This is good background but not sure it's a motivator for what we're doing other than that we want to decouple physical/logical. Don't want to pull this L2-focussed stuff into problem statement. Lucy Yong - I agree with Eric. VM mobility is complicated and needs its own document rather than merging into the problem statement. Detailed problems would make the problem statement too big. Second point - I hope this doc addresses situation where NVE is co-located. In that case you're completely free of L2 issues. So this needs to be stated. Linda - to address Thomas's comment that's one reason we want to have this draft. L3 is underlay network. As Lucy says, in a pure environment where all the NVEs are on the server then there's no L2. but in most data-centres as you migrate from today's network to the future you'll have L2 between server and NVE as not all servers will have virtual switch to do encapsulation. Puneet Aggarwal - I don't see why this is in its own draft. Can fold into problem statement and architecture/framework. Linda - I think we're going in circles. Eric Gray - We need a draft on VM mobility to go to RFC. But not saying necessarily that this is the draft. There is nothing specific about L2 technologies. Need to go into VM mobility in detail. People will point out that we're ignoring issues with other technologies. So need to steer clear of layers/technologies. Win Henderickx - (co-author) - we did this draft as mobility is a rather big topic and could make problem statement unreadable. The question of L2 vs L3 is something we're happy to get feedback on and incorporate in the doc. But L2 has very specific requirements which is why we put that here for now. Lucy - following Eric's comment. I do think this draft is right place to do this. But issue is that document defines its own terms. Can we use the framework terms? ------------------------------------------------------------------------------- Requirements for Mobility and Interconnection of Virtual Machine and Virtual Network Elements - Bhumip Khasnabish ------------------------------------------------------------------------------- draft-khasnabish-vmmi-problems http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-7.pptx Skipped first few slides. Presenting answers to the chairs' questions about relationships to other drafts. Answer is "Yes". Lots of stuff that can be merged into other drafts. This draft started before NVO3 was formed. Focus was VM mobility/interconnection only. Looked at L2, L3, hybrid environments. Once we update this draft we can work with problem statements/requirements authors to see what needs to go in there. Also could combine content here with the other VM mobility draft. Matthew - issue is we want to LC the problem-statement and framework soon. Bhumip - not too significant so can do that as comments on the problem statement and framework. Thomas Narten - what we really need is you do send text. Benson - need that in next couple of days. Next version will be published ASAP. So want to merge and then to develop a new draft if there's stuff that can't be merged into other drafts. Benson - we know this is similar to the draft Linda presented. Lots of overlap. So first steps are to see if need any content to go into problem statement and framework. After that we as a WG (and as 2 sets of authors) need to decide whether to merge the two VM mobility drafts, to pick one or the other, or drop them both. Would be great to get WG feedback on that. Linda - I have provided extended comments. Bhumip - we are updating based on those. Linda - lots of stuff here that's out of scope of NVO3. And would appreciate you providing concrete text to our draft. Bhumip - some text is out of scope of existing drafts so will create a new one. Pat Thaler - sent comments but also feel the draft is a very difficult read. Some sections not written with good grammar. Got as far as i could. Bhumip - yes, problem is draft written in parallel by multiple authors. Will fix it. ------------------------------------------------------------------------------- Signaling VM Activity to the NVE - Kireeti Kompella ------------------------------------------------------------------------------- draft-kompella-nvo3-server2nve http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-8.pptx this is server to NVE signalling. Draft intended to simplify the exchange of info between a server and an NVE to make provisioning easier. Goal is to provision server with all attributes you need (networking, storage etc.) and then have it signal the NVE with the network-related parts (e.g. IP address, virtual network) so that the orchestration system can provision the NVE. So we figured out how orchestration works in a data centre. Tried to describe in an abstract way but with enough detail to make networking parts clear. Need to show what's important for data centre networking. Wasn't intended to be prescriptive - though some people took it that way. But it's good to explain how VM creation/deletion etc. happen. Described VM provisioning and the corresponding network provisioning and signalling that has to happen. Looked at different signalling choices for the future (e.g. VDP, XMPP, TCP socket). And looked at different options for network virtualisation (VLAN, E-VPN, IP-VPN, something else). Final thing is looking at NVE to NVE control plane and how this integrates. Tried to make it clear that descriptive text is just descriptive (not prescriptive). Goal is to capture enough to understand what network side needs. Also details on hot vs cold VM migration. And made it clear that NVE can be remote or local to server. Also expanded details on VM creation, migration, termination. When do you send addresses and create virtual network etc. Section on how NVEs talk to other NVEs has been moved to a companion draft. Say now that server2nve signalling must co-ordinate with nve2nve signalling. Lots of work still to do - we've all been busy lately! More focus needed on co-located NVE. Need algorithm to ensure server/NVE in agreement on VN/VID mapping. More details on signalling required for hot migration - and documentation of what traffic loss you might expect for a given protocol etc. Also we need to choose some protocols and figure out format for signalling in those protocols. Eric Gray - I believe that if we have specifications that say NVE must appear to be a separate entity to any external object then we don't need to worry about co-resident NVE as mechanisms are irrelevant. Kireeti - what we came to is that it's important to capture what information goes to server vs NVE module. Information the same for co-resident or remote, but might pick a different protocol. Eric - maybe best to capture behaviours you need so that it looks to an external entity as if NVE and VM are separate. Florin Balus - this is a solutions draft rather than requirements. Also the name isn't good. Needs to be more generic than server2nve. Could be network appliance. So generalise states to not being just VM states. Mobility etc is specific to VM but other stuff is general. Maria Napierala - there are pros/cons of inband vs out of band signalling. Kireeti - we want to write down what information needs to be carried. Then write down protocols and encode that information in those protocols. Maria - also security implications need to be covered. Thomas Narten - the document Larry talked about earlier on server to NVE has been renamed hypervisor to NVE. Server isn't really the right term. We need to figure out what term is right. Kireeti - Hypervisor also not right as may have non-virtualised cases. Thomas - but with a bare metal machine you may not need this. Can statically configure first hop as server won't move. Lucy - missed first comment :( Second comment - you describe VM creation/migration/termination. But also have power off/power on. That will impact NVE and needs addressing. Marc - these terms have already been defined (in framework). First few slides said goal was to describe how to provision. This is more than provisioning. Is also status management in-life. Kireeti - sure there's a a mumble in the draft on OAM etc. We're assuming the protocol is stateful. So we need to know what the NVE does if the protocol goes down. We could provision on both sides and not use this. This is to simplify things. Larry Krieger - terminology discussion (Tenant System etc.) Kireeti - will take that off-line. Chairs have asked Qs re relationships with other drafts. May need to add requirements to Larry's hypervisor-nve-cp draft, and maybe a paragraph or two in framework. Will send Marc some text (may even be none if required text there already). Bigger overlap with gu-nvo3-tes-nve-mechanism. Gu draft has description of VDP but everything else is in this draft. Yingjie Gu (author of gu draft) - not surprised by overlap. Scope is limited. Common basic understanding of operations between 2 systems. Difference is Kireeti's draft focus is on general steps. Gu draft pays more attention to VM lifetime events. Different events will have different status/activities. Other difference is that draft-gu has detail on signalling considerations including in what circumstances events can happen. Also draft-gu provides basic requirements for tenant to NVE CP. Kireeti - that's what confused me with draft-gu. Has requirements, architecture, solution. Our draft is solution-focussed. David Black - definitely overlap here. Both drafts look at VM lifetime events. We need to figure out whether to just do this once. ------------------------------------------------------------------------------- Mechanism and signalling between TES and NVE - Yingjie Gu ------------------------------------------------------------------------------- draft-gu-nvo3-tes-nve-mechanism http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-9.pdf Draft does requirements for this but also signalling considerations. Brief overview of draft. Updated since last meeting. VM lifetime events. So that people have common understanding of events. Draft adds suspend/resume events. Similar to physical PC being in sleep mode or waking up. suspension is not termination as want restart to be much quicker than creating a new VM. Traffic stops but VM state/policies can be retained at NVE. Also made it clear that not all VM has to go through all events - creation/termination is minimum. And NVE doesn't need to be aware of all events. Showing full lifetime sketch. Draft has dedicated section on TES to NVE interactions. Lifetime agents but also have interactions that aren't related to changes in state - e.g. keep-alive or local NVE changes. Also explained circumstances under which events occur and parameters that need to be carried when that happens. This is overlap with Kireeti's draft. Clarified that not every interaction needs a dedicated message. For example you can suspend in an associate message. Showing view of TES to NVE signalling state machine. Answering the chairs' questions: 1) nothing for problem statement or framework as this is focussed on TES to NVE. 2) possible material here for CP requirements. CP split into 2 parts now - so this is dedicated to TES/NVE signalling. 3) there are other drafts related to this (e.g. Kireeti's). Each draft has its own focus. Benson - we'd appreciate comments. Jon Hudson - makes sense to break this out a bit for now. This WG is focussed on stuff that's a bit out of scope for many of us. Good to get familiar with problems we need to solve. Secondly in terms of merging/organising. We have 2 issues. (1) VM Mobility. (2) VM lifecycle. Some customers only care about one or the other. So separating mobility from care/feeding might make sense. Thomas Narten - agreeing with Jon. I see these 2 documents (Kireeti's and Yingie's) as having useful material. Good to have material on VDP but not necessarily related to requirements. But also do need a clear set of requirements - so probably a separate document. Again I think Kireeti's doc has useful material. Explains why we need this and how it all fits together. So I see 3 conceptually separate pieces. Kireeti - to Thomas's point we had 3 docs in one. Background material, signalling, NVE to NVE CP. We pulled one out. Finally decided to keep together to avoid the back and forth. NVO3 is a new space. People coming in need to understand the problem we're trying to solve and then we can look at solutions. So we can look at NVE to server signalling. Do we write problem statement and requirements for that then use-cases/analysis. And then do the same for NVE to NVE and then for data plane. Do we need dedicated requirements for each solution? At a high level a problem statement, framework and use-cases are important to ensure we're aligned. But do we need those for each small part of the problem. There are requirements in my doc. Thomas - I agree that we need those components, but not necessarily in separate docs. Need to figure out what's in the final RFCs that implementers read. Not good if implementer needs to read 5 docs. Makes sense to keep server to NVE part and NVE to oracle/controller part separate. Different issues. George Swallow - need a small statement in draft as to what part of problem you're solving. If requirements draft is good enough don't need to repeat. Kireeti - the problem statement isn't 6000 pages so doesn't have detail. So almost becomes a recursive problem statement. Each solution draft can have a mini problem statement - unless it's big enough to pull it out as a separate draft. George - I think we're in violent agreement. Benson - good discussion but we'll follow up on mailing list. Manuel Paul - want to know if gu authors have spoken to hypervisor vendors? Benson - good Q but let's take up on list so we stay on track. ------------------------------------------------------------------------------- Path Optimization for LAN Extension - Xiaohu Xu ------------------------------------------------------------------------------- draft-xu-nvo3-lan-extension-path-optimization http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-10.pptx showing general data-centre architecture using VPLS across data-centres. discussing issues: 1) Suboptimal routing for incoming traffic. Problem is a subnet runs across multiple locations. So traffic may follow sub-optimal paths. Side effect of this is unnecessary use of inter-DC bandwidth and also increased latency. 2) Suboptimal routing for outgoing traffic. If a VM moves from one DC to another want to use the same default gateway IP/MAC. So usually configure default GW at both DCs with the same IP/MAC But it's an issue with VPLS - you may end up using the remote default GW. solutions: 1) default GW acting as L3VPN PE can create /32s for local servers and advertise to remote PEs. 2) can anycast outgoing traffic to nearest default GW. So need multiple routes for a given MAC address. Believe that path optimisation will be an important factor which drives operators to select L2 vs L3 overlays and to choose between DP and CP MAC learning. So it's helpful to do this. Can WG discuss whether this should be incorporated into Problem Statement/Framework drafts or adopted as a separate draft. Wim - the current problem statement addresses this (as a section on optimal forwarding). Xiaohu - noticed that but I think we need more detailed discussion. Wim - if we agree to a special draft on mobility problem statement then this could be there. David Black - "Send Text". Also don't think this would be a good standalone draft. It's very narrow - assumes VPLS which is one of many solutions. So need to do it once, not 5 times. Also chairs want us to address overlaps. This topic is also in the draft Linda presented. So there's some useful stuff here but it is really really narrow. Xiaohu - I propose decoupling this from specific solution. VPLS is just an example to show the problems. Marc - this is also discussed in data plane requirements Xiaohu - also noticed that. But said previously the work there isn't enough. This is an important topic. Marc - we all agree it's important. There's already one page of text in Data Plane requirements. Also some control plane stuff here. But don't see benefit of splitting information in different docs. Luyann Fang - please send text to problem statement, framework & data-plane requirements. ------------------------------------------------------------------------------- Use Cases for DC Network Virtualization Overlays - Lucy Yong ------------------------------------------------------------------------------- draft-mity-nvo3-use-case http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-11.pptx Doesn't see this draft as overlapping with problem statement and framework. Better as a companion draft. 2 purposes - (1) make it easy to find the use cases. (2) avoiding those other docs getting too big. Also don't see this doc as overlapping with requirements. But does help identify requirements. And don't see overlap with other drafts. This is the only use case draft out there. Various changes since -03. e.g. description of VAP and NVE location for first use case. And new applications. Want more comments/suggestions and want WG adoption as a companion draft. Linda Dunbar - I think this is very helpful. Different angles to describe scenarios where NVO3 is applicable. Helps community to understand issues. Eric Gray - is this draft one of the set we were discussing earlier? Benson - no, my view is that this is the only use-case draft. Chairs generally think we need a use-case draft and that we need to call for adoption of this. Matthew - probably also need to add a milestone too. Benson - we'll update the charter for a milestone for this and call for adoption. Manuel Paul - good to have this. Uma Chunduri - I've gone through this draft and have found it very useful. ------------------------------------------------------------------------------- NVO3 Architecture - Chairs ------------------------------------------------------------------------------- http://www.ietf.org/proceedings/85/slides/slides-85-nvo3-12.ppt WG will struggle to agree on requirements unless we agree on architecture. Problem statement and framework are good but the framework (to its credit) doesn't attempt to narrow down decision points. Chairs have agreed to do a new draft on NVO3 architecture. Will evolve over time. Milestone will be to publish in the future but need to start work now. not to specify a solution but to narrow down into a skeleton of an architecture that we build solutions to. Creating a design team. Asking for people to communicate on mailing list. design team's job is to capture consensus. Will be a WG doc so won't be authors' opinion but WG opinion. Design team will be Matthew, Kireeti and David Black. To get things started will ask them to put a strawman out. So then we can review that. This will just be a starting point. Any comments on the approach? Also good to have comments on what architecture should look like. Linda Dunbar - we already have a framework doc. WG not chartered for solutions. So will architecture iterate framework or drive solution architecture. Benson - fair question. Framework has been neutral. Talks about functional components and how they relate rather than how we use them. Good to go ahead on that basis. Requirements milestones will require us to agree on what the architecture looks like. Starting this work to assist in creation of requirements. Expect multiple iterations as new requirements identified etc. Don't plan to Last Call this one until after the requirements. If we decide there are solutions out there we'll Last Call it and shut WG down. If we decide to do solutions in future we'll use this to guide them. Linda - I think we should wait until WG recharters to look at solutions. Puneet - is intent to define one architecture? Thomas Narten - I hope we pick one. Benson - our goal is one. If we need more than one this is a good opportunity to figure out why. Puneet - we have fundamental push/pull choice. David Black - some discussion on this. We know there won't be a single data-plane. But need architecture doc that says "put data plane here". Same with push vs pull control-plane. Need architecture to say what CP is and what it does. Push vs pull is then hopefully mostly in the structure of the component you plug into that slot. Tension between architecture and solutions. Hopeful one architecture can address diversity of DP and CP. Fabio Maino - what's relationship between architecture and gap analysis? Benson - don't know answer to that completely. Gap analysis compares solution to requirements. If no requirements can't do gap analysis. But can't say architecture is done until we've started to figure out what solutions look like in more detail and gap analysis is part of that. So expect architecture doc to be around/alive for a long time. Thomas - agree we need a separate architecture. Framework shows options. At some point you have to narrow it down and pick one. Not going to have open framework. architecture narrows choices. Architecture/requirements in tandem. Kireeti - want requirements first, then gap analysis. If have all you need can stop there. Might be useful to do architecture anyway. But may be more informational if no gap. But if we have gap and need solutions then architecture required to see how fits together. So on e.g. push vs pull that's a solution. Architecture says where it fits. So you will do all this in parallel. Gap analysis only depends on requirements. Puneet - on push vs pull I think it's fundamental to architecture. Depends how we define architecture. Architecture is functional components and how they interact. e.g. push vs pull may define if you have centralised database. So it's a core part of architecture. Eric Gray - combining these comments. Architecture draft often comes after requirements. Often easy to agree requirements. But in this group we have a plethora of possible requirements. So we need an architecture that is a focal point so we can focus on requirements we'll work on. But architecture is living document throughout process. Even if don't go to solutions architecture is useful to show we did analysis and found out what solves the problems. Linda - see pull/push as part of solution. Not in the charter of NVO3 as of now. Benson - in case it's not clear the architecture doc will stick around for a while. Don't want to let it slow requirements draft down. It's intended to help the process not add another serialised step. Work starts on this now. ------------------------------------------------------------------------------- END -------------------------------------------------------------------------------