IETF
nvo3@jabber.ietf.org
Monday, March 11, 2013< ^ >
Benson Schliesser has set the subject to: NVO3 at IETF-85 Atlanta
Room Configuration
Room Occupants

GMT+0
[12:41:33] Jorge Rabadan joins the room
[12:42:06] Jorge Rabadan leaves the room
[13:11:45] dhruvdhody joins the room
[16:27:57] dhruvdhody leaves the room
[16:28:04] dhruvdhody joins the room
[16:30:33] dhruvdhody leaves the room
[16:32:02] dhruvdhody joins the room
[16:32:10] <dhruvdhody> test
[16:39:36] Matt Welch joins the room
[16:41:05] Matt Bocci joins the room
[16:43:50] farinacci joins the room
[17:03:29] Stewart Bryant joins the room
[17:04:41] Giles Heron joins the room
[17:04:51] <Giles Heron> ok - am jabber-scribing, but only just managed to join.
[17:05:19] <Giles Heron> Benson asking people to read reqs drafts.  need to focus on requirements/gap analysis.  showing NVO3 next steps slides.
[17:06:04] <Giles Heron> want single gap analysis draft.  want to point IESG at it when rechartered.
[17:06:25] <Giles Heron> looking for a good neutral editor for this.  please volunteer if interested.
[17:07:05] <Giles Heron> not chartered to do solutions, but for each solution which might solve what NVO3 is chartered to address then need a gap analysis draft that shows how it does/doesn't match NVO3 requirements.
[17:07:31] <Giles Heron> asking WG to document gap analysis of existing solutions - not to invent new solutions.
[17:08:13] Melinda joins the room
[17:08:41] <Giles Heron> we may end up talking about solutions that live in other WGs.  Want to be clear that Gap Analysis belongs in NVO3.  Feel free to describe solutions from other SDOs.  But for other WGs it's probably best just to point at the other WG.
[17:08:45] Daniel King joins the room
[17:08:47] <Giles Heron> chairs will help co-ordinate with other WGs.
[17:09:53] <Giles Heron> at last meeting agreed to create a design team to work on NVO3 architecture.  been asked by design team to apologise that not written it down yet.  chairs working with them to reformulate the design team.  David Black will update us next.  David's slides may irritate some of the WG - but that is the goal!
[17:10:30] <Giles Heron> please post opinions to the mailing list.
[17:11:21] <Giles Heron> we have lots of drafts but few milestones. don't intend to publish most of those drafts as WG docs.  We intend to have 1 (or a few) docs per milestone. if material in your draft needs to be captured in a milestone then talk to authors of existing WG doc for that milestone if we have one, or propose your doc for the milestone if it doesn't have a WG doc yet.
[17:11:42] <Giles Heron> showing picture re next steps that hopefully addresses all this.
[17:12:17] <Giles Heron> at some point will decide to recharter or shutdown.  may push requirements to other WGs, or do protocol work here, or decide there's nothing to be done.
[17:12:51] <Giles Heron> there may be more than one solution either here or in another WG.
[17:13:22] dhruvdhody leaves the room
[17:13:41] Wes George joins the room
[17:13:41] <Giles Heron> david black presenting architecture report.
[17:13:51] dhruvdhody joins the room
[17:14:11] <Giles Heron> goal is solutions.  protocols pass traffic.  reality is that we aren't chartered to do exactly one thijng.
[17:14:31] <Giles Heron> 2 interesting points:
[17:14:44] <Giles Heron> 1) is this fundamentally an L2 or L3 service?
[17:14:51] <Giles Heron> 2) is encaps MPLS or IP?
[17:15:09] <Giles Heron> MPLS/GRE is MPLS!  Ditto MPLS/UDP.  Or MPLS/foo.  Was the encap based on MPLS?
[17:15:27] <Giles Heron> usual 2x2 matrix as a result.  We have solutions for 3 of the cells
[17:15:36] <Giles Heron> 1) IP encap/L2 service is VXLAN/NVGRE
[17:15:43] <Giles Heron> 2) MPLS encap/L2 is L2VPN
[17:15:49] <Giles Heron> 3) MPLS encap/L3 is L3VPN
[17:15:58] <Giles Heron> 4) nothing yet for IP encap/L3 service.
[17:16:19] <Giles Heron> we want commonality within and across categories.  there's a reason we have one WG.  Not picking one category.
[17:16:48] <Giles Heron> framework draft is good.  but don't understand everything yet so not complete.   Need a doc that captures what we're going to learn.
[17:17:08] <Giles Heron> framework doc is quite abstract. need more detail.
[17:17:21] <Giles Heron> so this new doc is the architecture doc.
[17:17:41] <farinacci> when you talk about L3 service, can you please list LISP as a possible candidate, worried that people are not looking at all available solutions
[17:17:56] <Giles Heron> want me to ask that on mic later?
[17:18:05] <farinacci> sure, thanks Giles
[17:18:12] <Giles Heron> discussion now of possible content in this living doc.
[17:18:28] <farinacci> and if there are multicast issues, come to the LISP WG on Friday, I will be presenting options
[17:18:33] <Giles Heron> :)
[17:18:41] <Giles Heron> proposing next steps:
[17:18:44] <farinacci> for L2 and L3 multicast overlay solutions
[17:18:56] <Giles Heron> discussion on-list.
[17:19:14] <Giles Heron> discussion of "architectural" issues - e.g. if covers multiple of those boxes then more likely to be architectural
[17:19:41] <Giles Heron> need to decide what we will support.  might be we need multiple alternatives (e.g. L2 vs L3, on-board vs off-board NVE).
[17:19:54] <Giles Heron> important to capture what is possible to can set the scope.
[17:20:16] <Giles Heron> list likely to be v busy if we get this right.
[17:20:54] <Giles Heron> topics that may need attention:
[17:21:05] <Giles Heron> data plane - e.g. control plane vs data plane learning.
[17:21:23] <Giles Heron> control plane - e.g. push vs pull.  both have merits.  centralised v distributed v mixture.
[17:21:35] <Giles Heron> management plane needs addressing and ditto security.
[17:21:39] <Giles Heron> note these are all just examples.
[17:21:56] <Giles Heron> Lucy asking Q re slide 2.
[17:22:16] <Giles Heron> goal is "network virtualization solutions"  but not "network virtualization overlay solutions". is this a typo?
[17:22:20] <Giles Heron> David - yes all overlay here.
[17:22:33] <Giles Heron> Lucy now asking Q re slide 3.  there's a draft there for IP encap with L3 service.
[17:22:42] <Giles Heron> Benson - please bring that to the list.
[17:23:00] <Giles Heron> oh, Dino.  Looks like Benson wants things like the LISP Q asked on the list.
[17:23:25] <Giles Heron> but given the Friday thing I'll risk getting my head bitten off now :)
[17:24:07] <Giles Heron> David - gap analysis draft will take up the details of what has to be done to meet the requirements of this draft.  hopefully framework, architecture and gap analysis are all coming from the same place.
[17:24:52] <Giles Heron> David - there may be multiple gap analysis drafts (solution specific).
[17:25:27] <Giles Heron> Usman - other L2 technologies e.g. infiniband.
[17:26:17] <Giles Heron> David - not seen anyone talking about a L2 service in this WG other than Ethernet.  Suspect that assumption runs through the drafts we already have.  If you want to broaden scope then write a draft.  David's view is we have more than enough work with the existing scope.   Infiniband is rather overlay unfriendly also.
[17:26:25] <Giles Heron> Usman - so what do we do for DCs that deploy infiniband?
[17:26:28] <Giles Heron> Benson -good Q for list.
[17:26:43] <Giles Heron> John Messenger - When you say "Ethernet" do you mean Ethernet or IEE 802 MACs.
[17:26:50] <Giles Heron> David - 802.1Q is the bulk of the answer.
[17:28:14] <Giles Heron> David - Dino, LISP is a good IP/L2 solution, and to the extent you want to pitch it as an IP/L3 solution "have at it"
[17:28:41] <Giles Heron> Marc now updating on the framework draft - went through last call in the last couple of weeks.
[17:29:01] <Giles Heron> changes vs previous rev:
[17:29:11] <Giles Heron> 1) new stuff on VM mobility (some inherited from VM mobility draft)
[17:29:26] <Giles Heron> 2) clarifications of e.g. underlay vs core/backbone.  One or two occurrences left.
[17:29:31] <Giles Heron> 3) updated security section
[17:29:33] Daniel King leaves the room
[17:29:47] wmhaddad joins the room
[17:29:56] <farinacci> one control-plane is what you want to pitch, that does a service to data center operators
[17:30:00] <Giles Heron> seems we have agreement on substance.  Some editorial changes.    e.g. Thomas Narten / Larry Krieger have provided good feedback.
[17:30:06] <farinacci> for either push or pull mechanisms
[17:30:32] <Giles Heron> removing some redundant text that is repeated multiple times re address space separation.
[17:30:41] <Giles Heron> a few open items to discuss.:
[17:31:03] <Giles Heron> avoided term "Oracle" because is contentious.  Trying to stay generic.  recent comments from Larry.
[17:31:34] <Giles Heron> can we find generic terms e.g. like "access switch" instead of "ToR".  Marc has no problem changing this.  A ToR is an example of an access switch.
[17:31:53] <Giles Heron> clarified whether a single tenant can be composed of multiple VMs.  Yes!
[17:32:17] <Giles Heron> discussion on list re "inter-subnet communication".  Marc suspects this would be in a separate doc but maybe we'll have some generic text.
[17:32:44] <Giles Heron> David Black - we need to get rid of Oracle and pick something else and broadcast it from the treetops!  it's sneaking into draft names etc. and isn't the name we should use.
[17:32:50] <Giles Heron> Stewart - worried by trademark issues
[17:33:00] <Giles Heron> Benson - chairs will take action item and do something about it.
[17:34:04] wmhaddad leaves the room
[17:34:05] <Giles Heron> Marc - in conclusion.  we should be able to do final revision soon after Orlando.  David has done a good job of explaining difference between framework and architecture.  architecture doc can deal with more specific issues.
[17:34:30] wmhaddad joins the room
[17:34:41] <Giles Heron> Marc - if we publish a rev in the next few weeks need to be sure we get proper feedback.  last round of feedback from a few people (4 at most).
[17:35:06] <Giles Heron> Benson - chairs will select a few reviewers.  Any volunteers should let them know.  Intent is to last call this...
[17:35:26] <Giles Heron> next presenter is Lucy - NVO3 Use Cases
[17:36:23] <Giles Heron> 1) NVO for DC could be any sort of DC.
[17:36:50] <Giles Heron> 2) NVO to external network interconnect.  using NVO3-provided services for enterprises
[17:37:53] <Giles Heron> 3) DC apps using NVO3.
[17:38:04] <Giles Heron> a) multiple technologies in a DC - various examples.  e.g. NVO3 interworking with legacy equipment, interworking different NVO3 solutions (VXLAN/NVGRE etc.).
[17:38:40] <Giles Heron> b) multiple VNs in a tenant network - e.g. inter-subnet solution between different VNs for a tenant, "zoning" etc.
[17:39:16] <Giles Heron> c) NVO3 for vDC.  allows a DC provider to group resources (compute, storage, network appliances) as a vDC for a customer.  In this instance NVO3 is not the service but is running as part of a service for a vDC.
[17:39:24] <Giles Heron> so this doc describes all these use cases.
[17:39:35] <Giles Heron> changes since last version:
[17:39:52] <Giles Heron> added options B, C, D from 4364 for connection for WAN VPN.
[17:39:57] <Giles Heron> terminology fixes.
[17:40:17] <Giles Heron> editing for mailing list comments and to make it clearer/more readable.
[17:40:35] <Giles Heron> there are remaining comments from the mailing list:
[17:40:58] <Giles Heron> discussion of zoning and multiple webhosting apps for one customer (Vinay from PayPal)
[17:41:10] <Giles Heron> traffic management - do we need explicit text for these applications
[17:41:27] <Giles Heron> plan to address remaining issues and solicit more comment/feedback.  Want WGLC before Berlin.
[17:41:49] <Giles Heron> Benson asking how many have read it..  seems a fair scattering of hands.
[17:42:14] <Giles Heron> nobody seems to think it's close to being finished.  Chairs would agree.  Need the WG to come up with text and help contribute.
[17:42:40] <Giles Heron> Marc now presenting again - on data plane requirements...
[17:43:15] sriganesh.kini@jabber.org joins the room
[17:43:40] <Giles Heron> single slide - doc seems stable.  Only issue is controversy about Lucy's suggested text on a new L2/L3 service type.
[17:44:22] <Giles Heron> Marc completely opposed to the new service type.  Why have an IRB-like service type when IRB is implementation specific?  Large consensus to say no need for new service type.  Hence Marc thinks is ready for last call.
[17:44:31] wmhaddad leaves the room: Computer went to sleep
[17:44:39] <Giles Heron> Benson asking who's read it.  Fair number.  most of those seem to think it's ready for last call...
[17:45:25] cdub joins the room
[17:45:49] <Giles Heron> Larry is the next presenter - "hypervisor to NVE control protocol requirements"
[17:46:25] <Giles Heron> terminology changes/additions.  E.g. "Oracle" issue. currently saying IMA "Information Mapping Authority".  Woud be good to get feedback on that.
[17:47:17] <Giles Heron> framework talks about VAP "Virtual Access Point" that faces tenants.  Nothing documented on tenant side.  Today people talk about VNICs.  Better option may be TSI "Tenant System Interface".
[17:47:54] <Giles Heron> there's a relationship between VNIC (or TSI), virtual networks and physical networks.
[17:48:02] Bill Fenner joins the room
[17:48:09] <Giles Heron> VNIC can connect to one or more virtual networks.
[17:48:58] <Giles Heron> MAC addresses are required for L2 or L3.  Ethernet needs to be addressed to MAC of VNIC to not get filtered.  IP is IP over Ethernet from the tenant system to the NVE.  IP addresses required for L3 and may be useful for L2 if there's optimisations for IP.
[17:49:18] <Giles Heron> simple case is VNIC connects to one VN with one MAC and one IP.
[17:50:42] <Giles Heron> hypervisors have limitations today where only support 8 or 10 VNICs.  So there's a need to support multiple VNs on the same VNIC.  Also each VN may have multiple MACs (e.g. tenant system that's bridging e.g. for transparent firewall - all the MACs you're bridging for will appear on the VAP and need to be communicated to the NVE) or multiple IPs (e.g. virtual load balancer with multiple IPs for the various virtual servers).
[17:52:09] <Giles Heron> next steps - had meeting of the draft authors plus authors of related drafts.  Became clear that we need to put in some more detailed step-by-step requirements (hard to derive out mandatory/optional requirements).  Also need to bring in VM lifecycle events to explain motivations.  Planning to get together and update draft and then to ask for WG adoption.
[17:52:33] <Giles Heron> also another draft on NVE to IMA control plane reqs that Larry wants to see adopted.
[17:52:48] <Giles Heron> Linda - "IMA".  Why not "directory service"
[17:53:03] <Giles Heron> Larry - a directory service implies a pull model.  We want to be generic to push or pull.
[17:53:10] <Giles Heron> Linda - IMA reminds me of ATM.
[17:53:16] <Giles Heron> Larry - nobody will confuse us here.
[17:53:49] <Giles Heron> unintelligible question....
[17:54:12] <Giles Heron> Benson - we have a milestone on "control plane requirements".  Issue is we have multiple interfaces where we need a CP.  So will have >1 draft for that milestone.
[17:54:33] <Giles Heron> questioner - asking us to look at his NVE to NVE draft that he's presenting later.
[17:54:42] <Giles Heron> Larry - is NVE to NVE the same as Hypervisor to NVE?
[17:54:48] <Giles Heron> questioner - we'll explain later.
[17:55:18] <Giles Heron> question re slide 2.  describing this as a mapping table would be more reasonable.
[17:55:22] drudin joins the room
[17:55:26] <Giles Heron> Larry - not sure what you mean.
[17:55:36] Tim Wicinski joins the room
[17:55:49] <Giles Heron> Larry explaining the relationship.  Root is the VNIC, then the VN then MAC/IP etc.
[17:56:10] <Giles Heron> so it's a container relationship not a table.
[17:56:54] narten joins the room
[17:56:57] <Giles Heron> multihoming issues?
[17:57:55] <Giles Heron> discussion of reasons VNIC attaches/detaches etc.  Larry not saying protocol needs to explain why a VNIC attaches. But wants text to explain what drives an attachment.
[18:05:34] Tim Wicinski leaves the room
[18:11:48] S73654-TX0FB16B913 joins the room
[18:12:45] Tim Wicinski joins the room
[18:13:36] farinacci leaves the room
[18:14:37] Tim Wicinski leaves the room
[18:14:50] Tim Wicinski joins the room
[18:15:28] farinacci joins the room
[18:16:30] Tim Wicinski leaves the room
[18:17:47] Tim Wicinski joins the room
[18:18:49] Giles Heron leaves the room
[18:19:59] Giles Heron joins the room
[18:20:23] <Giles Heron> sorry guys - got booted out before.  Not sure if related to the speaker talking about security.  back on now :)
[18:20:45] <Giles Heron> So Linda talking about L2/L3 stuff.
[18:20:53] wmhaddad joins the room
[18:21:54] <Giles Heron> talking about L3 NVE acting as a proxy for the default GW (if you sit between the client and the real default GW you can optimise things).
[18:22:18] <Giles Heron> asking group if we should document the different types of default GW (centralised, distributed, virtual, proxy etc.)
[18:23:09] <Giles Heron> current framework doc has some text on optimum routing, triangle routing etc. and believe can do this much better.  Linda offering to send text to WG describing the issues.
[18:23:38] <Giles Heron> David - confessing has worked with Linda behind the scenes.  this is not an exhaustive discussion, but a bit of new text saying default GW may have an interesting distributed structure.
[18:24:06] <Giles Heron> David offering to work with Linda to craft text that explains issues without getting into details.
[18:24:41] cdub leaves the room
[18:24:43] <Giles Heron> Anoop now presenting on multicast issues in NVO3.
[18:25:36] <Giles Heron> explaining 4 ways you can do multicast in NVO3 (none, source replicated, replicated at a service node, or native IP multicast).
[18:25:48] <Giles Heron> looking at al 4 options:
[18:26:20] <Giles Heron> 1) no multicast implies that you're only doing unicast traffic.  IMA/Oracle can solve issue of resolving IP/MAC bindings.
[18:26:29] cdub joins the room
[18:26:39] <Giles Heron> problem is how do you support non-virtualised hosts.
[18:26:40] Tina Tsou joins the room
[18:27:19] <Giles Heron> 2) source replication (source NVE).   Still no need for multicast-capable underlay.  But NVE may have performance issues.
[18:27:34] <Giles Heron> (this is the VPLS model prior to enabling multicast there)
[18:29:08] <farinacci> there is a 5th way, a combination of the 4 ways
[18:29:20] <Giles Heron> 3) multicast service node.  really just shifts replication to that node so still potentially performance issues at the replication node - becomes a hot-spot, though you could distribute this.  Also an issue if you depend on the data-plane to learn MACs then this scheme has issues either with learning or with RPF (as packets come from replication node - not from the source NVE).
[18:30:18] <Giles Heron> 4) native IP multicast in the underlay.  People generally assume this is the solution.  ensures optimal delivery but potential scaling issue as need a different underlay multicast group for each tenant multicast address.
[18:30:43] <farinacci> for 3), you should look at LISP-RE
[18:30:44] <Giles Heron> (or rather can only be truly optimal if you use a different underlay multicast group for each tenant group)
[18:30:55] <Giles Heron> want me to take that to the mic Dino?
[18:31:23] <farinacci> for 4), you can do a many-to-one group mapping but this is the classical state/bandwidth tradeoff
[18:31:39] <Giles Heron> yes Dino - I think he kind of alluded to that.
[18:31:42] <farinacci> yes, thanks Gile, for all 3 comments I made
[18:32:10] <Giles Heron> Kireeti - suggesting you look at a different draft.  combination of ingress replication and replication nodes.  Means you can distribute the work without the underlay supporting multicast.
[18:34:01] <farinacci> agree with Kireeti and that is what LISP-RE does
[18:34:21] <farinacci> don't have to mention this, Kireeti will get a heart attack if he hears I agree with him  ;-)
[18:34:21] <Giles Heron> cool.  I made your comments anyhow and the group has been re-reminded that we have LISP on Friday :)
[18:34:31] <farinacci> LOL giles
[18:34:54] <Giles Heron> I might even turn up myself ;)
[18:36:01] <Giles Heron> Qin now presenting on architecture design and control plane requirements.
[18:36:08] <Giles Heron> 3 drafts here...
[18:37:06] <Giles Heron> showing diagram of the architecture..  3 interfaces - NVE/Oracle, NVE-Hypervisor and Hypervisor-vCenter (out of scope for NVO3?)
[18:37:53] <Giles Heron> talking about benefits of simple provisioning, increased uptime.  reduce provisioning time etc.
[18:38:05] <Giles Heron> talking about how you do provisioning in centralised or distributed approach.
[18:38:57] <Giles Heron> breaking a connection down into segments (source tenant to source NVE, source NVE to dest NVE, dest NVE to dest tenant)
[18:39:03] <Giles Heron> projector has now died.
[18:39:07] <Giles Heron> heat-stroke?
[18:39:16] <dhruvdhody> :)
[18:39:28] <Giles Heron> will let you all know when normal service resumed
[18:39:34] <Giles Heron> it's making hopeful noises
[18:40:01] <Giles Heron> Benson is showcasing his hardware engineering skills
[18:40:20] <Giles Heron> and his multitasking skills as he reminds us about the blue sheets
[18:40:55] <Giles Heron> the slide is starting to emerge....
[18:41:24] <Giles Heron> Qin working through his example.
[18:42:32] <Giles Heron> talking about centralised/distributed approaches to keeping mapping table up to date.
[18:42:45] <Tina Tsou> If u could mention the slide number, much appreciated from remote participants
[18:42:52] <Giles Heron> this is page 4
[18:42:58] <Giles Heron> previous speakers didn't always have slide numbers :(
[18:43:12] <Tina Tsou> Tks
[18:43:35] <Giles Heron> talking control / data plane learning
[18:43:42] <Giles Heron> now page 5 - showing how mapping table can be created, distributed, updated.
[18:43:52] <Giles Heron> again centralised vs distributed approaches
[18:44:59] <Giles Heron> slide 6 now.  discussing data plane learning.
[18:45:21] <Giles Heron> (or I think it's slide 6 - the slide number is buried under a text-box with a coloured background).
[18:47:09] <Giles Heron> now page 7.
[18:47:11] S73654-TX0FB16B913 leaves the room
[18:48:44] <Giles Heron> now page 8 - relying on mapping table distribution.
[18:50:00] <Giles Heron> final slide - next steps.
[18:51:04] <Giles Heron> david  - nice work, lots of details.  some of this ought to go in the architecture.  probably not all.  mostly focussed on L2 service.  but details may well end up in solution drafts - not sure architecture draft needs all this step-by-step detail.
[18:51:58] <Giles Heron> David - encouraging you to keep going.  but when you get into specifics of methods you're starting to cross the line from overall architecture to specific solutions.
[18:52:14] <Giles Heron> Benson - out of time.  but this is good material and we'll follow up
[18:52:36] <Giles Heron> Florin now presenting on Federated Sdn-based controllers for NVO3.
[18:52:54] <Giles Heron> scope - end to end solution view.  show how modules interact.
[18:53:08] <Giles Heron> aim is to generate discussion about gaps.
[18:53:18] <Giles Heron> now slide on "DC Network Virtualization Framework" with diagram.
[18:53:31] <Giles Heron> (slide 4)
[18:53:46] <Giles Heron> slide 5 now.  Control, Data and Management Plane for one DC domain
[18:54:03] <Giles Heron> they're using "controller" instead of "oracle"
[18:54:23] <Giles Heron> showing management, control and data-planes.
[18:54:56] <Giles Heron> have discussed when you distribute controller.  could go to NVE level.  or could be centralised to save on server resources.
[18:55:18] <Giles Heron> management plane is "cloud management system" (e.g. Openstack/Cloudstack).
[18:55:43] <Giles Heron> CMS talks to controller via API (e.g. Quantum for Openstack)
[18:56:11] Bill Fenner leaves the room
[18:56:22] <Giles Heron> tenant system states based on VM lifecycle management.  but also needs to work for appliances etc.
[18:57:00] <Giles Heron> need to discover tenant system states.  could be top down (CMS) or bottom up (NVE).
[18:57:42] <Giles Heron> key is defining  a good information model. Don't think can push to standardise APIs.
[18:58:19] <Giles Heron> discussing role of controller.
[18:58:49] <Giles Heron> now showing "extending the model across DC domains and to VPN WAN"
[18:59:10] <Giles Heron> same 3-plane model with WAN attached to it.
[18:59:31] <Giles Heron> easiest option is MP-BGP module on controller.  that can talk to the WAN MP-BGP.  Act as a virtual PE.
[18:59:48] farinacci leaves the room
[19:00:00] <Giles Heron> can then use MP-BGP also between different controller domains (e.g. multi-vendor).
[19:00:10] <Giles Heron> slide 7 now - what's covered and what's missing
[19:00:56] <Giles Heron> need to be conscious that people have been working on CMS etc. for 3 or 4 years so NVO3 needs to work with that.
[19:01:18] <Giles Heron> need a model so Openstack developer can see what's missing.
[19:01:43] <Giles Heron> for NVE-drive TS state discovery are suggesting Openflow extensions.  Only needed for centralised controller model.
[19:02:02] <Giles Heron> if NVE is on ToR then need server to NVE signalling.  Multiple drafts out there now in NVO3.
[19:02:15] <Giles Heron> also suggesting Openflow for controller to NVE FIB download.
[19:02:31] <Giles Heron> suggesting re-use of E-VPN for L2 MP-BGP from controller to PE and IP-VPN for L3.
[19:03:04] <Giles Heron> draft already in L2VPN showing E-VPN over VXLAN/NVGRE.
[19:03:04] <Giles Heron> slide 8 now - next steps.
[19:04:06] <Giles Heron> Linda asking if this is in NVO3 scope
[19:05:17] <Giles Heron> Now Linda's asking if gap analysis is for existing or new solutions.
[19:05:33] <Giles Heron> Benson - we can do gap analysis against a new solution.  But won't adopt anything in NVO3 until we've rechartered.
[19:06:18] <Giles Heron> Benson - suggesting that authors go through this and ensure that requirements are all captured and assist with gap analysis.  when we recharter we can look at adoption.
[19:06:30] <Giles Heron> Florin - we're following framework/requirements
[19:07:12] <Giles Heron> Marc - this draft is a mix of gap analysis and solution.  Ideally there's a companion draft.  this could be in same draft or a companion.  Sometimes it's difficult - if we split the two then we have to repeat ourselves.
[19:07:27] <Giles Heron> Benson - might revisit that at the end. we need to be sure we're dividing work up the right way.
[19:07:35] <Giles Heron> Lucy is next presenter
[19:07:47] <Giles Heron> "IP/MPLS VPN Protocol Gap analysis for NVO3"
[19:08:17] <Giles Heron> slide 2 - "about this draft"
[19:08:54] <Giles Heron> slide 3 - "NVO3 Requirements"
[19:09:03] <Tina Tsou> There is another gap analysis draft http://datatracker.ietf.org/doc/draft-chen-nvo3-gap-analysis/
[19:09:06] <Giles Heron> comparison table for individual requirements.
[19:11:42] <Giles Heron> now on "quick comparison" slide
[19:12:59] <Giles Heron> Tina - do you want me to bring your draft to the WG's attention at the mic?  or are you here?
[19:14:09] <Tina Tsou> Sure, thank u, I'm in California
[19:14:12] <Giles Heron> now another slide on the quick comparison
[19:14:14] Tim Wicinski leaves the room
[19:14:17] Tim Wicinski joins the room
[19:14:21] Tim Wicinski leaves the room
[19:14:50] <Giles Heron> now VPN Interconnect DC Underlay Networks slide
[19:15:43] <Giles Heron> now "DC NVO Access via a WAN VPN"
[19:16:13] <Giles Heron> (slide 7)
[19:17:25] <Giles Heron> final slide is next steps
[19:18:17] <Giles Heron> nabil @ mic.  other draft from Taiwan. agreed to merge drafts.  did work prior to atlanta.
[19:19:42] Melinda leaves the room: Computer went to sleep
[19:20:00] <Giles Heron> I just mentioned Tina's draft @ the Mic.
[19:20:14] <Giles Heron> now Melinda Shore is talking about state migration in overlay networks
[19:20:23] <dhruvdhody> no slides?
[19:20:24] <Giles Heron> problem slide.
[19:20:39] <Giles Heron> issue of network flows instantiating state in middleboxes, load balancers etc.
[19:20:49] <Giles Heron> so to migrate a VM you may need to migrate that state.
[19:21:04] <Giles Heron> slides are on screen in here.
[19:21:09] <Giles Heron> maybe not online.
[19:21:13] <Giles Heron> will type more :)
[19:21:21] <dhruvdhody> thanks :)
[19:21:22] <Giles Heron> so next slide is "solved and unsolved problems".
[19:21:35] <Giles Heron> IETF has a load of protocols for instantiating state.
[19:21:58] <Giles Heron> unsolved problems re network topology/discovery, triggers for migration, copying state out of middleboxes to a new middlebox etc.
[19:22:02] <Giles Heron> status slide.
[19:22:12] <Giles Heron> fairly mature framework (draft-gu-statemigration-framework)
[19:22:19] <Giles Heron> think understand the problems
[19:22:26] <Giles Heron> new doc - draft-gu-statemigration-arch.
[19:22:31] <Giles Heron> much less mature and want feedback/review
[19:22:36] <Giles Heron> had discussions with TSV ADs
[19:22:50] <Giles Heron> TSV is locus of middlebox expertise in IETF so they're the right people to talk ot
[19:22:53] <Giles Heron> talk to even
[19:23:03] <Giles Heron> but not the only area that needs to deal with this.  NVO3 is another example.
[19:23:06] <Giles Heron> next steps slide
[19:23:10] <Giles Heron> want more review of architecture doc
[19:23:19] <Giles Heron> want agreement on overarching design even if don't work on a protocol
[19:23:30] <Giles Heron> want to ensure is consistent with nvo3 design decisions so is real-world useful
[19:23:39] <Giles Heron> informal get-together after tech-plenary tonight.
[19:23:47] <Giles Heron> will send info on get-together to sami and nvo3 mailing lists.
[19:24:02] narten leaves the room
[19:24:04] <Giles Heron> Benson - agree this isn't in-scope for NVO3 but encouraging authors to look at this in terms of requirements for NVO3
[19:24:11] <Giles Heron> Melinda - will get text together.
[19:24:17] <Giles Heron> no other comments.
[19:24:51] <Giles Heron> Benson pulling up chairs slide one last time.   question Marc had re dividing up solution work and gap analysis.
[19:25:35] <Giles Heron> so looking at middle bullet on "NVO3 Next Steps - 2" slide.
[19:25:53] <Giles Heron> if solution is from another WG then gap analysis might have applicability statement pointing to those docs.
[19:26:10] <Giles Heron> if solution is in another SDO we may need to elaborate more if the refs aren't publicly available
[19:26:39] Melinda joins the room
[19:26:46] Matt Welch leaves the room
[19:26:48] <Giles Heron> if solution is individual I-D (like Florin's doc) then might make sense to divide into a larger applicability statement and a gap analysis that references that.  so then WG can adopt the gap analysis but not adopt the individual draft until we are rechartered.
[19:27:03] ipankajg joins the room
[19:27:24] <Giles Heron> Marc saying Benson's answer is clear, but he's not sure it is the best way to move forward.  worry is we could get tons of specific cap analyses.  Repetition of text between gap anaylsis and solution.
[19:27:52] <Giles Heron> Marc thinks in most cases gap analysis can probably be within the solution draft. After all we have an overall gap analysis.
[19:28:06] <Giles Heron> Matthew - agree in principle.  But we can't adopt drafts that contain solutions until we recharter.
[19:28:39] ipankajg leaves the room
[19:28:50] <Giles Heron> Nabil - (1) the intention here is to cover existing solutions that have already been documented.  (2) gap analysis for that solution is then done vs NVO3 problem statement/requirements.
[19:28:52] Pankaj Garg joins the room
[19:29:15] <Giles Heron> Benson - you can imagine requirements aren't satisfied by any existing solution. So the requirements might point towards a new solution
[19:29:26] <Giles Heron> Nabil - could be extensions to an existing solution or a new solution.
[19:30:02] <Giles Heron> Benson - as a WG we need to make sure we look at all solutions we might want to consider.  whether we do that in one big document or with a doc that summarises and points to individual docs isn't a big issue to the chairs.
[19:30:28] <Giles Heron> Nabil - there's an existing doc that does a lot of this. Should we hold off for now - or distribute to get feedback as to whether it's sufficient.
[19:30:36] <Giles Heron> Benson - we'll follow up with you and authors of the other drafts.
[19:30:53] Matt Bocci leaves the room
[19:30:59] <Giles Heron> Linda - seems odd that you'd have gap analysis for a new solution.
[19:31:16] <Giles Heron> Benson - we're done. thank you everyone.
[19:32:01] Stewart Bryant leaves the room
[19:32:01] Giles Heron leaves the room
[19:33:24] Melinda leaves the room: Computer went to sleep
[19:33:35] wmhaddad leaves the room
[19:36:17] Pankaj Garg leaves the room
[19:39:55] Wes George leaves the room
[19:41:42] Bill Fenner joins the room
[19:42:40] Giles Heron joins the room
[19:42:40] Giles Heron leaves the room
[20:00:08] Tina Tsou leaves the room
[20:00:34] narten joins the room
[20:07:51] Tina Tsou joins the room
[20:10:26] Tina Tsou leaves the room
[20:10:29] Tina Tsou joins the room
[20:13:46] Tina Tsou joins the room
[20:14:24] Tina Tsou leaves the room
[20:20:56] Tina Tsou leaves the room
[20:24:53] cdub leaves the room
[20:28:51] Tina Tsou joins the room
[20:31:53] Tina Tsou leaves the room
[21:13:17] Bill Fenner leaves the room
[21:13:26] narten leaves the room
[21:24:10] Bill Fenner joins the room
[21:30:35] farinacci joins the room
[21:40:59] Bill Fenner leaves the room
[21:51:08] Bill Fenner joins the room
[21:57:04] narten joins the room
[22:39:10] Tina Tsou joins the room
[22:42:04] farinacci leaves the room
[23:17:19] dhruvdhody leaves the room
[23:42:05] narten leaves the room
[23:49:30] Bill Fenner leaves the room
[23:53:07] farinacci joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!