> [Please add your name to the end if you want to be acknowledged as a note taker. > This is not required. Notes should be added below, after the slot/draft slide url] > > TEAS Agenda For IETF 96 > Version: Jul 15, 2016 > > Thursday July 21st 2016 > 10:00 - 12:30 - Thursday Morning Session I > Room: Charlottenburg II/III > >Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-teas > Video: https://www.youtube.com/watch?v=_o_HEhgdL-w > Joint session: https://www.youtube.com/watch?v=t26WRG36Rkc > Num Start Duration Information > Time > > 0 10:00 10 Title: Administrivia & WG Status > Draft: > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-0.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-0.pptx > Presenter: Chairs Lou Berger: please respond to IPR requests; we can't progress a document until all authors and contributors have done so. > 1 10:10 (10:08) 10 Title: WG Draft updates > Draft: Many > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-1.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-1.pptx > Presenter: Chairs Pavan Beeram: Open questions from June need discussion on list. Additive vs non-additive attributes - can non-additive attributes be handled by this draft? If we open the door to non-additive attributes, should we add others, such as those discussed in RFC 7471?? Do we need a generic mechanism for the collection of these attributes? Pavan Beeram: Anyone here want to talk about this now? Pavan Beeram: Please discuss on the list. Poll: How many have read latest version How many have read any version How many think ready for last call Any technical objections Lou Berger: Expect to see the LC process to start on this document to try and drive reviews, early reviews are welcome [draft-ietf-teas-rsvp-egress-protection-04] Status Pavan Beeram: Authors would like to do an internal review and then move to LC. Comment outstanding from last IETFs about adding text to make the document more generic by adding text on segment protection, and also coordination with the document in MPLS WG on egress protection. Huaimo Chen: We will work on the comment on making the draft more generic and address it Lou Berger: That'd be great Huiamo Chen: On the second point: the other draft is a framework which has been introduced much later than this draft. We may put some more text in our draft to reference that. Lou Berger: does the draft in MPLS need updating to align with yours? Huiamo Chen: that draft claims no extension is needed in RSVP-TE for egress protection. I don't think that's true. I had a hallway conversation about this at the last IETF and explained why the extension is valid and necessary. For example: need extension to protect multiple LSPs to the same egress node. Pavan Beeram: Will you suggest changes in the framework document Huimo Chen: I haven't yet. Lou Berger: Please suggest text on the framework on list Huaimo Chen: I can do this and explain why we need an RSVP-TE extension Yimen Shen: I'm the author of the draft intended for MPLS WG. I've had an offline discussion with Huaimo. We will work with Huaimo and come up with text. Pavan Beeram: Thanks for coordinating. We look forward to seeing the outcome. > 2 10:20 (10:22) 20 Title: YANG Data Model for TE Topologies > Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-2.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-2.pptx > Presenter: Xufeng Liu [re: ID type debate: numbers vs URI] Michael Scharf: As an implementor, in case of a very constrained node, the reasons you give for numbers may apply. In the case of case of high end, scalable implementations none of the reasons that you give for numbers make sense and it makes no difference to use numbers vs anything else. Lou Berger: What do you prefer in your implementation? Michael Sharaf: Prefer string or URI. The string is very flexible - you can do anything with it. Numbers seem limited. Pavan Beeram: Do you want to do this for every identifier in the routing domain? Michael Scharf: not for all of them, but for some identifiers across service models will be helpful. My key concern is service models. Anurag Sharma: First, I prefer strings. The TE topology augments the I2RS model, which uses URIs. We need to be consitent across IETF models. Second, in other SDOs they are also using URIs, and it would be difficult to fit everything they have into an integer and move that back to a UID. Third, I agree with Michael and it applies to service model too Igor Bryskin: I don't have a strong preference on strings vs integers. We do not model internals of DB; we model how DB is seen from remote. Numbers vs String doesn't matter; I'll still have to convert the external replresentations to my internal ones. Changes to string will be lot of work. Anurag Sharma: To answer Igor's point, you can model an integer as a string, but not the other way round. Oscar Gonzalez de Dios: I prefer URI. The schema of the URI can be specified so the URI can be fully transparent. We may need to do some work on the URI schemas. Tarek Saad: I agree with Oscar. This has wider applicability, and the decision needs to be coordinated across Yang Models. We need additional data to understand what the URI is. Anurag Sharma: I also agree with Oscar. You can use URI as a face value too; you aren't forced to parse it. Pavan Beeram: You are ok with URI and an additional qualifier Anurag Sharma: Yes. That will put us in sync with other SDOs. [Re: slide 18] Lou Berger: what feedback do you want get from the group? Xufeng Liu: I'd like to see the WG's consensus Lou Berger: it's definitely a complicated question. Some questions to the WG: How many people care which one to use? How many have opinions? Now for feedback, not a consensus poll, how many prefer: Uint 32 URI String Lou Berger: good thing this wasn't a consensus poll. ??? Can we have a question on "non-uint32" (ie string or URI)? Lou Berger: we know that about two thirds prefer non-uint options. Lou Berger: This is useful information and demonstrates that more disucssion is needed on this topic. Please use the list, the informal meetings and if needed the chairs can schedule an interim. [Re: naming discussion] Lou Berger: do the authors have a recommendation? Xufeng: we prefer PSC. Lou Berger: Is that OK? Does anyone find the use of PSC unacceptable? Tarek Saad: Objecting, because it trickles down to other models too. There are other TEAS models that are named with "-MPLS" Adrian Farrel: Better if we use existing terminology, not just here but in the previous document too. Refer to RFC4397 which established terminology for a lot of this. Lou Berger: and what conclusion will that lead us to? Adrian Farrel: nothing, but other documents will lead us to "packet". Lou Berger: This is likely to affect other models in other WGs, e.g. MPLS, so we might want to hear from their Chairs. PSC is well understood in the GMPLS context, but is a bit narrow in context of generic TE. mpls/packet is well-known terminlogy. George Swallow: PSC is too esoteric. The rest of IETF understands packet and MPLS Lou Berger: We have some pushback against "PSC" and towards "packet". Please use packet and see if we recieve any objections > 3 10:40 (10:50) 20 Title: A YANG Data Model for Traffic Engineering Tunnels and Interfaces > Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-3.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-3.pptx > Presenter: Tarek Saad Lou Berger: Have you talked to the YANG doctors? Tarek Saad: We have mailed them, but didn't get conclusive feedback. We should discuss F2F Lou Berger: Will arrange a meeting with YANG doctors after this and get Benoit to help out. Anurag Sharma: In netmod there was a discussion on mounts, and the authors themselves have some reservations about the mounting technique, so it would be a good idea to sync up with them. Lou Berger: Any comments on issues 2 and 3? Dhruv Dhody: For issue #3, clarification question that the ephemeral auto tunnel would be at the device and not at the PCE, where it is config. Igor Bryskin: for issue #2, support the separation of P2P and P2MP. Tarek Saad: Yes Anurag Sharma: RPC is clean, for a clear state; Xufeng Liu: RPC is not a YANG stuff, should be netconf; RPC should not be used to create state, notification do that. Igor Bryskin: agree with Xufeng. If I create a tunnel via RPC then I'll want to see it in telemetry output. There's no point in creating a tunnel and forgetting about it. Adrian Farrel: I have no specific opinion, but I'm wary of creating many ways to do the same thing. From an implemenmtation point of view you then have to track ownership, and who creates what, and who's allowed to delete it. If you're doing it just because you can, then I'd advise you not to; if there's a good reason for it then that's fine. > 5 11:00 (11:08) 10 Title: Extensions to RSVP-TE for LSP Ingress Local Protection > Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-5.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-5.pptx > Presenter: Huaimo Chen John Messenger: (re: slide 5): it looks like you're assuming the failure detection is bidirectional and the underlying transport communicates the CE1-PE1 failure back to the source. Is that a safe assumption for all transport types? George Swallow, off-mic: it's just a matter of time John Messenger: So if you want quick protection, that assumption needs to be met. Lou Berger: We've talked about various mechanisms. This is only for FRR, correct? Huaimo Chen: Yes Lou Berger: Change the title "-for FRR". Wrap it up as soon as you can. We've decided this is experimental, right? So narrowing the scope (to FRR) is okay. What work is left before publishing? Huaimo Chen: we need to add more details for a particular corner-case. Lou Berger: it would be good to wrap this up ASAP so we can begin experiments. Adrian Farrel: How does this work compare with the pseudowire work in PALS. Dont' need to answer the question now, but can you add a pointer to the draft and state why it is different? Huaimo Chen: I think this was asked a long time ago. Lou Berger: Add the answer in the document. > 4 11:10 10 Title: Requirements for Abstraction and Control of TE Networks > Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-4.pdf > Presenter: Young Lee Adrian Farrel: I'd like to offer to help align the terminology with inter-domain TE and PCE based central control. Not a change to the content, just to align terminology. Lou Berger: Thanks Adrian for the offer. We've asked for this in the past, so please do. Young Lee: Should that be done in this document, or in the framework? Lou Berger: anything that helps the WG understand the requirements would be useful, so I think it's a very important step. Young Lee: Adrian, please could you provide a list of the terminology that needs clarifying? Lou Berger: Adrian has offered to work with the authors on this, and he's the WG technical advisor. Adrian Farrel: I'm not looking to change the meaning of the document or slow it down; in fact, I think this will speed things up. All I need to do is read through it and suggest substitutions for some terms. George Swallow: Should be done before last call. Lou Berger: Agreed. > 6 11:20 (11:27) 10 Title: ACTN framework > Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96teas-6.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-6.pptx > Presenter: Daniele Ceccarelli Igor Bryskin: Do you distinguish between access link and inter-domain link. In the TE topology model we do not distinguish. PNC doesn't distinguish either. Daniele Ceccarelli: I think that's an open point that needs to be discussed. I tend to agree with you that there's no difference. Anurag Sharma: Does this framework cover policy? Daniele Ceccarelli: It wasn intended to, but it has been sidelined a bit. Were you asking because you had a proposal? Anurag Sharma: No. Just asking because there's work going on related to policy and it's becoming more important. Daniele Ceccarelli: Yes, adding some text here would be a good idea. George Swallow: if you consider policy in the document, the draft will be too large to handle. My experience is that it's better addressed separately. Dan King: Considering the policy, should be consistent with the requirement document. If there's nothing on it in the requirements document, you don't need it here. Lou Berger: I'd hope policy would show up when we discuss inter-domain, since we generally have policy considerations there. > 7 11:30 11:36 10 Title: ACTN Info Model > Draft: http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-7.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-7.pptx > Presenter: Sergio Belotti Lou Berger: How many have read Lou Berger: Will wait for terminology discussion to happen then look for an update > 8 11:40 11:45 15 Title: ACTN VN Yang > Draft: http://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-8.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-8.pptx > Presenter: Young Lee Igor Bryskin: TE-topology is not just for extracting the physical topology from providers; client can ask for an abstract topology and request that a segment of the physical topology be represented as an abstract node. This machinery exists in TE topology. Young Lee: Yes, you can use the TE topology to determine a view of the topology. Igor: My point is that you also have a way to configure this. Young Lee: this is aimed at the customer interface. Igor Bryskin: Only for CMI model, your model works well for MPI Dieter Beller: I have difficulty in understanding how you can create abstract topology without knowing underlying topology Haomian Zheng: to respond to Igor, the first motivation for this model is to be used by CMI to introduce the VN description. It may have overlap with topology but should not be fully duplicated, will fill the gap if any. Igor Bryskin: You can always take the native topology and then configure abstract topology. We can update the TE topology if something is missing. Lou Berger: We need to find out what is missing from topology model in detail (ie down to which leaf items are missing). We can then figure out whether we need to augment the topology model with this draft, or whether something's missing from the topology model and needs to be added, so this is quite important. Young Lee: the access point and customer endpoint is new Lou Berger: There are policy differences, and we should discuss those in other documents. Young Lee: Yes, we need to clarify this. Igor Bryskin: An important issue is how you control the customer equipment. We have a concept of Tunnel Termination Point and TTP can be given to orchestrator and used there. Young Lee: Yes, but the customer has to give permission for this. Sergio Belotti: The second model of VN needs to be addressed Igor Bryskin: It is already supported in TE topology model Xufeng Liu: Regarding policy, we also plan to add in topology draft. > 9 11:55 12:02 10 Title: The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs > Draft: http://datatracker.ietf.org/doc/draft-zhao-teas-pcecc-use-cases/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-9.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-9.pptx > Presenter: Artsiom Rachitski Jeff Tantsura: How do you envision provisioning flows in the LSP? Artsiom Rachitski: We expect the controller to be provisioning IGPs and well as LSPs, so traffic with go through L2 segments. The devices have L2 rings and are the point of attachment for VPLS. VPLS uses the tunnels, and so VPLS traffic also uses the tunnels. The question is how to load-balance efficiently. Jeff Tantsura: So you'll just recursively resolve the loopback and have the traffic follow the LSP closest to the loop? Artsiom Rachitski: yes. Jeff Tantsura: Do you see a need for more granular provisioning to send traffic across different LSPs? Artsiom Rachitski: yes, there's a need for that. We're expecting tunnels to be built in regard to services required. Dieter Beller: Comment on the draft, the statements that compare signaling-based solutions with distributed system should be removed. Those are valid solutions for some problems. I thought we had agreed to do that. Quintin Zhao: I sent an updated version was sent to Dieter, your response is awaiting. We agree those statement should be removed. Ina Minei: It seems like you're statically configuring label ranges and downloading these from the controller. Artsiom Rachitski: no, we're not statically configuring it. We're calculating the path and uploading the labels Ina Minei: Why not use segment routing? Artsiom Rachitski: it's like discussing whether to use one IGP or another. It's just a different solution. Ina Minei: How are the labels allocated? Artsiom Rachitski: They're allocated by the central controller. Ina Minei: what's the advantage in that? Artsiom Rachitski: SR is just a tunnel built from the ingress; here we can control all devices. Ina Minei: then what difference from previous PCE? Artsiom Rachitski: now we can control on each node, and maintainance TED and LSPDB. Anurag Sharma: are you planning to extend this use-case to multi-layer? Right now this seems to a single-layer Artsiom Rachitski: we may try it. Lou Berger: How many read? How many think it is useful to WG? Lou Berger: As there will be an update soon, WG adoption poll will come after update and discussions on list. > 11 12:05 (12:14) 10 Title: Architecture for Scheduled Use of Resources > Draft: http://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-11.pdf > Presenter: Yan Zhuang Dhruv Dhody: in the solution doc, synchronization between the controllers is mentioned, and should be also included in the architecture draft as well. Yan Zhuang: Confirmed. Lou Berger: Dhruv do you think that should be done before/after WG adoption? Dhruv Dhody: After. Lou Berger: this topic has come up in the IETF many times. When we were working on the distributed control plane we said it didn't belong there. Now that we're looking at more centralized models it seems like a reasonable thing to be looking at. How many have read? How many thinks this function useful? How many thinks this work good foundation? Lou Berger: Clear that there's support in the room. Will move to WG adoption on the list > 10 12:15 (19) 10 Title: PCE in Native IP Network > Draft: http://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/ > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-10.pdf > http://www.ietf.org/proceedings/96/slides/slides-96-teas-10.pptx > Presenter: Aijun Wang Lou Berger: do you see the work as constrained to TE, or broader than that? Aijun Wang: only for TE. Lou Berger: I didn't really get that from the document. How many have read? Lou Berger: we have another path-computation use-case document; think about whether there's common ground there and whether we should have a single use-case document. Lou Berger: Thanks, all. See you in the joint Yang session later today. > Adjourn 12:30 > > Notes taken by: Dhruv Dhody Haomian Zheng Matt Hartley (from recording)