Re: [Teas] raw notes from session

["Matt Hartley (mhartley)" <[e-mail]>]

All,

Many thinks to the people who took notes during the meeting in Singapore. 

I've been through the recording and updated the notes in etherpad (http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teas, also pasted below). I'll publish these as minutes in a couple of days if there's no further comments/objections.

Cheers

Matt

                        TEAS Agenda -- IETF 100
>                          Version: Oct 31, 2017
>         Tuesday November 14th 2017
>         09:30 - 12:00 - Tuesday Morning Session I
>         Room: Canning
> 
>         Slides: https://datatracker.ietf.org/meeting/100/materials#teas
>         Etherpad:       http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teas?useMonospaceFont=true
>         Meetecho:       http://www.meetecho.com/ietf100/teas
>         Audio stream:
>         Jabber: xmpp:[e-mail]?join
> 
>         Available post session:
>         Recording:      https://www.ietf.org/audio/ietf100/ietf100-canning-20171114-0930.mp3
>         YouTube:        https://www.youtube.com/watch?v=CeQdMtuWpPk

> #  Start Time Information
> 0  9:30  10    Title:  Administrivia & WG Status
>                Draft:
>                Presenter:      Chairs

Lou Berger: please use the list for discussions. If draft authors discuss changes amongst themselves and publish a new version then it still needs to be discussed on the list. However, if discussion on the list results in changes, then that can be considered WG consensus.

> 1  9:40  5     Title:  WG Draft updates
>                Draft:  Many
>                Presenter:      Chairs

Pavan Beeram: We didn't receive an update from the pcecc-use-case draft. Would be useful if the authors can get an update sent to the list.
Authors of the te-metric-recording draft still need to address/discuss the comments sent out mid-last-year.

> 2  9:45  5     Title:  Post pub request update:  draft-ietf-teas-network-assigned-upstream-label
>                Draft:  https://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label
>                Presenter:      Vishnu Pavan Beeram

Lou Berger: there were no technical changes since the last revision, right?
Pavan Beeram: No
Lou Berger: generally we do not do an additional LC if there are no technical changes post-LC so we can proceed without a second LC

> 3  9:50  5     Title:  Post pub request update: draft-ietf-teas-rsvp-te-scaling-rec
>                Draft:  https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec
>                Presenter:      Vishnu Pavan Beeram
<no comments>

> 4  9:55  10    Title:  Post pub request update: draft-ietf-teas-lsp-diversity
>                Draft:  https://tools.ietf.org/html/draft-ietf-teas-lsp-diversity
>                Presenter:      Dieter Beller
<no comments>

> 5  10:05 10    Title:  LC Update: draft-ietf-teas-yang-te-topo
> 9:46           Draft:  https://tools.ietf.org/html/html/draft-ietf-teas-yang-te-topo
>                Presenter:      Xufeng Liu

Lou Berger: Poll: how many have read the latest version?
 - A good number
How many are planning to augment this model (e.g. in CCAMP)? 
 - Also a good number
If you're working on an augmentation please rlease review the guidelines on augmentation guidance in the latest version and send feedback to the list in the next two weeks.  Would like feedback before submitting for publication in ~2 weeks. Positive feedback is also very useful.

> 6  10:15 15    Title:  RSVP/TE YANG Models Update
>                Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp
>                https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te
>                https://tools.ietf.org/html/draft-ietf-teas-yang-te
>                Presenter:      Rakesh Gandhi

Lou Berger: I sent a message to the list commenting on the need for referencing RFCs that define the feature being configured, can you comment on this? 
Rakesh Gandhi: We have references in some places, but not all.  We agree to go and add missing references to the docuement. 
Lou Berger: it's really good to have references to where the original features were defined so that everyone understands what is intended.
Lou Berger: there are three pieces to the yang-te draft, general, RSVP-TE and MPLS-TE, does it make sense to split in three different documents? Generally we try not to put separate technologies into the same document. I'm talking about splitting the document into three WG documents and moving quickly to WGLC, not restarting the entire process.
Rakesh Gandhi: we did that for RSVP we had two and now we have three, we can split as needed.
Lou Berger: it would be good to hear from the WG.
Poll: How many think it is better to split generic and technology-specific part?
 -  A reasonable number.
How many want to keep it as it is?
 - None.
Sounds like we shoudl split the documents and submit the new ones as WG drafts
Rakesh Gandhi: OK
Xufeng Liu: what about te-types? 
Lou Berger: it's generic. Is there any reason why we shouldn't keep it in the generic documents?
Xufeng Liu: The te-types will be shared by topology and tunnel models. Ok to keep the te-types in the same document

