INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.
NOTE TAKERS ADD YOUR NAMES HERE (not required):
> TEAS Agenda For IETF 101
> Version: Mar 15, 2018
>
> Monday, March 19, 2018 (GMT)
> 09:30 - 12:00 - Wdnesday Morning Session I
> Location: Park Suite
>
> Slides: https://datatracker.ietf.org/meeting/101/session/teas
> Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-101-teas?useMonospaceFont=true
> Meetecho: http://www.meetecho.com/ietf101/teas
> Audio stream: http://ietf101streaming.dnsalias.net/ietf/ietf1015.m3u
> Jabber: xmpp:teas@jabber.ietf.org?join
>
> Available post session:
> Recording: https://www.ietf.org/audio/ietf101/
> YouTube: https://www.youtube.com/watch?v=1HfL8jBtnv8
>
> # Start Time Information
> 0 9:30 10 Title: Administrivia & WG Status
> Draft:
> Presenter: Chairs
Loa Andersson: the MPLS WG has not really done an extensive review and discussion on draft-deshmukh-teas-rsvp-rmr-extension-00, the only discussion was about the WG the work belongs to. Same for the LDP one.
Lou Berger: So should we have more discussion here before adoption?
Loa Andersson: I should at least allow for it. I've reviewed the document halfway before sending it to TEAS but that's the only review the document has had so far. It hasn't been through our usual review team.
Lou Berger: The chairs will discuss and get back to the WG (list) on next steps
> 1 9:40 10 Title: WG Draft updates
> Draft: Many
> Presenter: Chairs
Robin Li: regarding draft-ietf-teas-pcecc-use-cases, will progress after a discussion among authors.
> 2 9:50 30 Title: Yang Data Models - TE/RSVP
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-te-14
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-08
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-03
> Presenter: Tarek Saad
Lou Berger: make sure all models should properly indicate references to the RFC defining the function being controlled, particularly when the function is not defined in the base RFC. In the case where there is no good reference, please ensure there is a description adequate for someone less familiar with the function to understand what is being controlled.
Tarek Saad: Good points. We'll take that as an action item.
Lou Berger: We'd like to wrap this work up soon. There has been a move to go through models and make sure that the generic pieces are clearly split from non-generic ones. Please review the documents . As soon as the split is done, the documents will go to early YANG doctor review and then proceed through the process, so now would be a really good time for the WG to review them. We don't anticipate that the technical content will change much at this point.
> 3 10:20 10 Title: TE Topology and Tunnel Modeling for Transport Networks
> Draft: https://tools.ietf.org/html/draft-ietf-teas-te-topo-and-tunnel-modeling-01
> Presenter: Igor Bryskin
Igor Bryskin: I would encourage people to raise more questions for definitions/clarifications. We are also looking for additional use cases that could be added to the document.
Lou Berger: This sort of document is very important for people coming to the topic fresh as there is a lot of complexity in the models as we support a lot of different functions. Please read this document and raise any questions/clafication between the TE-topo model and TE-tunnel model. This document should help with questions relating to the other models and if you have questions, it's likely that others will too. This document is the right place to capture the answers.
Igor Bryskin: We are introducing new concepts in addition to strict inclusion like desirable inclusion and optimization, especially on client-specific optimization criteria which allow the path-computation algorithm to achieve the best possible trade-off between constraints. These things are not conventional and are not part of current PCE. We allow for customized objective functions which are not well defined.
Fatai Zhang: I think this draft is very useful for vendors and operators. In CCAMP we have another similar draft on Transport NBI(draft-ietf-ccamp-transport-nbi-app-statement) which has similar motivations behind it. The authors of these two drafts need more discussion and coordination.
Igor Bryskin: I am participating and providing input to the CCAMP Transport NBI design team and CCAMP members are also active and raising questions on the TEAS TE work so we are coordinating.
Lou Berger: between CCAMP Transport-NBI document and TEAS document (this document), we're relying on authors of the two document coordinate each other so that proper material is in each document. If they decide it's best to combine the documents, we'll work with CCAMP chairs to ensure that our process can support such.
42:00
> 4 10:30 10 Title: Yang model for requesting Path Computation
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-01
> Presenter: Sergio Belotti
Lou Berger: this is another document that it would be good for people to look at and provide comments to the list. If you see areas that you don't think are adequately covered, that's particularly important to mention.
50:30
> 5 10:40 10 Title: ACTN YANG applicability
> Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-yang-01
> Presenter: Daniele Ceccarelli
Lou Berger: there is some disagreement on how to support the CMI, to use the VN yang and service mapping models or existing models (TE topo/tunnel, etc. ) CMI. It would be helpful if we can have others comment on this.
Daniele Ceccarelli: we have made steps forward in the ACTN VN YANG. Dhruv will explain next.
56:50
> 6 10:50 10 Title: ACTN VN YANG
> Draft: https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang-12
> Presenter: Dhruv Dhody
Dieter Beller: we found out that there is another draft in the operations area WG that also addresses virtual netowrks. Are yo uaware of that? There seems to be some commonality. The other draft's title is YANG data model for network virtualization overlay resource management.
Dhruv Dhody: I feel the documents cover differnent things. If I remember correctly that document talked more about network slicing and doesn't cover VNs as we do. But yes, we need to coordinate.
Dieter Beller: that documetn also defines a traffic matrix, connectivity, etc
Dhruv Dhody: I think that sounds more like something a TE topology should handle, so we should check
??Daniele Ceccarelli??: I guess the OPS area draft doesn't deal with traffic engineering, and if it does it's in the wrong WG.
Lou Berger: sounds like a good discussion to have with those chairs and the ADs. I was not aware of it so thanks for pointing it out.
Pavan Beeram: what's the significance of the bandwidth field> Are those the only constraints?
Dhruv Dhody: those are the customer-facing access links, so sometimes they're not part of the TE topology if the TE topology is the provider view of the network. We wanted to make sure that they were present somewhere, but if you think there's a better place for the information we're OK with that. As I understood it it wasn't possible to put this in the TE topology model.
Young Lee: this one is possibly not defined by the TE topology because the access link is only one entity. Here we're talking about an AP so customers need to maintain a bandwidth partition
Pavan Beeram: we'll take it offline - I still have concerns about using it here.
Lou Berger: this is a major update. Reusing mechanisms rather than defining mechanisms is a great step.
How many have looked at this version? A reasonable number
Clearly this is the type of work we should be doing here. How many think this work is a suitable foundation for the WG? About the same as those who have read it
Keep in mind that this an individual document so it's OK for there to be issues when we start working on it.
Does anyone have reservations about adopting this as a WG document? no hands
Thanks for the big step forward. Before we take any action moving the document forward here we will have to talk to the ops area folks to ensure there's no conflict
1:18:30
> 7 11:00 10 Title: ACTN TE Service Mapping
> Draft: https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-06
> Presenter: Young Lee/Guiseppe Fioccola
Parviz Yegani: Is there an overlap between these IETF models and the MEF LSO interfaces?
Young Lee: MEF LSO has LEGATO but not yet data models. MEF is currently working on information model. We can provide the YANG model for MEF if they want to have a liaison with the IETF.
Jeff Tantsura: MEF models are not open to those who are not participating to MEF. I think they'll eventually use IETF models because someone has to write the model.
Pavan Beeram: I think this WG should be working on a generalized service mapping function, but I don't see why it needs to be under the ACTN umbrella, but let's see how the previous document progresses.
Young Lee: this is not under the ACTN umbrella
Pavan Beeram: I think it is at the moment, but let's see how the other document goes and we can revisit this.
Lou Berger: it would be helpful to make it clear that this applies to all TE.
Pavan Beeram: I don't understand the slide with ACTN-VN in a box. I understand how you map onto an ACTN VN but I'd like to see a generic discussion.
Young Lee: OK.
Dhruv Dhody: One source of confusion here is that when we were writing this document we were focusing on CMI where we're seeing the L2SM model and service model being mapped to a single thing. On the device side you may want to bind a VRF to a tunnel and that would be a bit different becasue that mapping is on the device. I think it's good to differentiate between looking at the service model and when we're looking at the network and the device model.
Lou Berger: I think this goes to the disconnect earlier where some see the TE topology as equally applicable as a service model as it is on a device. I think we have a difference of perspectives here that we have to work through. We can have more discussions here but some getting together offline might also be necessary.
Dhruv Dhody: in this model, if we don't want to go via ACTN VN and want to look at the TE topology abstract node nothing will stop you. The difference is that when you're mapping the L3SM that has to be at the higher level. If you have VPN and VRFs we need to work out how to map those to the TE topology
Igor Bryskin: I agree that the service mapping problem has to be solved in a general way. As an example, we have a lot of discussions in the ethernet layer on how to map EPL services and EVPL services onto tunnels as well, and they have the same issues as we have here. I think that TE tunnels and topology should be decoupled from the services. So you have one service model in which a network-wide model like a L3 VPN network is described, and then you have a device-specific model that describes how to map, for example, service on a particular PE to a tunnel. Then you have the tunnel model which is completely separate. Policies are just one part of service mapping, and there are other policies that are not our job to discuss, e.g. connectivity constraints, or how to translate LAN IDs from the customer to LAN IDs in the network. These are very generic issues that need to be discussed separately; it would be good to have some kind of service-independent agnostic model that provides various divisions, e.g. key policies like connectivity. I would strongly suggest we decouple the TE tunnels from the services. We need an infrastructure that can service requests like a L2VPN with a delay constraint so that appropriate TE tunnels can be established to meet this need.
Young Lee: I agree. This is more or less what the L3VPN guys are saying, e.g. they want a service with a specific latency and it has to be deterministic, without any variation of queue delay. Then we can create a TE tunnel and the customer can monitor it in a closed loop through telemetry.
Igor Bryskin: There's duplication of what you specify as a TE policy vs what you specify as key constraints. The customer may specify reliability of a service or diversity of two services and this could be translated into, say, an SRLG to join, but the customer doesn't know what that means or which SRLG to join - he only cares about availablity. We have to have a service mapping to translate this into how tunnels can be set up on the network.
Adrian Farrel: I think Igor nailed it there and the generalization of that statement is that the service model is not aware of the content of the network, and somewhere you need a model that is aware of the content of the network. There may also be a loop where as you stack networks (which is what ACTN is about) the TE tunnel request at one level may become a p2p connection request back down to another network, and then the whole thing reverses.
Young Lee: I think that's exactly why TE service mapping is needed, because the service model doesn't address how TE should be constructed. That's why we need this glue between the two worlds so the customer can have visibility into the underlay and monitoring capabilities in a closed loop.
Jeff Tantsura: So it maps service-level objectives into a physical path through the network
Lou Berger: it sounds like there's an opportunity for some really good input into this document, so please work with the people who made the comments to capture that.
1:38:50
> 8 11:10 10 Title: Use Cases for SF Aware Topology Models
> Draft: https://tools.ietf.org/html/draft-bryskin-teas-use-cases-sf-aware-topo-model-02
> Presenter: Igor Bryskin
Tarek Saad: The way you've modelled the service function is as a property of a node. Can it not be a stand-alone elsement rather than being hosted on a node?
Igor Bryskin: Node here could mean an abstract node that could be e.g., a data center abstracted as node attachement. Node is not necessarily a switch or router.
Fatai Zhang: The examples in this draft all apply to packet networks. Is it applicable to transport networks, such as WSON and OTN?
Igor Bryskin: Yes, we've tried to add use cases to the draft to illustrate this. We have 3R generators as an example for layer 1 or layer 0. There are other examples like OAM capabilities that require hardware support from the OTN network which is not readily available on all devices. These can also be modeled as network functions so that TE tunnels can be routed in the best way.
Fatai Zhang: could you please add into draft
Igor Bryskin: Yes. I think we have six or seven already.
Himanshu Shah: You have SFC with TE constraints. What about the service constraints themselves, e.g. replications and availability of the services? Does that affect the topology?
Igor Bryskin: No. The point is that we're trying to build this model as an augmentation to the TE topology model. This model will provide the identity of the functions in the network as well as constraints on how they could be connected.
Himanshu Shah: but say, for instance, you have a firewall which is utilized 90% and so you only have 10% availability. There could be other places where it's available, so does your topology change based on the service availability or utilization?
Igor Bryskin: This is a good point. We haven't considered service attributes as we hoped that this could come from models like Tosca. It might be an idea to separate connectivity from the actual resources available to a function. We'll consider that.
Parviz Yegani: We're looking into separating the service layer in our information model. The information model includes the service function and the topology graph, and that graph drives the service layer connectivity. There's a separation of the information model from the data model that describes the actual network. have you considered the info model, as SF is different from network model, an info model may be useful than a data model.
Igor Bryskin: we want to decouple service models from topology models but we also want to allow them to be combined to produce this dual optimization. I dont' like very complex yang models; I prefer to have simple ones that can be interrelated. Some clients may be only interested in limited things and may not want to have to handle large and complex models.
Lou Berger: Keep in mind that this is a use-case document, not a solution document, so we have to focus on the use cases first
Jeff Tantsura: there's a difference between network-driven application and application-driven network, and we should look at it from the perspective of a network-driven application.
Lou Berger: we should determine whether the WG wants to work on this type of solution.
how many support to work on this type of solution?
how many think this document is the good place to start?
how many has read this document ?
> 9 11:20 10 Title: SF Aware TE Topology YANG Model
> Draft: https://tools.ietf.org/html/draft-bryskin-teas-sf-aware-topo-model-01
> Presenter: Igor Bryskin
No presentation/combined with previous topic.
2:06:00
> 10 11:30 20 Title: Framework for Traffic Engineering with BIER-TE forwarding
> Draft: https://tools.ietf.org/html/draft-eckert-teas-bier-te-framework-00
> Presenter: Toerless Eckert
Lou Berger: This is early work but well aligned with other work in the working group and there are a lot of common ideas.
How many have looked at this? (reasonable number)
How many who haven't looked at it are interested in learning more? (some)
Seems like there's good alignment and good interest.
2:21:50
> 11 11:50 10 Title: Hierarchy of IP Controllers (HIC)
> Draft: https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-00
> Presenter: Dhruv Dhody
(no comments)
Lou Berger: no joint session this time. Thanks for coming!
> Adjourn 12:00