Subject: Re: [Teas] rough notes from today's session

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 17 Apr 2017 15:22:01 +0000

All,

I've gone over the recording and updated the minutes. Please edit at http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-teas?useMonospaceFont=true if there's any other changes to be made.

I'll publish them as official draft minutes in a couple of days.

Cheers

Matt

INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.
Please feel free to add your name at the end if you want to be acknowledged in the formal minutes.  

> TEAS Agenda For IETF 98
> Version: Mar 23, 2017
> 
> Session 1
> Monday March 27th 2017
> 09:00 - 11:30 - Monday Morning Session I
> Room: Vevey 1/2
> 
> Session 2: Joint with MPLS, PCE, CCAMP
> FRIDAY, March 31, 2017
> 0900-1130  Morning Session I
> Zurich D
> https://datatracker.ietf.org/meeting/98/agenda/mpls/
> 
> Etherpad:       http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-teas?useMonospaceFont=true
> Meetecho:       http://www.meetecho.com/ietf98/teas
> Audio stream:   http://ietf98streaming.dnsalias.net/ietf/ietf982.m3u
> Jabber: xmpp:[email-masked]?join
>         
>         Available post session:
> Recording:      https://www.ietf.org/audio/ietf98/
> YouTube:        https://www.youtube.com/user/ietf/playlists
> 
>             Session 1
> Num  Start Duration    Information    
> 0    9:00  10    Title:    Administrivia & WG Status
>                  Draft:    n/a
>                  Presenter:    Chairs

Lou Berger: Agenda change - presentation 8 will go before 6

> 1    9:10  15    Title:    WG Draft updates
>                  Draft:    Many
>                  Presenter:    Chairs

Julien Meuric (PCE Chair hat on): (on draft-ietf-teas-scheduled-resources) There has been talk of merging this with a draft in PCE WG. We're meeting this afternoon and we hope to discuss and move our draft forward
Lou Berger: What do you think about the TEAS document? Should we hold it up until you've decided on a direction in PCE WG? Are you not worried about it? We don't want this document to sit forever, but we don't want to publish something out of line with what PCE WG is doing.
Julien Meuric: I don't see any need to hold anything back and we don't mind which document comes first, as long as we're going in the same direction. But we should avoid divergence.
Lou Berger: our inclination is to go first.
Lou Berger (on draft-ietf-teas-te-metric-recording): the current authors don't seem to be doing anything on this draft. If anyone's interested in taking it forward please get in touch with the Chairs.

> 2    9:25  20    Title:    Yang Data Model for TE Topologies
>                  Draft:    https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo
>                  Presenter:    Xufeng Liu

Michael Scharf: Model is complex to implement, particularly from the single layer perspective.  Would be worth defining what is needed for single-layer, i.e. can you provide direction for the simple case. Second: what's the use case for the statistics in there?
Xufeng Liu: can we discuss this on the list?
Michael Scharf: I'm not asking to change the model, but to say what subset needs to be implemented for different use cases
Lou Berger: maybe put that in an appendix? It's probably worthwhile if it helps people implement a simple case. But could also be a separate document if the authors prefer.
Greg ???: Sometimes a TE tunnels goes over two optical networks in an underlay, which connect on blind ports. How is that modeled?
Xufeng Liu: we do have that in the draft in the inter-doman access. 
Fatai Zhang: this draft is foundational, please publish as soon as possible. People are waiting on it to implement it and build other models.
Igor Bryskin: We have a tutorial that includes tunnel model as well -- we publish seperately 
Lou Berger: what do you think will happen with I2RS?
Xufeng Liu: we'll move forward one way or another.
Lou: how do we handle a revised data source?
Xufeng Liu: This affects many models, will discuss in Routing WG and get a common approach for the routing area.
Sue Hares (with I2RS hat): what would you like to have happen with the I2RS topology?
Xufeng Liu: approach similar to ours (option 2 or 3)
Lou Berger: please show up to the Routing WG discussion if you're interested in that.
Gert Grammel: In the previous topo model you had a transitional link to get from one layer to another, which is similar to MPLS. Will you keep it for MPLS LSPs?
Igor Bryskin: label and transitional links aren't the same. Transitional link is a TE construct and is used for e.g. path computation. Label is data-plane. So you can calculate a path using transitional links and use labels when the path is set up.
Gert Grammel: I'm looking at it from a dataplane perspective
Lou Berger: it's a good discussion, but one we should have on the list.
Lou Berger: there's two other docs that have been split out from this: one for the L3 topology representation and one for the SR topology representation. Questions for the room: 
    How many think that we should work on both?
    Are you intereested in working on these drafts?
    Should we work on the L3 draft in the WG? a reasonable number
    How many have read this draft? not many