> 7  10:30 10    Title:  ACTN Info model
>                Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-info-model
>                Presenter:      Sergio Belotti

Lou Berger: we are going to check that all the IPR declarations are there and then we can issue a WG LC on this draft together with the requirements and framework draft

> 8  10:40 5     Title:  ACTN YANG applicability
>    10:13       Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-yang
>                Presenter:      Haomian Zheng

Michael Scharf: On slide 3, there is some confusion between the L1CSM and the VN Member. The draft doesn't well define how they relate to each other and whether they overlap.
Haomian Zheng: VN model provide a high-level description on how the virtual network is described. While L1CSM is used to support the L1VPN service. 
Michael Scharf: We need a clear defintion of the differences so that a CMI user can understand how to establish different service types. Especially for layer 1 we need a precise definition of what the difference is and why we need two different things, and how the customer would use this, e.g. how to set up a VN member, how to set up a L1 member, etc. The document doesn't explain these concepts well.
Haomian Zheng: OK - well discuss more offline and update the docment.
Lou Berger: How does the service model in this draft related with the transport-service model that presented a few meetings ago? 
Haomian Zheng: That model (transport service) is to describe the client-server relationship in multi-layer network, which applies on MPI. The current service model is used on CMI, which is different. 
Jeff Tantsura: Don't be fixated with a specific transport protocol (NETCONF/RESTCONF), gRPC is another option; focus only on the YANG models.
LouBerger: the draft should only mention the YANG model and say nothing about how they are transported.

> 9  10:45 10    Title:  ACTN VN YANG
>                Draft:  https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang
>                Presenter:      Dhruv Dhody

