IETF 97 - TEAS WG - Meeting Minutes
Version: Dec 08, 2016
Monday November 14th 2016
09:30 - 12:00 - Monday Morning Session I
Room: Grand Ballroom 3
Slides: https://datatracker.ietf.org/meeting/97/session/teas
YouTube: https://www.youtube.com/watch?v=71PKKZUKX94&t=4s&index=89&list=PLC86T-6ZTP5gtLuoSjpTGO_mS5Ly2pfIS
Audio: https://www.ietf.org/audio/ietf97/ietf97-grandballroom3-20161114-0930.mp3
Jabber: https://www.ietf.org/jabber/logs/teas/2016-11-14.html
> Num Start Time Duration Information
> 0 9:30 10 Title: Administrivia & WG Status
> Draft:
> Presenter: Chairs
Two drafts in last call, publication request of second draft should be in the next couple of weeks.
Reminder that draft discussions should be on the list so that others can see and comment if desired.
> 1 9:40 10 Title: WG Draft updates
> Draft: Many
> Presenter: Chairs
Pavan Beeram:
te-metric-recording: no status update received. is there still interest? Poll: How many think the WG still work on this?
Ingress protection: Chairs believe it needs an editorial scrub in next few weeks and then WG last call. No issue in progressing it since the experimental status.
network-assigned-upstream-label: Poll: how many have read the latest version? Please review it.
> 2 9:50 10 Title: A YANG Data Model for Traffic Engineering Tunnels and Interfaces
> Draft: https:/tools.ietf.org/html/draft-ietf-teas-yang-te
> Presenter: Rakesh Gandhi
Pavan Beeram: Does anyone want to comment on open issues? No questions.
Lou Berger: what is your plan for the different modules?
Rakesh Gandhi: wrt RSVP it is very stable. wrt TE model it is one model but further discussion is needed.
Lou Berger: It may be time to peal off the more mature parts and start publishing them. Aslo should consider to allow implementors only implement the parts that they care about, e.g., just a specific technology.
Daniele Ceccarelli: Relationship between otn model and L1 model - you already answered. What is the relationship with italo's path computation API?
Rakesh Gandhi: We have had some discussion with PCE team on PCE yang model. We need to do some more work
Dhruv Dhody: Need to clarify role of ietf-te-pcc model. PCC can mean device, NMS, etc. Perhaps clarify in joint session, what is the role of this model?
Lou Berger: In terms of splitting the draft up, please think about what parts are stable enough to do that now so they can be progressed.
> 3 10:00 10 Title: Extensions to RSVP-TE for LSP Egress Local Protection
> Draft: https:/tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection
> Presenter: Huaimo Chen
Huaimo Chen: Status update, First slide - More details have been provided in the draft.
Huaimo Chen: Need WG chairs help on one comment: Author of draft [draft-shen-mpls-egress-protection-framework] asks for a reference in this draft. Stuck figuring out how to resolve this issue, draft is 6.5 years old. Concern about making a reference from this stable draft on an unstable/individual draft.
Lou Berger: An informative reference isn't blocking and is your choice. If useful, add it.
Lou Berger: Asking MPLS chairs to comment. Question to MPLS chairs, will this individual draft be adopted?
Loa Anderson: It is an individual I-D in MPLS and MPLS WG does not have an opinion (yet). Loa thinks MPLS work might become a delta on TEAS work
Lou Berger: Happy to have a solution draft come before a framework draft. For the concern about a WG document referencing an individual draft, it is fine to reference as an informative reference.
Lou Berger: Huaimo has the choice whether to include the reference
Pavan Beeram: how many have read this version? A few. How many think it's ready for last call? . Not a lot either way.
Lou Berger: Please read and review and send comments send to the list. (particularly objections or ready to go comments).Seems we have adequate support to wrap this document up.
> 4 10:10 10 Title: Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs
> Draft: https:/tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute
> Presenter: Rakesh Gandhi
Lou Berger: Good changes worth re-reading. How are you dealing with off-path control? Here it needs to be in-band unlikely GMPLS.
Lou Berger: It would be good to address this.
Rakesh Gandhi: Current scope is just in-band signaling.
Lou Berger You can't claim you support GMPLS if you don't support off-path control. Have a look at it and come back.
Himanshu Shah: Agree it should be addressed.
Rakesh Gandhi: Will take a look at this.
Pavan Beeram: Will move to another last call after changes.
> 5 10:20 10 Title: Requirements for Abstraction and Control of TE Networks
> Framework for Abstraction and Control of Traffic Engineered Networks
> Draft: https:/tools.ietf.org/html/draft-ietf-teas-actn-requirements
> https:/tools.ietf.org/html/draft-ietf-teas-actn-framework/
> Presenter: Young Lee
Young Lee: ACTN framework, document is quite stable, but need more reviewers.
Adrian Farell: Apologies for not doing a terminology review. Will try and get the review done.
Lou Berger: There were changes in terminology, getting it stable and consistent is important, they were old issues that were put on hold until the terminology is updated. Please can WG look at the terminology and review both documents, and see if it makes sense. Then check old comments, and see if they still apply after the terminology update. Now is the time to review the documents, in particular the terminology.
> 6 10:30 10 Title: Information Model for Abstraction and Control of TE Networks (ACTN)
> Draft: https:/tools.ietf.org/html/draft-leebelotti-teas-actn-info
> Presenter: Sergio Belotti
Lou Berger: Questions/comments? [None] Same information appears to be repeated in other documents.
Sergio: Yes, there is some terminology that is repeated from other drafts. Could decide that the definitions should be in other frameworks.
Lou Berger: Once the other drafts have been completed, what will be left in this draft? Is there still enough left to be published?
Young Lee This is an info model that is useful before implementation. It is a standalone RBNF info model, independent of other ACTN related documents.
Daniele Ceccarelli: May not be overlap, but should remove any content that overlaps in other documents. Information model applies at the CMI where we don't have any solution yet. In CMI many more things are missing. Even if we remove redundant information from the document, there is still enough to publish as a useful independent document.
Pavan Beeram: So you see this document being eventually published?
Sergio Belotti: Yes
Lou Berger: How many people think that this is useful work? [A reasonable number of hands]
How many have read? [About the same]
How many think that this should be adopted as a WG document? [about the same].
Chairs will discuss next steps (and go from there.)
> 7 10:40 10 Title: Abstraction and Control of TE Networks (ACTN) Abstraction Methods
> Draft: https:/tools.ietf.org/html/draft-lee-teas-actn-abstraction
> Presenter: Daniele Ceccarelli
Adrian Farrel: I find most of this useful. Struggling with the abstract node with border nodes.
Daniele Ceccarelli: From requirement point of view, ask the PNC to set up a tunnel or set up a service -- need to know the two PE nodes to set up a tunnel. Perhaps could have further refinement.
Dhruv Dhody: Border nodes are still nodes.
Gert Grammel: A model without the border nodes isn't useful.
Daniele Ceccarelli: Starts with a black abstraction and then can added extra detail.
Dhruv Dhody: RFC6805 H-PCE uses the black topology. Both exist and both are usable.
Dieter Beller (Nokia): For the left abstraction need to know the links between the border nodes, for the right total abstraction , need connectivity information.
Young Lee: This is a justification for path compute request/reply.
Gert Grammel: What is the problem that we are going to solve? Path computation or not?
Daniele Ceccarelli: Draft is to find common agreement.
Gert Grammel: Agree, it would be nice to have something talking about abstraction, but abstraction has to serve a purpose. Work out the purpose and then figure out the abstraction. Need to link the two.
Lou Berger: Cataloging possibilities, and useful from that purpose. The document is introducing new terms (from black links to black networks), terminology should be defined in the framework.
Loa Andersson: Need some information on the connectivity.
Daniele Ceccarelli: Black topology gives you the information to ask for the connectivity.
Adrian Farrell: Already have switches with limited capabilities. Concerned about the terminology. Abstract node has a very specific meaning, perhaps use virtual node instead. 7926 RFC talking about problem with too much abstraction nodes.
Lou Berger: Need to align terms, being loose with terms causes confusion.
Italo Busi: Think that this work is very useful. Useful to think about abstractions in different context.
GQ : What does the circle mean. Is an abstracted topology equal to information entity?
Daniele Ceccarelli: The circle is the domain. The black abstraction doesn't tell you the internal connectivity.
> 8 10:50 10 Title: Applicability of Yang models for Abstraction and Control of Traffic Engineered Networks
> Draft: https:/tools.ietf.org/html/draft-zhang-teas-actn-yang
> Presenter: Young Lee
Jeff Tantsura: Yes, this is useful work, how to mount the different YANG models.
Gert Grammel: A bit confused reading the draft. Is there an entire hierarchy for each technology? e.g. one for packet, one for optical, one for the services or everything is put together?
Young Lee: A good question, how do the different YANG models fit into this model. Happy to develop details of use-cases further if the WG thinks it is useful.
Lou Berger: Note that on the diagram (Slide 9) the left and right look the same but with different names
Young Lee: Because they are different areas of IETF.
Lou Berger: The matching is helpful. Rest of industry understand the left-hand-side terminology (Orchestrators and Controllers), perhaps should adopt the same terminology as everyone else rather than continue down a path that makes it harder for everyone else to understand?
Young Lee: Industries use different terminologies, which is why it is being defined here.
Lou Berger: Concept of service models is well entrenched in IETF, e.g., L3SM and L2SM. Do we want to align with terminology with other areas to make it easy for others to understand.
Jeff Tantsura: Using existing terminology for existing functions would be great.
Daniele Ceccarelli: Mapping of terms isn't quite 1-to-1. PNC is one functionalities of the controller, the MDSC is one of the functionalities of Orchestration. It is not necessarily 1:1 mapping between service yang models and ACTN arch/interfaces.
Lou Berger: Adding this description to the terminloogy description would be very helpful.
Haomian Zheng: Propose continuing to use ACTN terminology as we have been using them for a while. Only change the terminology if the terms are exactly the same.
Lou Berger: Lots of people are likely to understand controllers/orchestrators, but not MDSC or PNC, hence aligning with common terminology is useful independent of age of terminology.
> 9 11:00 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
Lou Berger: How many have read this document? A reasonable number. Have you thought about relationship between L2SM and L3SM model?
Dhruv Dhody: Yes. Need to translate Qos between the models. May write a mapping model between L2/3 service models to ACTN VN model. What to maintain a mapping between the models (which is the job of the service orchestrator)
Lou Berger: Want to see how L3SM/L2SM use this model.
Jeff Tantsura: Please make sure that the mapping between the service model and the underlay infrastructure (being a tunnel or a VN) is generalized enough to be able to be used to L3SM, L2SM and whatever SM will come.
Xufeng Liu: What is the relationship between TE-abstract topology model and this model?
Dhruv Dhody: This uses a reference to the TE-Topology model.
Xufeng Liu: This looks like a simplified version of another model (TE-abstract topology model). Do we always need to build another model in such cases?
Dhruv Dhody: Our aim is to build a simple model for our customers doing VN. Still have to use abstract topology model if that is what you want.
Xufeng Liu: Topology model can already provide abstract nodes.
Lou Berger: Interesting discussion, but needs to be cut due to over time. Perhaps we are looking at a TE service model -- beginnings of one?
> 10 11:10 10 Title: Inter-Op Test Cases in Multi-Vendor Scenario based on ACTN Architecture
> Draft: https:/tools.ietf.org/html/draft-zheng-teas-actn-multivendor-interop
> Presenter: Haomian Zheng
Dieter Beller: Would like to get some clarification on intent - is IETF going to organize interop events between vendors. Not all YANG models are stable? Not an official IETF interop test.
Lou Berger: It is always good to hear implementation reports and issues found for the model/protocol work in IETF. Although there is no official inter-op in IETF, it is up to the volunteers to work together which is encouraged.
> 11 11:20 10 Title: The Use Cases for Using PCE as the Central Controller (PCECC) of LSPs
> Draft: https:/tools.ietf.org/html/draft-zhao-teas-pcecc-use-cases
> Presenter: Boris Khasanov / Andrey Elperin / Evgeniy Brodskiy (Potential -- Remote presentation)
Lou Berger: How many people have read the document? We will talk a bit more about this after the next presentation.
> 12 11:30 10 Title: PCE in Native IP Network
> Draft: https:/tools.ietf.org/html/draft-wang-teas-pce-native-ip
> Presenter: Aijun Wang
Lou Berger: How many have read the draft? A few people. The draft describes a new use case, and also a solution for that. Would be useful to move the use case description into document. The solution can continue to be discussed in this draft. Would like to get feedback from authors and the room?
Aijun Wang: Ok. What about the solution itself?
Lou Berger: This draft would continue as a solutions draft.
Dhruv Dhody: As a co-author/contributor of previous document (draft-zhao-teas-pcecc-use-cases), concerned that adding this usecase might slow the other draft; not sure that this is a good use case.
Danielle Ceccarelli: We already have a solution for Traffic-Engineering in IP networks -- it is called MPLS.
Jeff Tantsura: Would like to see better comparison with FlowSpec and BGP based solutions before we proceed.
Lou Berger: I would take the reaction of the room as rejection to the Chairs' proposal to bring the native-IP use-case into the use-cases document. How many would like to see a PCECC use-case to be adopted as WG draft? [reasonable number, about the same who read the draft]. How many think that draft-zhao-teas-pcecc-use-cases is a good foundation for this work? [About the same number, no reservations]. Chairs will talk and decide the next step.
> 13 11:40 10 Title: Recommendations for RSVP-TE and Segment-Routing LSP co-existence
> Draft: https:/tools.ietf.org/html/draft-sitaraman-sr-rsvp-coexistence-rec
> Presenter: Vishnu Pavan Beeram
Dhruv Dhody:
Looking at Central controller - Why cant we do only SR by the controller? Also wouldnt there be backwards compatibility issues when we don't know if the node is updating SR resv bandwidth or not.
Lou Berger: Question has to go the list.
Pavan Beeram: Will respond on the list.
Lou Berger: Next question has to go to the list as well.
Rakesh Gandhi: Quick point -- For the option with adjusting max-res-bw, can document cover the Diff-serve TE BC models RDM, MAM, etc. and explain what happens to Pool0, pool1, etc.
> 14 11:50 10 Title: Generalized Routing Interface Switching Capability Descriptor Switching Capability Specific Information
> Draft: https:/tools.ietf.org/html/draft-ceccarelli-teas-gneralized-scsi
> Presenter: Daniele Ceccarelli
Amy Yemin: I support this solution. 8 bits will be enough.
Pavan Beeram: How many think that this is a problem that needs to be solved? A good number. How many have read this draft? A good number. How many think that this draft is ready to be adopted??? Slightly less than the number of people who read it, but still a good number.
> 15 12:00 Adjourn
>
Note takers:Huaimo, Rob Wilton, PK