[Notes from 2016-01-28 interim: http://etherpad.tools.ietf.org:9000/p/notes-interim-2016-teas-1] > Agenda > TEAS Agenda For IETF 95 >                     TEAS Agenda For IETF 95 >                     Version: Mar 31, 2016 >                      >                     Monday, April 4th, 2016 >                     10:00 - 12:30 - Monday Morning Session I >                     Room: Atlantico B > Presentation         Start Time     Duration     Information      > 0           10:00     10     Title:     Administrivia & WG Status >                 Draft:      >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-0.pptx >                 Presenter:     Chairs (no questions/comments) > 1           10:10     10     Title:     WG Draft updates >                 Draft:     Many >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-1.pptx >                 Presenter:     Chairs (no questions/comments) > 2           10:20     10     Title:     Discussion on  RSVP-TE for LSP Ingress Local Protection >                 Draft:      >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-2.pptx >                 Presenter:     Adrian Farrel Lou Berger: I find it useful that you labelled LSP-ingress in the final case (slide 5). Where does the LSP start in the other 2? Adrian Farrel: double-line on the slides is the LSP. The problem is that the head-end fails; the solution is how we get traffic to the destination. Eric Osborne: I'm not sure what's in and out of scope（on page 5）, but if I'm interested in anything it's the third case Adrian Farrel: Thanks, that's helpful Eric Osborne: Are we just talking about RSVP LSPs? Adrian Farrel: Just RSVP for this WG Eric Osborne: Not everyone runs PE-PE RSVP... Greg Mirsky: I agree that OAM has to be considered. We also need to specify what type of protection or restoration we can deliver as that will define the mechanisms we can use for monitoring Adrian Farrel: so you're saying, whether it's 1+1 or 1:1 or 1:n protection, and for restoration whether it's repair after failure Lou Berger: FRR is missed;  Adrian Farrel: FRR as currently defined cannot settle the ingress problem; FRR is a big problem... Lou Berger: do we want a solution that's tailored to work with FRR? Do we not care? Greg Mirsky: I think we can not use FRR but say segment protection Adrian Farrel: maybe say 'bypass tunnel'? Would that be less contentious? Eric Osborne: if I have to do something other than the FRR I already have I'm not that interested right now Gabriele Galimberti: would you also consider CE-PE link failures? This doesn't change the way you handle it but it changes detection Adrian Farrel: if you run LSPs from the CE you're interested in CE failure; if you run from the PE then it's PE failure. The main scope here is head-end LSP failure, wherever the LSP happens to run from. Gabriele Galimberti: CE failure requires the same actions Greg Mirsky: one more thing we need to define: what LSP head-end failure is. Adrian Farrel: yes Jeff Tantsura: More things we need to define: Do you want to merge back up and primary at merge-point? What do you want to do with LSPs? Adrian Farrel: challenge is to separate that out into the behaviour you want to define, rather than the techniques you want to use. Danger is that people say "I want to use FRR". Lou Berger: first focus on the problem before talking about solutions; (Questions) how many of you think it's a valuable problem? （reasonable number）; only first and third use case receive interests. How many of you understand the discussed options sufficently to have an opinion on the three use cases (a few).  Lou Berger: I feel we don't understand the problem well enough yet to discuss options here Jeff Tantsura: we can learn a lot from pseudowire protection discussions. Lou Berger: That's great, if you have any pointers, please send them to the list. I don't think we have a good enough understanding of the problems yet.  Think that we need to further discuss what problem we'd like to solve with ingress protection on the list. Lou Berger: It's useful to hear from the room that there is interest in the WG continuing to work on the problem (Ingress protection).  > 3           10:30     20     Title:     Extensions to RSVP-TE for LSP Ingress Local Protection >                                         Extensions to RSVP-TE for LSP Egress Local Protection >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/  >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-3.pptx >                 Presenter:     Huaimo Chen (for Ingress local protection draft) Pavan Beeram: for the scope are you referring to the FRR? Huaimo Chen: yes (for Egress local protection draft) Eric Osborne: I realize the ingress and egress are different but it'd be nice if the solutions were as close as possible. It doesn't make sense to have locally-scoped ingress protection and end-to-end egress Huaimo Chen: egress is also local Jeffery Zhang: we have a doc in MPLS for both RSVP and mLDP egress protection. Huaimo Chen: OK. I read Yimin's draft. Looks like there's overlap.  Lou Berger: it'd be good to look at existing solutions, if they exist, expecially for egress protection. And also discuss on the list Lou Berger: you said this covers FRR. Do you think the scope of egress protection is limited to FRR? Huaimo Chen: only FRR at this stage Lou Berger: is the WG OK with egress protection excluding segment protection and using only FRR.  Eric Osborne: as long as it's at least FRR, it doesn't bother me if you do other stuff too Lou Berger: in general we want to look at the broadest scope possible. Can narrow scope if there's a reason to do so but if not, we should cover both FRR and segment protection in this WG, even if it's just informative (beacuse nothing new is needed) > 4           10:50     30     Title:     YANG Data Model for TE Topologies >                                 >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-4.pptx >                 Presenter:     Xufeng Liu Lou Berger: for this presentation we're covering changes to the model that haven't really been discussed on-list Pavan Beeram: we've had quite a bit of dicussion off-list, so please use the WG list for further discussion Gert Grammel: (page 12), what do you mean by switching layer? where does this layer exist? Are you talking about ITU layers, which can all be switched? Or are you talking about things like MPLS and IP? It needs to be clarified. Fatai Zhang: are you going to define both transitional link and inter-layer lock?  Xufeng Liu: yes Fatai Zhang: better to define one of them as we can then do more analysis on pros and cons, and then pick one Igor Bryskin: we don't talk about inter-layer leaks. I think inter-layer computations are an important problem to solve. It would be useful to be able to have separate topologies at different layers but allow computations across layers. Inter-layer lock Using SRLGs can achieve this, which has advantage compared with transitional link. Dieter Beller: during the weekly calls we discusssed the two approaches, and the inter-layer lock id also has some drawbacks (you need an admin entity to assign the lock IDs). The concept of transitional links has the advantage that it's based on links and only requires some extensions. Lou Berger: I think this has been informative for folks that aren't involved. Informal discussions are open to all, but please send updates to WG list to coordinate calls and send updates so everyone's on the same page. Igor Bryskin: I disagree with Dieter.... Lou Berger: I look forward to seeing that discussion on the list. And also the announcement for the next informal meeting. > 5           11:20     10     Title:     RSVP Extensions For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-5.pptx >                 Presenter:     Rakesh Gandhi Lou Berger: I'm having trouble understanding the need for another fragmentation mechanism - s2l was introduced for this in the first place. I'd like to understand the need for this one. I think this needs to be clarified before LC. Rakesh Gandhi: Problem is when we send one s2l at a time, head-end doesn't know when to start things like reoptimization. RFC 4875 has a combined message defined but there's an issue when things are fragmented. Lou Berger: I think this is a discussion to have offline, and I'd like to have it. I know this (fragmentation) wasn't in the original proposal and came in as a result of comments in MPLS WG. I think we need to make sure we're not overloading too many mechanisms, and that it's clear why the existing mechnisms are insufficient. > 6           11:30     10     Title:     RSVP-TE Extensions for Collecting SRLG Information >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-6.pptx >                 Presenter:     Matt Hartley (remote) Lou Berger: A successful remote presentation! Thank you Matt (and Meetecho) > 7           11:40     15     Title:     Framework for Abstraction and Control of Transport Networks >                 Draft:     http://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-7.pptx >                 Presenter:     Daniele Ceccarelli Igor Bryskin: for a multi-domain network there will be inter-domain leaks. Daniele Ceccarelli: same concepts apply to inter-domain links as to access links Igor Bryskin:  Daniele Ceccarelli: So maybe we should call them access links rather than inter-domain links Igor Bryskin: Everything you discussed could be done with two models Lou Berger: doesn't change whether we move fwd w/ this doc. Just they point better at each other Gert Grammel: I was confused between a customer service provider model (often cited) which is more a policy issue, vs a network model (client-server relationship) where considerations about visibility simply don't apply. So it's tricky to figure out what you're describing in the draft. The assumption is that a layer is controlled by an entity and it has a client that's controlled by another entity, but that's not always the case. Daniele Ceccarelli: multi-layer applies. if client and server are managed by the same entity then that's one issue... Gert Grammel: question is how to define a 'domain'? Daniele Ceccarelli: domain is everything managed by an MDSC. Could be tens of differnet networks but as long as they're managed by the same MDSC they're one domain Gert Grammel: so if you have three domains run by a single provider, is that one domain? Daniele Ceccarelli: customer sees it as a single domain, provider runs it as he prefers. Gert Grammel: so need to distinguish between customer domain vs technical domain. Lou Berger: it seems that there's room for better-aligned terminology. I know you did this with SDN terminology, but also should align with the yang terminology Daniele Ceccarelli: what's not aligned? Lou Berger: what Igor talked about - access points. Also whether the boxes in the figure can be referred as a PCE or not? Daniele Ceccarelli: the PNC can be a PCE or something else. Lou Berger: are you gonig to take another pass? Daniele Ceccarelli: well, the WG needs to approve before the draft gets adopted. Lou Berger: (poll) How many think this is ready for adoption? (reasonable number) Lou Berger: how many want another revision (two) Lou Berger: okay will poll for adoption.  Question 1: is this work we should be doing in the WG (reasonable number) Lou Berger: Question 2:how many have read this draft? (slightly more) Lou Berger: Question 3: how many think this draft is a good foundation for the work? (more than the first one) Lou Berger: looks like we have good support in the room so we can take it to the list. > 8           11:55     10     Title:     Information Model for Abstraction and Control of TE Networks (ACTN) >                 Draft:     http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-8.pptx >                 Presenter:     Sergio Belotti / Young Lee Lou Berger: Last time Scott Mansfield gave another presentation on info model, and it was mentioned to work together, how's that going? Sergio Belotti: That info model presentation (by Scott) focused on how to make use of the YANG model, which is different from the one presented here. Lou Berger: concern is that we'd end up with two information models modelling the samething differently Gert Grammel: is this a client-server relationship or a customer-provider relationship? Need to spell that out. Young Lee: This is based on ACTN requirements and framework - nothing to do with other SDO model (by Scott). We're just trying to capture information elements before designing a protocol. Lou Berger: we should make sure such models are orthogonal and there is no overlap, otherwise there will be conflict.  Young Lee: but this is based on ACTN rather than anything else. Lou Berger: We should have more discussion on the list. We don't have to wait for a meeting to declare consensus but we do need to discuss. Lou Berger: we're running short of time, so cutting the discussion short here. > 9           12:05     10     Title:     RSVP-TE Extensions For Associated Co-routed Bidirectional Label Switched Paths (LSPs) >                 Draft:     https://datatracker.ietf.org/doc/draft-gandhishah-teas-assoc-corouted-bidir/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-9.pptx >                 Presenter:     Rakesh Gandhi Pavan Beeram: So you're just adding the co-routed flag and the extension object? Rakesh Gandhi: yes - source, lsp-id and co-routed flag Pavan Beeram: and you're just proposing a flag to make it co-routed Rakesh Gandhi: Yes, and also the midpoint needs to assign a corouted bypass Lou Berger: But the egress node already has that information Rakesh Gandhi: Yes, but it doesn't say the LSP is co-routed Lou Berger: So you're saying there's ambiguity in the current spec? Rakesh Gandhi: Yes. If there's a loose hop, how does the egress know it should follow the same path? Lou Berger: So you're requiring co-routing? Rakesh Gandhi: yes Lou Berger: And then you're adding a hint for the transit LSR. But isn't this already in the path message? Rakesh Gandhi: But nodes can have multiple LSPs (e.g. during reoptimization) Lou Berger: OK. I think we need a better definition of what's missing from the current definitions (RFCs) and what the gap is in order to have agreement that we need to solve the problem.  Feel free to send new draft text to list to get this discussion going. > 10           12:15     15     Title:     The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs >                 Draft:     https://datatracker.ietf.org/doc/draft-zhao-teas-pcecc-use-cases/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-10.pptx >                 Presenter:     Quintin Zhao Dieter Beller: I found some negative statements in the draft about the RSVP solutions already deployed, and I have some concerns about that. Quintin Zhao: Customers decide this, if they prefer not implementing RSVP, we provide this solution. Lou Berger: people sometimes feel they have to destroy old solutions to define new ones; this isn't really necessary. Just focus on the new stuff. Jeff Tantsura:Need to think about SR and separation of the link state. This reminds me of openflow with its centralized controller.  Adrian Farrel: I'm intrigued to see the last two speakers say that SDN is a bad idea Lou Berger: TEAS is a big tent, we can accomodate both approaches :) Lou Berger: thanks for coming, see you all tomorrow for the joint Yang session > Adjourn           12:30                   >                      >                      >                     TEAS/MPLS/PCE Yang Agenda For IETF 95 >                     Version: Mar 31, 2016 >                      >                     Tuesday, April 5th, 2016 >                     17:30 - 19:00 - Tuesday Afternoon Session III >                     Room: Atlantico B > Presentation         Start Time     Duration     Information      > 0           17:30     10     Title:     Administrivia >                 Draft:      >                 Presenter:     Chairs > 11           17:40     10     Title:     YANG Data Model for TE Topologies >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-11.pptx >                 Presenter:     Xufeng Liu Pavan Beeram: guidance at last IETF was to separate out packet-specific stuff and publish as a separate TEAS document and share details on the MPLS WG list. Loa Andersson: Model will support multi-layer (work in progress). Two approaches are considered "transition link" and "inter layer lock". > 12           17:50     15     Title:     A YANG Data Model for Resource Reservation Protocol (RSVP) >                                          A YANG Data Model for Traffic Engineering Tunnels and Interfaces >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp/ >                 Draft:     https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-12.pptx >                 Presenter:     Tarek Saad Dhruv Dhody: in PCE WG our aim was to have a generic PCEP Yang. What's the ietf-te-PCC you have? Tarek Saad: Dhruv Dhody: We can discuss offline, but should that belong in IETF-PCEP? Tarek Saad: OK, let's talk about that Cyril Margaria: Where's the source in the tunnels? Tarek Saad: data needs to be globally scoped to model the network, and it's keyed by name. We thought that the name can be made global by prepending the source router name or id. All implementations seem to support name-based tunnels. Cyril: is this in the draft? Tarek Saad: the key in teh draft is a string. we can make this clearer if need be. Dhruv: I'd like to thank the authors for taking comments form PCEP and making a generic ietf-te . ? Tarek Saad: we thought about embedding a distinuisher in the tunnel name but we decided it was unnecessary Pawel Brzozowski: Name can be globally unique - are you saying the source isn't valuable? Tarek Saad: no, but the name is sufficient for a unique key. Pawel Brzozowski: So the source ID doesn't have to be part of the key Tarek Saad: we have the source in the model Lou Berger: Naming: you didn't want to use PSC, so you used MPLS. That will lead to confusion as we have some base models that are MPLS that will be used for non-packet stuff. I appreciate that PSC is GMPLS-centric term - maybe just use "packet"? Tarek Saad: other models will use this too Lou Berger: I think MPLS as packet will lead to confusion, but I'm interesting in what other folks have to say. I think having MPLS implicitly be PSC will cause confusion Adrian Farrel: suppose there was another box for RSVP/GMPLS... Lou Berger: GMPLS-packet is an augmentation  Tarek Saad: Yes, for bidirectional Lou Berger: I'd hope bidir would be part of the core as it applies to everything except traditional RSVP-TE Lou Berger: I'll back up: until you have GMPLS in this picture I don't understand it. I still think you need a term for packet other than MPLS. Loa Andersson: question to Lou: what's the cause of the confusion by using MPLS and why is packet better? Lou Berger: I think we'll end up with a bunch of technology-specific models, which will look like GMPLS. until we see how it all fits together i dont' really understand it. So I'd like to see the authors proposal for this. Jon Hardwick: we should take this offline as we need to keep to schedule Lou Berger: OK. As TEAS chair I'd like to see a GMPLS module. Lou Berger: another thing: you have a use-case for the schema mount idea that we (routing design team) think is likely to happen. Please take this to netmod and say that their restrictions are too extreme for your use-case - that would be useful information Igor Bryskin: I agree with Lou that 'MPLS' is confusing. I like to call PSC PSC - we should use the right names for each technology. Things like MPLS are ambiguous. Tarek Saad: we went away from PSC becasue ti was confusing. Qeustion now is between packet and MPLS. > 13           18:05     10     Title:     A YANG Data Model for MPLS Base and Static LSPs >                 Draft:     https://datatracker.ietf.org/doc/draft-saad-mpls-static-yang/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-13.pptx >                 Presenter:     Tarek Saad Adrian Farrel: Static LSP... I'm trying to work out whether what you describe is an end-to-end LSP or an LSP as seen at one node Tarek Saad: End-to-end. We have the notion of in- and out-segment so we're defining exposed swap and pop... but for the LSP we have an operation that applies on head/transit/egress Adrian Farrel: So it's a bit like an explicit route with labels Tarek Saad: Yes Adrian Farrel: So when I use the model, what's different between a static LSP and a RSVP-TE signaled one? Tarek Saad: Static is config-driven Adrian Farrel: But from the point of view of a user who doesn't understand the difference, how does the model look different? Tarek Saad: What we're trying to model is what operations need to be invoked on invoming/outgoing labels. RSVP has a lot of state and timers, etc. In the data-plane they'll look alike but we aren't modeling that yet Adrian Farrel: I understand the data-plane and what coders have to do, but when you request an LSP from the management plane, isn't the information all the same? Tarek Saad: The interface we're exposing is a data model. But this is mostly config-driven. Jon: please take to the list Dhruv Dhody: IETF-TE works at the controller. Is MPLS static LSP only for the device or can it be used at the controller too? Tarek Saad: controller can provision an LSP using this? ? (inaudible) George Swallow: you mentioned multiple labels. Have you considered how a SR LSP would look? And are you engaging with SPRING WG? Tarek Saad: It's still a static LSP.  George Swallow: Or it could be a stack of labels. Tarek Saad: We think the operations we've defined (impose/swap/pop) also cover SR Lou Berger: From a chair's perspective you have at least a couple of models here and you should consider separating them Tarek Saad: OK, thanks. Jon Hardwick: The right list is MPLS. OK? Lou Berger: I think it should be the list for the WG that owns the draft. And if the intent is that it should cover TE and non-TE then MPLS is the right list. > (~18:25) > 17           18:50     10     Title:     Yang Data Model for LSP-PING >                 Draft:     https://datatracker.ietf.org/doc/draft-zheng-mpls-lsp-ping-yang-cfg/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-17.pptx >                 Presenter:     Guangying Zheng (no questions) > (~18:34) > 15           18:30     10     Title:     A YANG Data Model for Path Computation Element Communications Protocol (PCEP) >                 Draft:     https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-15.pptx >                 Presenter:     Dhruv Dhody Tarek Saad: I see that the ietf-device model we've introduced is a fit to be augmented by this. Dhruv Dhody: Yes for the first part, but when you come to PCE it's PCE stuff. We can figure this out but the feeling is this belongs in IETF-TE rather than in PCEP. Lou Berger: As NETMOD chair, I'll say that this whole topic is an open one and the WG is trying to come up with a solution. I have no idea if we'll succeed, but we hope to have a better idea by Berlin. The objective right now is that model writers won't have to do anything to support opstate - there will be tooling to provide the elements we need. That's the hope.  Dhruv Dhody: So keep drafts as they are for now? Lou Berger: Don't go decorating your models with intended/applied if you haven't already done so. If you have, don't change it back. Jon Hardwick: we should talk about this in PCE WG tomorrow. (~18:41) > 16           18:40     10     Title:     YANG Models for the Northbound Interface of a Transport Network Controller: Requirements, Functions, and a List of YANG Models >                 Draft:     https://datatracker.ietf.org/doc/draft-zhang-ccamp-transport-ctrlnorth-yang/ >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-16.pptx >                 Presenter:     Xian Zhang Cyril Margaria: the service model looks a lot like tunnel information. Why not use that? Xian Zhang: the reason we do it separately is that for the tunnel model there's a lot of stuff the client doesn't need. Cyril Margaria: but those aren't mandatory Tarek Saad: I would expect that some of these would be augmentations to TE-tunnel. Xian Zhang: So do you think these things are generic? Lou Berger: What we're seeing here is specific to a specific technology - it's in CCAMP. What here is technology-specific? Xian Zhang: Not a lot. But the use-case we focus on is technology-specific which is why the draft is in CCAMP Lou Berger: OK. I think the details belong in TEAS. Do the CCAMP chairs want to say anything? Adrian Farrel: I'm interested by the scheduling piece of this. We have work going on in TEAS around scheduling LSPs from a control-pane point of view. What I see here is a very generic scheduling policy - you could schedule anything in the IETF with this. Someone probably needs to talk to the right person about whether this should be a separate model. Xian Zhang: I'm not writing my own schedule paths - I'm using pre-existing ones Rajiv Asati: if it's related to northbound, so we really need to have the specifics in the model that describes every node where the service needs to be instantiated? Can we abstract the details out Xian Zhang: you're right to some extent. Some use-cases (e.g. #2) need to expose technology-specific info. We'd need a use-case for the abstracted version. (~18:52) > 14           18:15     15     Title:     YANG Data Model for MPLS LDP and mLDP >                 Draft:     https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang  >                 Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-14.pptx >                 Presenter:     Rajiv Asati Loa Andersson: I'm a bit split as I'm an author of LDP and also a member of the design team. I don't think we're doing anything more strict than in RFC 5036. What's stricter is that we're getting away from the rather loose concept that we've had since then. Lou Berger: Did you hear Andy's talk in NETMOD yesterday? Rajiv Asati: Yes Lou Berger: There's a guideline update happening, so please send that to Andy Rajiv Asati: I sent a mail this morning Jeff T: Could we have a goal for the yang design team to come up with this by Berlin? This quesiton comes up over and over again Lou Berger: it's an AI for netmod at this point. One of the changes from yesterday to now is that this is now a specific deliverable. Rajiv Asati: even if there's no recommendation, pros and cons would be nice. Lou Berger: I'd like specific guidelines. NETMOD is the right place for that conversation. ============ Jon: I think that was a really useful session. Special mention to Matt for the agenda. That's the end of the agenda. Please come to PCE tomorrow :) > Adjourn           19:10                   >  >  >  Notes from Haomian and Matt