Igor Bryskin: what you describe is exactly what TE Topology can do it right now. The customer can configure and view an abstract topology that has nothing to do with the native topology.
Dhruv Dhody: TE Topology and Tunnel model are required to provide the attributes that network element and SDN controller needs, but not to show to the customer. In the IETF we've found it helpful in the past to have separate models for the customer view and the provider network. In theory it is possible to use TE Topology but using VN allows specifying the policies and let the MDSC to further translate rather than having the customer to configure all the detailed attributes. So, for example. you can set up a policy to optimize links for for delay and all the details of how that's actually done are hidden from the customer. The customer view comes from the CMI and is the job of the MDSC to translate that into the real provider network. So we need to decide whether we want to do everything with the same model or whether we want a customer-facing model that only deals with the things that customers care about.
Igor Bryskin: So what can't be done with the topology? In our view, it is different layer of abstractions but it is the same topology.
Dhruv Dhody: The example I gave for link optimization is one. We reuse the abtract topology model where we can, but having a VN model as an entity towards the customer helps. We also want to ask if having the same model at all layers meeting requirements for device, network as well as service and exposing all these details towards the customer is a good idea? 
Lou Berger: generally in this group we try to re-use the solutions that we already have and to define things in a generic way so they can be used in multiple layers. We are trying to use the same models. There may be some missing attributes. We need to understand what it is missing before deciding whether we wish to define new models or augmenting the existing models. This was one of the changes I requested in the Framework document
Micheal Scharf: I want to back what has already been said regarding applicablility of TE topology and tunnel models. It's not clear to me why a new model is needed. Bear in mind also that the relationship between the MDSC and the PNC could be a business relationship or it could be an internal interface within the same organization, and the attributes you expose between layers could be different in each case. I think you'll need a lot of the attributes in the TEAS models in the VN models too. Applying a policy to a set of tunnels is also something we don't need to solve here.
Dhruv: I agree, but we are considering the case where a business relationship exists
Michael Scharf: But that's just one case. The Framework document has a clear use case where the relationship is not external.
Dhruv Dhody: I agree. Since this model refers to the topology mmodel it abstracts things, and if you want more details the reference is there so you can go to the topology or tunnel model and find those details. But we don't think the fact that abstraction isn't always required means it shouldn't be available.
Young Lee: the VN concept is needed to  express customer's demand, but we don't want to reinvent the wheel so we re-use many things from the tunnel and topology models
Lou Berger: there is no disagreement that the VN concept is useful, but the disagreement is on how to realize the VN concept
Young Lee: To answer Michael's question, customers don't care about diversity becasue they have SLAs. They may have requirements on delay, etc but they don't need that at the VN level.
Micheal Scharf: I disagree on that. In a use case I have, diversity is needed so we need to add diversity to the CMI. If we can't have that, why are we doing traffic engineering?
Young Lee: we aren't doing traffic engineering for the customer - the SLA takes care of that.
Lou Berger: I think this highlights the range of requirements customers may have. In my experience in transport networks being able to tell the customer that you're using a diverse path is important and if we presented an interface that didn't include that they'd never use it. But that's just one use case, and in others the customer may not want that.
Young Lee: our main case is where CMI is the demarcation between the network and the customer
Lou Berger: I'm thinking of an external customer. I think it would be worthwhile the authors to take the TE Topology model and see how it can be augmented and what leaf in the TE Topology is not needed and can be marked as optional. YANG provides the ability to not use everything that is in the model.
Dhruv Dhody: one thing we found is that a simple TE topology is pretty straightforward, but what we do in type 2 VNs with full-mesh, hub-and-spoke, etc is very messy in the TE topology. Who talk to whom and what are the properties of objects. It's easy to ask for bandwidth on a link; it's not possible to ask to optimize the whole network for delay. That's why we felt it was better to start a new model, but we can go through the TE model and see what's needed.
Pavan Beeram: that would be very useful. I don't think anything mentioned so far is hard to do with the topology model, but working out where the topology model is lacking would be useful.
Daniele Ceccarelli: the problem is not what is missing but what is too much. The customers who just provide connectivity between endpoints do not want to know anything about tunnels and topology but just being able to request connectivity between two points without caring about multiple domains or multiple technologies. The VN is intended to cover this simple case.
Lou Berger: There are different cases and we wish a solution that can cover a range of use cases and we have to figure out the right way to do that.
Daniele Ceccarelli: in many cases, if you tell a customer to deal with a topology they won't want to.
Lou Berger: you could use the topology model but only supply endpoints; I think that's the solution Pavan suggested earlier
Igor Bryskin: optimizing an abstract topology can often be a single attribute as you're only optimizing for one thing. A single-node or mesh topology is also very simple. When people say it's too messy to do with the TE topology, I'd like to see what exactly is messy.
Dhruv Dhody: I think this an exercise for the authors - we'll take it offline.
Lou Berger: You also need to address Daniele's point - is there too much that's always required and could be optional or a feature-set. Pay really close attention to nodes that are mandatory and those that aren't.
Jeff Tantsura: for customers, what matters is the ability to express constraints. Physical diversity is a business requirement and when I was a customer I would ask for cable layouts. So you absolutely must have the ability to express this, but it doesn't have to be mandatory. Most people will work at the level of SLAs but the details need to be there for those who need them.
Dhruv Dhody: it's there, but not at the per-tunnel level. What we do is say that all members must be diverse for the whole VN so we have redundancy. We can do this via the TE topology model, but is it too complicated? e.g. if I have a full mesh and make a change, I have no way to say I'm making a change to the VN as a whole; it has to be on each tunnel.
Jeff Tantsura: it's about the ability to express what you need.
Dieter Beller: for VN Type 2, I do not understand why the TE Topology model cannot be used because these use cases were considered when developing the TE Topology model. We were specifically looking at this when we developed the TE topology model.
Dhruv Dhody: yes, we used the TE topology and referenced it. We are maintaining per-VN data like policies in this model. We also include operational data as well as configuration, so I can use this model to see how the VN as a whole is functioning without looking at each tunnel, link, etc individually.
Lou Berger: so there's some homework for the authors before we discuss WG adoption.

> 10 10:55 10    Title:  ACTN telemetry
>    10:59       Draft:  https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics
>                Presenter:      Young Lee

Micheal Scharf: two questions. First, this model contains technology-specific attributes (e.g., packet loss). Need to think about how to deal with different technologies and how to model it, e.g., defining different augmentations and it isn't clear how you do that. Second, scaling policies can be complex and include e.g. also business logic. Do we really want to encode this in such a YANG model? And what about policies beyond scaling?
Young Lee:  We thought packet loss was generic, but TDM may think about BER. It could be augmented in CCAMP. On scaling, I agree that isn't really telemetry. We could take it out and put it in a separate model if people think it's useful.
Lou Berger: where you're augmenting the TE topology with things that are truly generic then it would be good to get them in the TE model before we close it. Could you send them to the list soon so they can be discussed and we can work out whether we should bring it in?
Pavan Beeram: some of the attributes you are augmenting from the TE Tunnel are already there in the base model.
Young Lee: I think the TE model has more link statistics than tunnel statistics
Pavan Beeram: there's per-link statistics in the topology model, and then some statistics for the tunnel as a whole.
Young: the tunnel is per-domain? We're talking about C-to-C tunnel
Lou Berger: we're running short of time, so we should take this to the list
Jeff Tantsura: usability: you can want to compare your operational state with your intended state, and we recently published a draft with a compare operation for this based on filters. That would be useful here.

> 11 11:05 10    Title:  ACTN TE Service Mapping
>    11:11       Draft:  https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang
>                Presenter:      Daniele Ceccarelli

