Minutes for TEAS at IETF-93
minutes-93-teas-3
| Meeting Minutes | Traffic Engineering Architecture and Signaling (teas) WG | |
|---|---|---|
| Date and time | 2015-07-22 11:00 | |
| Title | Minutes for TEAS at IETF-93 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-09-22 |
minutes-93-teas-3
TEAS 93rd IETF TEAS Agenda For IETF 93 Jul 16, 2015Wednesday July 22nd, 20151300 - 1530 - Wednesday Afternoon Session I Room: Congress Hall 1 Chairs: Lou Berger and Vishnu Pavan Beeram > Presentation Start Time Duration Information > 0 13:00 7 Title: Administrivia & WG Status > Draft: > Presenter: Chairs Administrivia & WG Status - TEAS RFCs! - See slides for update https://www.ietf.org/proceedings/93/slides/slides-93-teas-0.pdf > 1 13:07 8 Title: Draft updates > Draft: Many > Presenter: Chairs Re: interconnected-te-info I-D Adrian Farrel: Apologies. We are reviewing I-D and have substantive reductions in text soon. This will mean the document needs a careful review. Pavan Beeram: draft-ietf-teas-p2mp-loose-path-reopt could do with more people reading it. Not many have so far. Extensions to RSVP-TE for LSP Ingress Local Protection Pavan Beeram: The authors of several WG drafts believe their drafts are ready for LC (see slides). Please review and comment on the list. Draft:http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection > 2 13:15 5 Title: Extensions to RSVP-TE for LSP Ingress Local Protection > Draft: http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection > Presenter: Huaimo Chen Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-teas-2.pdf Lou Berger: [Slide 5] Have you made any progress on selecting which method (Proxy-Ingress or Relay-Message)? Raveendra Torvi: We will be meeting later today Huaimo: Yes, the authors plan to meet, discuss and decide. Lou Berger: Please announce meeting on list so others may join in discussion > 3 13:20 20 Title: YANG Data Model for TE Topologies > Draft: http://tools.ietf.org/html/draft-ietf-teas-yang-te-topo > Presenter: Xufeng Liu / Igor Bryskin Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-teas-3.pdf Lou Berger: It would be good to follow through on your plan to remove scheduling sooner rather than later Xufeng Liu: Yes, within the next two weeks Adrian Farrel: Overlay & underlay relationship [slide 16]: I like that you can look down to the underlay; is it possible to reverse the view, can I (as the underlay) see what is above, i.e. what overly topology traverses me? Xufeng Liu: yes, but it may be inconvenient. We don't want to have 2-way links. Adrian Farrel: is there a quicker way that searching the whole TED? Lou Berger: Can you clarify if the model has the capability to do this? Or an implementation is required to support it. Xufeng Liu: The model allows it Adrian Farrel: So there is no back pointer in the model itself. Igor Bryskin: The model makes it easy to go from overlay to underlay - that relationship is usually 1:1, from underlay to overlay it could be 1:n so it is more difficult. > 4 13:40 25 Title: RSVP/TE Yang Models > Draft: http://tools.ietf.org/html/draft-saad-teas-yang-te > http://tools.ietf.org/html/draft-saad-teas-yang-rsvp > Presenter: Tarek Saad > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-4.pdf Lou Berger: Same question as IETF 92 - What do you mean when you say "Generic", does it include GMPLS? Tarek Saad: Generic includes generic features, e.g., bidirection, technology specifics are separate. Today just PSC is included. Igor Bryskin: Question for WG, a number of items missing from generic model. If we need to configure a transport service, then some elements may need to be configured that are not end-to-end. Tarek Saad: We wanted to defined a generic model, if what you state is applicable to multiple technology types it can be included in the generic model, but if its a single technology then no and it will need to be modeled and augment. Lou Berger: There is an example of this mentioned earlier (bidirectional) and the authors have a proposed approach. Once this is a WG document, the group can discuss and decide if this is best. Paul Doolan: Are the switching capabilities aligned with the generic model, and where are they derived from? Tarek Saad: Yes. Check they should be referenced [in I-D?] Paul Doolan: Ok, I just wanted to state the need to align. Lou Berger: Have you thought about merging with the OpenConfig draft? Tarek Saad: had some meetings with them, including one yesterday. We're aligning with their work. They'll import some of our groupings for now. I'll let Ina talk about long-term plans Ina Minei: We want to converge, if possible, and the authors will continue to talk. We want models that are easy to implement. It is too early to state that the authors plan to merge I-Ds. We want to avoid duplicating effort. Jeff Haas: approached the mic but was requested to send his comment/question to list. Lou Berger: [To Ina] We need to decide how to proceed as we have an I-D that we could adopt and work on. However, we do not want to move ahead and diverge from your work item as it has merit. Ina Minei: I understand your perspective but we are keeping our work separate for now and working on implementations using the models. Optimally we'd have our model which is made up of a collection of standard elements. Chair Poll (on presented drafts) - How many have read these I-Ds? <a good number> - How many feel the I-Ds are a good place to start? <a good number> Lou Berger: so we have a foundation, but we don't want to fork the work and we want to reconcile things. Normally we'd say "please merge the drafts", but we can't really ask this yet... Ina Minei: I can't speak for OpenConfig co-authors, but I'll take that feedback back to the OpenConfig folks and discuss with them. Lou Berger: we can define groupings that are used by multiple models. Ina Minei: that's the direction we're driving in. Ultimately we care about implementations and we don't' want to make people write code twice Lou Berger: Openconfig objective of a concise draft for their use, which may be different from the WG which may care more about covering the entire protocol. - (asked later) How many feel is good starting point for WG: <a good number> > 5 14:05 10 Title: MPLS / TE Model for Service Provider Networks > Draft: https://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-01 > Presenter: Ina Minei > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-5.pdf Loa Anderson: Meta question, the document is split 50/50 RSVP-TE and LDP. I am not clear if TEAS will be performing LDP work. Lou Berger: LDP details belong in MPLS. We need a common structure, this might be a meta/framework document or this document. This overall model could be managed here or in MPLS. For now, I'd say keep it here but we can revisit. Loa Anderson: As longs as the document states which containers are used its ok, if you start modifying the details within the container then its a problem. A suggestion, work on the document and present the RSVP-TE in TEAS WG and update MPLS WG for your LDP developments. Ina Minei: Okay. George Swallow: Are you importing containers from other models? Ina Minei: No, not currently. But that is the plan. ???: Has there been any work on coordination with other documents? Lou Berger: some, but all the documents need more coordination. > 6 14:15 10 Title: Usage of IM for network topology to support TE Topology YANG Module Development > Draft: http://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-topology > Presenter: Scott Mansfield > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-6.pdf Lou Berger: Please verify that our YANG models satisfy the IM and work with authors on any identified short commings. > 7 14:25 10 Title: Topology requirements > Draft: http://tools.ietf.org/html/draft-doolan-teas-te-topo-ml > Presenter: Paul Doolan > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-7.pdf Cyril: The abstracted topology seems to already supports some of the requirements/elements described in [slide n - virtual optical switch], or could be augmented for transport specific use cases. Lou Berger: I suspect much of what you are interested is covered by existing drafts or plans. Please talk with the authors directly to see if yours needs are met, or how they could be met. Also, keep in mind that technology specific definitions are still TBD and will be done in CCAMP. Once this is done, the draft can still be valuable by documenting your use case. Paul Doolan: Others have suggested a similar approach. Julien Meuric: Can you clarify the switching capability reference you made? Paul Doolan: IANA > 8 14:35 10 Title: Implementation Recommendations to Improve the scalability of RSVP-TE Deployments > Draft: http://tools.ietf.org/html/draft-beeram-teas-rsvp-te-scaling-rec > Presenter: Vishnu Pavan Beeram > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-8.pdf <no comments> Poll - How many think this is a topic we should be working on? [a good number] - How many think this a good document to start with? [~ the same number] - Does anyone have any comments or reservations about pursuing this work? [none] > 9 14:45 10 Title: Extensions to MPLS for Temporal LSP > Draft: http://tools.ietf.org/html/draft-chen-teas-rsvp-tts > Presenter: Huaimo Chen > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-9.pdf Lou Berger: Due to time constraints we will have move the comments to the list. > 10 14:55 10 Title: ACTN : Use case for Multi Tenant VNO > Draft: http://tools.ietf.org/html/draft-kumaki-teas-actn-multitenant-vno > Presenter: Takuya Miyasaka > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-10.pdf Lou Berger: You mentioned transport to start, and then mentioned L2VPN and L3VPN as your user service. Takuya Miyasaka: Yes, we are interested in L2VPN and L3VPN services Lou Berger: [Slide 4] Can you clarify QoS and SLA? Takuya Miyasaka: Bandwidth, latency, jitter, Lou Berger: Are these MEF definitions, how do you describe the parameters? Takuya Miyasaka: No, simply the same parameters for the end-to-end network mentioned before Lou Berger: Looking at an earlier slide, you show a customer provisioning interface is that something like a web based interface, is this correct? Takuya Miyasaka: Yes. Lou Berger: You show PCEP and RSVP for provisioning services within the network, do you use one or both? Takuya Miyasaka: Both > 11 15:05 10 Title: Requirements for Abstraction and Control of Transport Networks > Draft: http://tools.ietf.org/html/draft-lee-teas-actn-requirements > Presenter: Young Lee > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-11.pdf Lou Berger: A good start on requirements, and notable section on impact on YANG but this section needs further development. I would also like to see more discussion on future requirements and work that needs to be done. For adoption, I think we need to polish the aforementioned sections. Poll - Who has read the document? <a good number> - Who thinks this is a good document to serve as a foundation? <a good number> Lou: We can talk offline if comments are not clear, right after this > 12 15:15 10 Title: Framework for Abstraction and Control of Transport Networks > Draft: http://tools.ietf.org/html/draft-ceccarelli-actn-framework > Presenter: Daniele Ceccarelli > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-12.pdf Daniele: this work was previously polled and had good support Lou Berger: Poll was on the discussion not on a specific draft, and lead to the discussion here Daniele: (closes by summarizing ACTN overall status) Lou Berger: Understanding what the protocol extension requirements are would be very helpful. The interconnected-te document went through a similar process, but more for the case of end to end signaling control. This document may follow a similar evolution, but more from the perspective of "logically centralized" control. Daniele: Correct, that is the main difference Lou Berger: Please look to focus your document in the context of technologies that we have available, and its ok to say "this piece is missing". Daniele: Is it ok to keep that discussion (gap analysis) in this document? Lou Berger: If terminology is changed to cover the family of TE solutions, it's a great foundation for that. And hopefully we can get there faster than the we did with the interconnected document Young Lee: The document is an architecture framework document that should be viewed within the scope of TEAS with a more "logically centralized" approach without talking about protocol yet. Is it ok? Lou Berger: Yes agreed. This is rounds out and compliments the interconnected-te document and provides a missing part. Please authors, consider the comment and see if you can update the document from this perspective, the concepts are the same but will require authors. Young Lee: Do you have detailed suggestions. Lou Berger: We can talk offline and discuss. > 13 15:25 5 Title: Requirements of Abstract Alarm Report in ACTN architecture > Draft: https://tools.ietf.org/html/draft-xu-teas-actn-abstract-alarm-report-00 > Presenter: Xu Yunbin > Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-13.pdf Pavan Beeram: Please merge this with the earlier requirement draft > Adjourn 15:30 Minute Taker: Dan King Matt Hartley has reviewed audio ACTN notes updated by Lou Berger from audio (https://www.ietf.org/audio/ietf93/ietf93-congresshalli-20150722-1300.mp3)