I wanted to get to support for adoption for these. Will have to discuss on list
Igor Bryskin: Do we need these combined models? We should discuss on the list.

> 3    9:45  20    Title:    A YANG Data Model for Traffic Engineering Tunnels and Interfaces
>                            A YANG Data Model for Resource Reservation Protocol
>                            A YANG Data Model for RSVP-TE
>                  Draft:    https:/tools.ietf.org/html/draft-ietf-teas-yang-te
>                            https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp
>                            https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te
>                  Presenter:    Tarek Saad

Lou Berger: you mentioned some things that are not covered in the standards but are supported by most vendors. It's good to note these, but should these be features or not?
Tarek Saad: we've discussed this, and are generally using features when something isn't supported by all vendors who are involved
Lou Berger: You can always revist if you get pushback during WGLC. Also bear in mind which things are dataplane-specific, e.g. auto-bandwidth isn't. Please revisit the modules to ensure that technology specific parts aren't in the generic model and the reverse.

Dhruv Dhody: Can you clarify the semantics of bandwidth-type?
Tarek Saad: static type is used if the bandwidth is explicitly set; dynamic type is used to indicate auto-bandwidth functionality.

> 4    10:05  10   Title:    ACTN Framework and Requirements
>                  Draft:    https://tools.ietf.org/html/draft-ietf-teas-actn-framework
>                            https://tools.ietf.org/html/draft-ietf-teas-actn-requirements
>                  Presenter:    Daniele Ceccarelli

Michael Scharf: the document seems a bit dated, it sems it needs an update to reflect recent developments and state of industry in 2017, e.g., requirements have not kept pace with framework.  Also not clear what all interfaces are all about, e.g., MMI
Young Lee: MMI is a special case of MPI so no need for specific requirements. We can add specifics for MPI and MMI in the requirements
Michael Scharf: it isn't clear what CMI is about.
Igor Bryskin: I agree that policy framework is important. What are the next steps with policies? Which WG will the work be in? Will we develop languages for them?
Daniele Ceccarelli: we need to put together a collection of the work we have and work out what's missing.
Lou Berger: Super WG has been contacting people to see if their work is relevant to policy work that other folks are doing.
Young Lee: we can add MPI and MMI to the requirements doc.
Lou Berger: it is not clear where the requirements apply. Are they requirements on operators using the solution, or on developers to provide the tools to operators?
Lou Berger: I see this as multi-domain orchestration. I am proposing to take the text from the mapping draft into the framework draft to help people understanding the ACTN terminology. We need to help people understand how the terms in this document relate to the terms they already understand.

> 5    10:15  10   Title:    Applicability of YANG models for ACTN 
>                            ACTN Abstraction Methods
>                  Draft:    https://tools.ietf.org/html/draft-zhang-teas-actn-yang
>                            https://tools.ietf.org/html/draft-lee-teas-actn-abstraction
>                  Presenter:    Daniele Ceccarelli / Haomian Zheng

ACTN Abstraction Methods (Daniele)
Igor Bryskin: How does the white topology help with proprietary extensions?
Daniele Ceccarelli: Do not make it white. Unless you have an MDSC that understands the proprietary extensions, you are suggested not to use white topology and go for grey topology
Igor Bryskin: so greay topologies are more useful than either black nor white topologies?
Daniele Ceccarelli: yes, but we need to define black and white in order to explain grey.
Lou Berger: after you've moved text to the framework document, will anything be left in this one?
Young Lee: there's still stuff that is useful in here.
Lou: if you aren't using the whole of this document to the framework document, it'd be good if you sent a mail to the list to say which bits are moving. A complete merge is also OK.

Applicability of YANG models for ACTN (Haomian)
Michael Scharf: for CMI technology-specific attributes, isn't there overlap with other WGs? Many other WGs define virtual networks. Why don't you address that here? And why do we need new yang models here?

> 8    10:25  10   Title:    Traffic Engineering and Service Mapping Yang Model
>                  Draft:    https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang
>                  Presenter:    Dhruv Dhody

Igor Bryskin: This is too simple, there is no 1:1 mapping between L3SM and TE Tunnel. The only way to do the mapping is via versatile policy models
Dhruv Dhody: we have a map-type which is not yet an exhaustive list but new modes can be added to address this use case. Nobody's saying policy shouldn't be there.
Michael Scharf: Not clear on the use case. The mapping for L3SM to TE tunnel can be more complex, expecially with multi-AS case. Why this mapping cannot be internal and needs a YANG model?
Dhruv Dhody: need to visualize which TE Tunnel is used for an L3SM, e.g., to monitor it
Michael Scharf: With multiple-AS we need to envision if we have one or multiple MDCS which impacts the whole ACTN architecture

> 6    10:35  10   Title:    A Yang Data Model for ACTN VN Operation
>                  Draft:    https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang
>                  Presenter:    Dhruv Dhody

Igor Bryskin: what is the difference between VN model and TE abstract topology model. Abstract topology can address all these things
Lou Berger: please have a discussion on the list about this comment before the next meeting

> 7    10:45  10   Title:    YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics
>  (real :49)      Draft:    https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics
>                  Presenter:    Young Lee

Michael Scharf: I have not found requirements for telemetry in the requirements document. The telemetry information is packet technology specific.
Igor Bryskin: we are defining telemetric information for TE Tunnel/Topology with technology-specific augmentation
Lou Berger: the authors of the two drafts (this and the base model) to work together to reconcile the two documents
Tarek Saad: some of the performance metrics are technology-specific, so I'm hoping the idea is to augment the right yang model.

> 9    10:55  10   Title:    PCE in Native IP Network
>      (10:58)     Draft:    https://tools.ietf.org/html/draft-wang-teas-pce-native-ip
>                  Presenter:    Aijun Wang

Lou Berger: How many have read draft -- a few
            How many think that the WG should be working on this type of TE? -- very few
(conclusion) It doesn't seem like there is currently support for this in the WG, perhaps send mail on the how you are addressing questions previously raised to generate interest and discussion on the list

> 10    11:05  10  Title:    Recommendations for RSVP-TE and Segment Routing LSP co-existence
>      (11:08)            Draft:    https://tools.ietf.org/html/draft-sitaraman-sr-rsvp-coexistence-rec
>                  Presenter:    Harish Sitaraman 

Lou Berger: How many think the WG should be looking at signalled and SR based TE - A reasonable number
            How many have read the document - about the same
            How many think this draft is a good foundation for the WG activity in this area - about the same
(conclusion) Looks like there is support for adoption, will take it to the list.

> 11    11:15  10  Title:    Fast Reroute Procedures For Associated Bidirectional Label Switched Paths (LSPs)
>                  Draft:    https://tools.ietf.org/html/draft-gandhishah-teas-assoc-corouted-bidir
>                  Presenter:    Rakesh Gandhi

Stewart Bryant: How do you handle one way failures and maintain co-route requirement
Rakesh Gandhi: GMPLS-FRR has the same issue. We revert to the co-routed path
Stewart Bryant: but the change in the reverse direction may be relatively slow. Is that OK?
Rakesh Gandhi: this is an issue for unidirectional failures? Isn't that as likely as bidirectional?
George Swallow: control plane will detect failure and take link down
Tarek Saad: downstream node can detect failure and signal failure
Lou Berger: How many think this function is important for the WG to work on - A reasonable number
            How many have read the document - a few less, but still a reasonable number
            How many think this draft is a good foundation for the WG activity in this area - about the same
            Does anyone have reservations on adoption? -- no
(conclusion) Looks like there is support for adoption, will take it to the list.

> 12    11:25  5   Title:    ONF/T-API Services vs. IETF/YANG Models and Interfaces
>                  Draft:    https://tools.ietf.org/html/draft-bryskin-teas-yang-ietf-vs-onf-00
>                  Presenter:    Igor Bryskin

Lou Berger: we usually do not see drafts with comparisons with other groups, what is the objective?
Igor Bryskin: trying to compare two models to see what is missing
Lou Berger: have you found something missing in the TEAS model?
Igor Bryskin: no
Scott Mansfield: as a liaison person, the perception from ONF people of this draft is negative. If you wish to involve ONF people, it needs to be softened to be more collaborative. It needs to say more than "ONF is bad, IETF model is much better".
Igor Bryskin: we have at least got attention from T-API
Lou Berger: getting attention from other SDOs is not our mission, we care about what is missing in our work and not in what it is missing on the other groups
Michael Scharf: concerns with the wording, the "versus" word is not inviting collaboration
Daniele Ceccarelli: having this work was one of the intention of the Transport NBI DT in CCAMP, it would be good to synch-up with the DT
Gert Grammel: I also think this is useful work and I'd like to see it moving forward
Fatai Zhang: we are doing standard for the industry, if there is confusion in the industry, we need to help resolve it. I think this draft is useful

Lou Berger: see you on Friday, and then in Prague!

> Adjourn    11:30        

Note takers (feel free to add your name here):
Haomian Zheng
Italo Busi
Matt Hartley