Michael Scharf: these examples are too simple and unrealistic, please add more realistic use cases in order to explain what you want to map to (e.g., when talking about L3VPN, an actual topology with PE, P, and ASBR routers, tunnels, etc.). An optical network may be an underlay of the IP network. And there's contradictions between this and the framework document.
Daniele Ceccarelli: these are not the latest slides, the latest version should make you happier
Michael Scharf: same comment applies to the latest slides in datatracker.
Lou Berger: are your comments to the slides or to the draft?
Michael Scharf: Both. The draft has less than the slides. We could do with an example L3VPN over two ASs. 
Lou Berger: we're running short of time but it would be great if you could get together this week to discuss what's missing.

> 12 11:15 10    Title:  TE Topology and Tunnel Modeling for Transport Networks
>    11:20       Draft:  https://tools.ietf.org/html/draft-bryskin-teas-te-topo-and-tunnel-modeling
>                Presenter:      Igor Bryskin

Lou Berger: (Poll) How many think it is a useful work for the WG? A good number
How many have read the document? Also a good number
How many think this is a good foundation? Also a good number

We'll take this to the list

> 13 11:25 15    Title:  Consideration for applying PCE in native IP network
>                Draft:  https://tools.ietf.org/html/draft-wang-teas-ccdr
>                https://tools.ietf.org/html/draft-wang-teas-pce-native-ip
>                https://tools.ietf.org/html/draft-wang-pce-pcep-extension-native-ip
>                Presenter:      Aijun Wang

Adrian Farrel: Can you confirm that you are not doing anything special in the forwarding plane that isn't already achieved today using CLI to install static routes. In other words, your proposal is about introducing a central controller and standardardised southbound protocol, and not any change to how the network works.
Aijun Wang: Yes. We don't want to change the network.
Lou Berger: Poll: How many are interested TEAS WG to work on TE for IP network, independently of this or another solution? A few people, more than I expected
If we say to do this an experimental work and provide a home to foster this, how many would be interested? (asking for those who have raised the hands before, not to raise again):
Jeff Tantsura: if there's interest, we should give it a change
Lou Berger: we'll take this to the list towards an adoption call as experimental. That covers the first document, and the last is definitely PCE. I'd like to hear from the PCE Chair on where they think the second document should be.
Jon Hardwick (as PCE chair): This was discussed in PCE a couple of meetings ago. I wanted this to come to TEAS because I wanted some guidance on whether this is a problem we all want to be working on, and an adoption poll in TEAS would answer this. I don't think we're ready to adopt solution work in PCE yet.

> 14 11:40 10    Title:  Use Cases for SF Aware Topology Models
>                Draft:  https://tools.ietf.org/html/draft-bryskin-teas-use-cases-sf-aware-topo-model
>                Presenter:      Igor Bryskin

Dhruv Dhody: Is this model useful with VxLAN? Is this model only for when the underlay is a TE tunnel?
igor Bryskin: we don't want to narrow down to TE tunnels - it could be any other tunnel. The point is that it doesn't matter where the service functions are in the topology.
Dhruv Dhody: if I have a choice between the same service function being available in multiple places, I can make a good decision on which service functions I should choose.
Igor Bryskin: I agree

> 15 11:50 10    Title:  SF Aware TE Topology YANG Model
>                Draft:  https://tools.ietf.org/html/draft-bryskin-teas-sf-aware-topo-model
>                Presenter:      Igor Bryskin

Lou Berger: Interesting work - we'd definitely like feedback on the list.

Lou Berger: something I forgot earlier: there's no joint yang session this time. I'd like to get feedback from the WG on whether that's a good or bad thing and we'd love to hear from you.
Himanshu Shah: we asked for LC on our associated co-routed FRR draft and it hasn't been mentioned. What's the status?
Pavan Beeram: it was updated yesterday, so we'd like to see it discussed on the list.

> Adjourn         12:00

> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Wednesday, November 15, 2017 5:56 PM
> To: [e-mail]
> Subject: [Teas] raw notes from session
> 
> Hi,
> 	As usual, notes from our session are available in etherpad:
> http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teas
> 
> Please review and made additions/corrections based on what took place in
> the session (comments should be sent to the list.)  To aid in the review,
> please see:
> 
> Recording:
> https://www.ietf.org/audio/ietf100/ietf100-canning-20171114-0930.mp3
> YouTube:
> https://www.youtube.com/watch?v=CeQdMtuWpPk&index=51&list=PLC86T-
> 6ZTP5g_hEODKiZDeZTpr2Vxd2B3
> 
> Thank you!
> Lou (Pavan and Matt)
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas