> Monday, November5th 2018 > 11:20 - 12:20 - Monday MorningSession II > Location: Meeting 2 > > Slides: https://datatracker.ietf.org/meeting/103/session/teas > Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-103-teas?useMonospaceFont=true > Meetecho: http://www.meetecho.com/ietf103/teas > Audio stream: http://ietf103streaming.dnsalias.net/ietf/ietf1038.m3u > Jabber: xmpp:teas@jabber.ietf.org?join > > Available post session: > Recording: https://www.ietf.org/audio/ietf103/ > YouTube: https://www.youtube.com/user/ietf/playlists > Youtube session 1: https://www.youtube.com/watch?v=7as2GwZGpIw > Slot Start Duration Information > 1 11:20 10 Title: Administrivia & WG Status > Draft: > Presenter: Chairs 00:09:55 > 2 11:30 10 Title: WG Draft updates > Draft: Many > Presenter: Chairs Zafar Ali: WRT TE Metric recording - will have issue addressed before IETF 104 Pavan Beeram: could you use some help with this? Zafar Ali: yes, that would be appreciated Lou Berger: How many people are interested in this document? (a few) Any volunteers to help edit? (none) Lou Berger: we're at the point where the authors need to either get this moving again by the next IETF, or we'll declare it dead and move on. Igor Bryskin: WRT tutorial draft, looking for input on packet network example; need volunteers to work on this Tarek Saad: RSVP-TE yang split - should be done shortly, then ready for YANG DR review and LC 00:18:30 > 3 11:40 15 Title: A YANG Data Model for Traffic Engineering Tunnels and Interfaces > Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-te-17 > Presenter: Tarek Saad Igor Bryskin: The comment from the YANG DR is very valid. We don't cover defaults, but do want to cover active choice. We should take the comment seriously. Lou Berger: Authors are following approach of only defining defaults based on specifications, I think this is a good choice Igor Bryskin: my point was that it is better to choose some reasomable option Tarek Saad: the risk is that people may differ on what's a reasonable choice so we need to be careful here. Could maybe have a separate document with defaults? Lou Berger: I thought I heard that the authors' approach was only to have a default when it's specified somewhere in the protocol. Speaking as a contributor, I think that's a wise choice Igor Bryskin: if you do not go to default you need to have multiple choice and create confusion Aihua Guo: In my experience some defaults are necessary, but not all. If a default has interoperability implications should specify something Tarek Saad: yes, I think if there's a default that you feel is important to set then we should discuss on the list Igor Bryskin: A default doesn't preclude a user setting something else if they want Pavan Beeram: Please send a message to the list outlining the changes needed to te-types document to resolve the exising document MISSRef RFC editor state. (Including changes to align te-topology with final definition of te-types.) Lou Berger: where it's necessary to align the topology document with this one, I think it's sufficient to put out a proposal for that and give it to the RFC Editor. I know there were some substantive issues that were discussed off-list and those should be brought to the list and closed 00:35:15 > 4 11:55 10 Title: SF Aware TE Topology YANG Model > Draft: https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-02 > Presenter: Young Lee Lou Berger: There was an issue from the last meeting on identifiers, that is addressed with new -id. Did we talk to SFC about how they handle this? Young: I did, yes. They refer to work in TEAS and NFV. 00:40:15 > 5 12:05 15 Title: Yang model for requesting Path Computation > Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-03 > Presenter: Sergio Belotti Lou Berger: do you want to discuss the open issues now, or on the list? Sergio Belotti: on the list might be better Lou Berger: it would be good to say how you think you should do it now. We have time Igor Bryskin: To ensure the returned path is same as used for the tunnel when it's provisioned, we need to provide all tunnel configuration parameters. The discussion on the list, not much harm to provide everything. Tarek Saad: I agree with Igor. I don't think the fact tht policy isn't there should block progress. The attributes can be passed and the computation server can ignore them if it likes. Provides foundation for future policy module. Sergio Belotti: The problem is that if we need complete alignment on attributes, we'll need some modifications Tarek Saad: I'm proposing that you use the full set and the server can treat them as optional. Pavan Beeram: aren't we just using a grouping for the full set of constraints? Sergio Belotti: we don't have justification for a list of attributes when we don't know what they are Lou Berger: the justification is that a full set of attributes gives maximum flexibility Igor Bryskin: we want to avoid the situation where you ask for a path calculation and get a path, but then provision the tunnel with the same parameters and it takes a different path Italo Busi: that situation is difficult to avoid. If the client provides all attributes you can still get the same problem if the client doesn't provide an attribute that the server is nevertheless using. We're adding a path-verification phase in the next version of the document to try and address these issues. And if you have a policy, you have to explain exactly how it works for it to be useful. It can't be hidden. Sergio Belotti: No, we don't want hidden policies our position is that if the policy is there it has to be explicit. Igor Bryskin: I disagree with Italo. All we're requiring is that if you specify the same parameters for two tunnels, you get identical paths. Secondly, policies don't need to be known externally; they could be proprietary to the server. Lou Berger: there's clearly a difference of opinion here, but I saw there was some new text about path verification in the latest version and I don't think it has really been discussed on the list. It would be good to have the conversation WRT slide 5: Tarek Saad: To clarify the TE tunnel approach: setting multiple constraints is optional. When there are multiple constraints, it's not clear which the server should drop if need be. What does a server prioritize? We went with optimizing the inclusions/exclusions and make it clear that this is best-effort. Igor Bryskin: We need to define what it means to relax a constraint. If you can't satisfy a contstraint you could drop it entirely, or you could treat it more gently. Dhruv Dhody: WRT alignment with PCE, what is the cost of alignment, if cost too high, not worthwhile. We need a smarter way of modeling it. Igor Bryskin: please look at the model, it already has a mechanism that may be sufficient Dhruv Dhody: I like the way PCEP has specified this. I'm confused by what Tarek said about hops - it's like loose vs strict hops. We need to discuss further. Jon Hardwick: Not sure how important this is. The user wants to set their constraints, just need to express same level of richness. To take the example here we're looking at two more-or-less equivalent ways of doing the same thing; PCE can do the same thing - the PCE can return a set of candidate paths to the PCC and allow the PCC to choose the one it likes best. Sergio Belotti: The example is chosen on purpose: not trivial to deduce for implementation in yang the same functionality while for PCEP it is just a Boolean variable to use per constraint Lou Berger: we're over time but I'd like to continue the discussion tomorrow when we resume. > Adjourn 12:20 > > > Tuesday, November 6th 2018 > 16:10 - 18:10 - Tuesday Afternoon Session II > Location: Chitlada 3 > > Slides: https://datatracker.ietf.org/meeting/103/session/teas > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-teas?useMonospaceFont=true > Meetecho: http://www.meetecho.com/ietf103/teas > Audio stream: http://ietf103streaming.dnsalias.net/ietf/ietf1036.m3u > Jabber: xmpp:teas@jabber.ietf.org?join > > Available post session: > Recording: https://www.ietf.org/audio/ietf103/ > YouTube: https://www.youtube.com/user/ietf/playlists > Session 2: https://www.youtube.com/watch?v=A7MJ8NY7kTk > Slot Start Duration Information > 1 16:10 10 Title: Administrivia > Draft: > Presenter: Chairs 00:03:00 > 6 16:20 10 Title: ACTN applicability to YANG models > Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-yang-02 > Presenter: Haomian Zheng Pavan Beeram: this references a bunch of YANG models which are under development so I do not see any need to rush to WG LC, we need the basic models cited in this draft to be mature. Haomian Zheng: Agree on not rushing, but we expect some clarification what is the basic models and how mature we need to wait. Daniele Ceccarelli: here we are defining a huge number of documents, maybe we should define which one can be the showstoppers for the draft without waiting for the all the other drafts. I'd propose TE topology, TE tunnel and Ppath Computation as the three we need. Lou Berger: when this document is published as RFC, which documents we would like to be referenced as RFCs and which one as drafts? Since this is informational it will be published quickly, and all the references that are still drafts will be referenced as drafts. Daniele Ceccarelli: I would like to see those three referenced as RFCs and the rest can be draft. 00:10:20 > 7 16:30 10 Title: ACTN VN YANG > Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-02 > Presenter: Dhruv Dhody Adrian Farrel: there was original argument from the chairs on 'whether we need a separate model than TE', want to confirm whether this issue is addressed or not. I think the presentation explained this quite well - are the Chairs happy? Lou Berger: I think the question is whether the WG is happy. Poll: how many has read this draft (a reasonable number)? How many think the proposed approach is the right way? (same as above) How many thinks this is the wrong way ?(none) Lou Berger: the WG gives the answer. Adrian Farrel: the Chairs expressed that they had a lack of clarity. Have we cleared that up or is more work needed? Lou Berger: The working group has provided the answer -- yes Pavan Beeram: I think the document has gone a long way and thanks for the work and making things clear thank you. Lou Berger: Is the model and the notion of VN something that is ACTN specific or something applicable to any VN node/link control? Isn't it generic and applicable to any TE controller approach? Dhruv Dhody: I think we can use, VN is a general thing, but defined in the context of ACTN. It can be a base, and augment it to achieve other features such as network slicing, but what is the issue with calling it ACTN? Lou Berger: The issue is that the next the model does not read as being generally applicable and that an implementer of VNs who is not using the ACTN model won't think that can use this work. If ACTN term is removed from the model, then they can use it. Dhruv Dhody: if it's just the name space, then yes. Daniele Ceccarelli: ACTN is a structure that you don't necessarily implement everything, you can only implement a piece (like VN), or you can also implement all the pieces and put together, which is ACTN. Lou Berger: we'd like this work to be generally useful whenever we're modeling VN information Igor Bryskin: I agree with Lou, when we're talking about ACTN we're talking about all the building blocks we're building in this group. Anyone can use what they need. So you can use just the topology model if you want. 00:26:00 > 8 16:40 10 Title: Traffic Engineering and Service Mapping Yang Model > Draft: https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-12 > Presenter: Young Lee Lou Berger: it would be great to have a non-ACTN example in the document. How many think it is a topic we should work on? a reasonable number How many have read the document? more than those who think it is a topic we should work on How many think it is a reasonable starting point? a very reasonable number Let's take this to the list. It would be nice if the solution we adopt could be used for more than ACTN. 00:32:15 > 9 16:50 10 Title: YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics > Draft: https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics-08 > Presenter: Young Lee Dieter Beller: we noticed in the model, there are parameters such as delay, delay-variation, packet-loss, etc: are they tech-specific or general? Young Lee: delay is not technology-specific Dieter Beller: delay-variation is packet-only. Should it be defined in a technology-specific augmentation? Young Lee: I agree with packet loss but not with delay Dieter Beller: I was talking about dealy variation Young Lee: what do we have other than packet routers and otn switches, what do we have? Lou Berger: our approach thus far has been to have a base model and then augmentations. That means people implementing only one technology don't have to flag deviations from the base model because they didn't implement all of it. It doesn't make any difference to how the topology works. Gert Grammel: in the last ITU-T meeting there was a presentation about delay variation in OTN caused by asynchronous mapping Young Lee: will this give us trouble with TE types? We just imported that model - do we need to make that more generic? Daniele Ceccarelli: if the issue is to separate packet-specific attributes, we can develop a new module but it is not worth having a separated draft. Let's avoid having a document for only one value Tarek Saad: as the author of ietf-te-types, we need to make sure that our model covers generic performance parameters, and leave the tech-specific parameters augmented to generic TE models. Lou Berger: the comment is about the packet loss attribute being technology-specific, and that's in TE-types We have a YANG Doctor comment about it that needs to be addressed and I think this is worth looking at. Pavan Beeram: I'd to see like some discussion on scaling intent and how that's addressed. Young Lee: you can define this as what happens when you're above or below a certain utilization Pavan Beeram: we should discuss on the list. How many have read the document? A reasonable number How many think it is ready for WG adoption (assuming the comments discussed here are addressed)? A bit less Lou Berger: do the update to the comment (on generic/tech-specific), and then we take it to the list. Young Lee: So what do we do about TE types? Lou Berger: we'll sort that out so it becomes generic. Tarek Saad: the grouping we defined in TE types is generic but maybe doesn't apply to optical. So we could take these out if they're packet-specific Lou Berger: the packet loss is a useful attribute. It does not need to be removed from the te-types document but just been removed from the grouping Pavan Beeram: the TE-types issue isn't the only caveat - also need to make it ACTN-agnostic Lou Berger: We'll swap the next two presentations, first the enhanced VPN framework, then will do ACTN for network slicing. 00:46:40 > 11 17:10 10 Title: A Framework for Enhanced Virtual Private Networks (VPN+) > Draft: https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-02 > Presenter: Jie Dong Ketan Talulikar: Seems this draft defines an architecture. The changes needed are defined in other drafts in SRING, LSR and other areas. What to standardize here? Lou Berger: From process standpoint, this is the right working group for the architecture draft. Stewart Bryant: It is an informational draft, shows how to bring things together to solve a problem. Lou Berger: could you clarify the question? Ketan Talulikar: I'm not asking if this is the WG. My question is: what are we standardizing here? Lou Berger: it's an informational document, so by definition, nothing. Ketan Talulikar: This document generates requirements for standardization in other WGs. Lou Berger: This document informs how different standard mechanisms can be used in a particular way to solve a particular problem. We have many documents that do that. Stewart Bryant: This is absolutely normal. There are many similar documents, e.g. for MPLS-TP and Pseudowires. Lou Berger: It depends on WG's opinion whether there is value to move forward. Zafar Ali: There is a draft in SPRING which has addresses the same space as this draft. Maybe we should bring that draft here as well? Stewart Bryant: My recollection is that this draft is a superset of the draft you mentioned, it is not restricted to SPRING based solution. Zafar Ali: My question is - do you need a superset? This draft looks like marketing, and I think it would be fair to have both drafts discussed. This draft proposes specific ways of doing things that are not needed. We also need SPRING to look at this. Adrian Farrel: I would agree with Zafar if this document were proposing any changes to a technology, but I don't think it does. This document does not define specific extensions to segment routing. It is just one candidate technology, SR and MPLS-TE may both be used. Zafar Ali: I have no objection to the TE side, but for SR, specific SIT types are defined here. Jie Dong: The SR specific extensions are defined in another draft, which will be discussed in SPRING tomorrow morning. Lou Berger: We are happy to have architecture discussion happen in TEAS. Wim Hendricks: One question is about the scale, SPRING was a stateless architecture, we are going to introduce more state. The scale is an important factor and we should clarify this in the document and say which technologies are/are not in scope for a given scale Lou Berger: I've talked to one of the SRPING chairs about this, and we do have some marketing going on. The term SRTE is very confusing, can mean different things to different people. Some people think with TE you do introduce state into devices for resource allocation. Some others think SRTE is purely path steering or "PE" (path-engineering). We really need good definition of SRTE or PE. Zafar Ali: SPRING has an architecture document for SR policies or SRTE. Lou Berger: That's SR policy. There is no definition of SRTE anywhere. We hope we will get one. Zafar Ali: Agree with what Wim said on the scaling analysis, e.g. on the implications of using and adjacency-SID. Lou Berger: We need a definition of SR-TE first. Otherwise it could have different state implications. Daniele Ceccarelli: How about TEAS gives the definition of TE, then if SPRING agrees with it, we can call it SRTE, or they can call it SRPE. Lou Berger: Would be reasonable to have one informational document on what TE is. Can be based on the TE presentation on Sunday given by Adrian and Haomian. Maybe they could turn that into a draft. Robin Li: The framework document is not SR specific thus belong to TEAS. The discussion about SR or SRTE for VPN+ or network slicing could happen in SPRING. 01:08:45 > 10 17:00 10 Title: Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing > Draft: https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-04 > Presenter: Dan King Dan King: Our thought is to move portion of this document into the previous document as a subsection. Then will have a document which we could do liaison to other standards organizations looking at network slicing. Do we need to wait for the composite document be adopted before having formal liaison to other SDOs? Lou Berger: We don't usually do liaison on individual documents (look to Deborah). I don't know if there's a hard and fast rule on this. Deborah Brungard: We could do some liaisons as 3GPP already did liaisons to us showing interest in an area of work. And ITU-T SG-15 have started 5G work, so we could liaison with them to show our work on 5G or network slicing, and ask about the work they are doing now. Lou Berger: If there is value it is certainly something we could do, whether we do it or until we have something adopted? Deborah Brungard: I would do it now. SG-15 is moving fast. The only concern is the data plane technology was FlexE, and that's not the only data plane technology. It would better to make things more general as individual technologies belong to the OIF or ITU. Lou Berger: Maybe we should set up a liaison. Propose some text and we'll work on it. Adrian Farrel: I'm working with the co-authors to do the merge of the three drafts. ACTN will be one of the candidate technologies. There will also clarifications about the terms - we have four terms that are almost the same (VPN, VPN+, Virtual Network and Network Slice), and they seem to be names for the same things depending on where you view it from. The data plane technologies will also be extended from packet focused to other TE technologies. Lou Berger: I want to confirm whether the authors want to do the merge (of this and the previous documents). Jie Dong: As coauthor of VPN+ framework, in support of the merge. Daniele Ceccarelli: VPN+ is something we should work on, but need to be careful about saying VPN+ is network slicing. If we merge everything we lose the distinction. Network slicing is a much bigger problem. Lou Berger: What I heard is VPN+ solves part of the problem of network slicing. Stewart Bryant: It was originally intended to solve the data plane and lower layers. Network Slicing is a much bigger problem. We didn't use the term network slicing in beginning because we want this to be universally useful, and applicable to some aspects of network slicing - and also because Netowrk Slicing was a very controversial term when we started the work. Young Lee: As coauthor of the 2 ACTN drafts, support the merge as long as we clarify what VPN+/network slicing mean. Could clarify our scope is transport or TE network slicing. Lou Berger: We are running over time so we need to wrap the discussion. The plan is to merge the documents. And that's gonna be pretty quick. Who is interested in working on this topic in this working group? Very healthy number. Lou Berger: We'll need to see the merged document, but given the level of interest and discussion we'd like to not wait for the next meeting to do a poll. Zafar Ali: There is another draft, WG also need to see it. Lou Berger: After adoption there is opportunity to bring your content into this document, and the ownership moves from the authors to the WG. Zafar Ali: Would like to work with the authors of the draft, even before the WG adoption poll. Dan King: we'd be happy to work with you. 01:24:20 > 12 17:20 10 Title: Interworking of GMPLS Control and Centralized Controller System > Draft: https://tools.ietf.org/html/draft-zheng-teas-gmpls-controller-inter-work-01 > Presenter: Sergio Belotti Sergio Belotti: The draft was presented in CCAMP last time but was considered technology-agnostic so it is now presented in TEAS. Lou Berger: is it proposed as an Informational document or as a Standard Track document? Sergio Belotti: it is Informational Lou Berger: How many have read the document: an ok number How many think we should work on this: the same How many think it is ready for adoption: a bit less How many think we need to wait for the changes? none There is support but not overwhelming. We will discuss offline the next steps 01:32:40 > 13 17:30 10 Title: Hierarchy of IP Controllers (HIC) > Draft: https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-01 > Presenter: Dhruv Dhody Pavan Beeram: Is the scope of this limited to ACTN, or are we going beyond packet networks? Dhruv Dhody: this work include the BGP which is not a part of ACTN; Adrian Farrel: Is it possible to generalize this as a controller-driven document? i.e. something that covers the material in the previous draft? Dhruv Dhody: open to discussion. Lou Berger: How many are interested to this topic (even if they have not read the document)? A reasonable number Lou Berger: it would be good to follow up on Adrian's suggestion 01:38:40 > 14 17:40 10 Title: Basic YANG Model for Steering Client Services To Server Tunnels > Draft: https://tools.ietf.org/html/draft-bryskin-teas-service-tunnel-steering-model-00 > Presenter: Igor Bryskin Daniele Ceccarelli: I like the idea of pools but I would like to see pools made by a single tunnel, i.e. specify that a particular tunnel is to be used Igor Bryskin: you have the option to reference a tunnel or a pool Italo Busi: I agree with Igor. It's better to reference the tunnel or the pool, rather than have to create a pool with one tunnel Daniele Ceccarelli: that's ok, I just need to have the possibility to specify a specific tunnel Lou Berger: we have to cut the discussion here. I think the conversation demonstrates that there's interest in this. 01:45:20 > 15 17:50 10 Title: Applicability of ACTN to VPN with POI > Draft: https://tools.ietf.org/html/draft-lee-teas-actn-vpn-poi-00 > Presenter: Daniele Ceccarelli Lou Berger: How many thnk this is useful work? (a few) How many think we shouldn't be talking about this in the WG? (none) Please discuss more on the list 1:53:20 > 16 18:00 10 Title: GMPLS Signaling Extensions for Shared Mesh Protection > Draft: https://tools.ietf.org/html/draft-he-teas-gmpls-signaling-smp-00 > Presenter: Italo Busi Pavan Beeram: There are three protection C-types. Need to clarify which we're changing. Italo Busi: second one Pavan Beeram: We currently don't have any IANA registry for the flags. We may want to consider one. Dieter Beller: the draft mentions shared-mesh protection, which is similar to shared-msh restoration. But protection is done by the data plane, whereas restoration is done in the control plane. How do the two coexist? Both use shared resources in the network. Italo Busi: I would not expect that SMP and SMR would be in the same network, but if they were I would expect them to share resources. Igor Bryskin: What's the environment for this? Do you envision a multi-vendor GMPLS network? Italo Busi: the requirement is to set up a working LSP and a protecting LSP. The transit nodes need to know that the protecting LSP belongs to an SMP schema rather than SMR or linear protection. Igor Bryskin: But is it a single- or multi-vendor environment? Italo Busi: at the moment I don't expect multi-vendor as there is no common APS signaling. Igor Bryskin: So why are we discussing this? Lou Berger: How many are interested in this? A small number How many have read the document? More Chairs will discuss. See you all at the next meeting. > Adjourn 18:10 > Notes by: Italo Busi Haomian Zheng Matt Hartley