=============================================================================== PCE Working Group Meeting IETF 97 (Seoul) Working Group Chairs: Julien Meuric (julien.meuric@orange.com) JP Vasseur (jpv@cisco.com) Jonathan Hardwick (jonathan.hardwick@metaswitch.com) Working Group Secretary: Daniel King (daniel@olddog.co.uk) Responsible AD: Deborah Brungard (db3546@att.com) =============================================================================== Session I Time: November 16, 2016, 13:30-15:00 (1:30pm-3:00pm) Location: Park Ballroom 1, Conrad Seoul, Republic of Korea With thanks to our scribes: - Dhruv Dhody - Yuji Tochio (remote) - Haomian Zheng - Daniel King ------------------------------------------------------------------------------- 1. Introduction --------------- 1.1. Administrivia, Agenda Bashing (chairs, 5 min) (13:30-13:35) [5/90] - The session is being co-chaired by Jon Hardwick and Daniel King. Unfortunately, Julien and JP were unable to travel to the IETF this time. - Agenda bashing: no agenda changes. 1.2. WG Status (chairs, 15 min) (13:35-13:50) [20/90] Adrian Farrel: Can you clarify "No renewal" on the "Early code point allocations" on slide: Documents beyond the WG Jon Hardwick: After requesting early code point allocation, only one renewal is permitted. Adrian Farrel: The AD can give special dispensation to renew a second time. Deborah Brungard: Yes, you can ask the IESG to do it. Jon Hardwick: I know that is an avenue we can take, but I very much don't want to take it. I want to finish this work instead. Adrian Farrel: I would very much like to see these documents published as RFC. Jon Hardwick: The stateful PCE authors have comitted to move within one week. Dhruv Dhody: The [stateful-pce-inter-domain-lsp] I-D is not adopted, it was submitted using a WG doc name by mistake. Himanshu Shah: There is the auto-bandwidth draft we are interested in. We have asked for WG adoption a few times. Jon Hardwick: Does anyone want to support (at the mic) the auto-bandwidth I-D, or object to it? Jon Hardwick: The problem was that JP had a significant concern about this draft and emailed the list. Was this resolved? Dhruv Dhody: We replied to JP's comments and thought we addressed the questions. We would like to discuss how to move the I-D forward and request adoption. Jon Hardwick: If JP's concerns have been addressed then we can call for adoption. 2. Work in Progress ------------------- 2.1. PCEP Extension for associating Policies and LSPs https://datatracker.ietf.org/doc/draft-dhody-pce-association-policy/ Dhruv Dhody, 5 min (13:50-13:55) [25/90] Dhruy Dhody: We would like to associate a user-defined policy to a group of LSPs. Adrian Farrel: How does this relate to the signaled policy that RSVP might use? Also, is there a vendor independent mode capability? Dhruv Dhody: We would like to work with you on this. 2.2. PCEP Extension for LSP Diversity https://datatracker.ietf.org/doc/draft-litkowski-pce-association-diversity/ Stephane Litkowski, 10 min (13:55-14:05) [35/90] Haomian Zheng: This is useful. The resource sharing draft is related to this work. Let's work together. Stephane Litkowski: Yes. Loa Andersson: Regarding the shortest path flag (P), is that strict (lowest hop count)? George Swallow: If your shortest path won't allow totally disjoint, what will you get? Stephane Litkowski: Then the PCE can relax the requirement to be totally disjoint, but only if the PCC has indicated that this is acceptable by leaving the "strict disjointedness" flag (S) unset. Daniele Ceccarelli: If you set both P and S flags, and you cannot meet both requiements, can you relax/prioritise one? Stephane Litkowski: It's strict currently, but we can discuss. Adrian Farrel: Please take care to distinguish between this disjointedness constraint and an objective function. We will have an offline discussion. Lou Berger: Have you looked at lsp-diversity draft in CCAMP and now in TEAS? Stephane Litkowski: No. Can you send me the pointer? Jon Hardwick: This is good, missing function. I have two comments. 1) Please don't suggest code points in your draft. Before we can poll for adoption, please remove these code points and submit a new version of the draft. Once adopted, we can proceed to an IANA early allocation, which is a fast process. 2) If the PCE relaxes the diversity criteria for some of the LSPs, you need a way to tell the PCC which LSPs got relaxed. If the PCC gets less than it asked for, then it needs to know. Stephane: OK. Himanshu Shah: I particularly agree with Jon's second point. 3. New Work ----------- 3.1. Association-aware Computation https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/ Stephane Litkowski, 10 min (14:05-14:15) [45/90] Danielle Ceccarelli: This is a good solution for a problem that doesn't exist. What you need is a PCE server with a good internal reliability mechanism. SDN controllers are already offering this. Stephane Litkowski: We have the problem. We are doing this for resilency, scalability, and to avoid a computation loop. We have an SDN-like availability solution, which can be issued. Danielle Ceccarelli: You may also have IGP, BGP database issue. Haomian Zheng: Is the role master/slave permanent? Or per LSP? Stephane Litkowski: You can decide it flexibly. Haomian Zheng: If everything is configured manually, it may be controversial. Stephane Litkowski: We never say it's the best. Adrian Farrel: In the real world, i.e. non-Unicorn networks, this is good solution for a real problem. Dhruv Dhody: The solution should be applicable to multiple deployment options: H-PCE, stateful, et al. 3.2. Ability for a stateful PCE to request and obtain control of a LSP https://datatracker.ietf.org/doc/draft-raghu-pce-lsp-control-request/ Dhruv Dhody, 5 min (14:15-14:20) [50/90] Jon Hardwick: (Chair hat off) This seems like useful function to have. Haomian Zheng: How does this work with pce-initiate? Dhruv Dhody: It's applicable if the LSP is orphaned, this is not for creating a new LSP. 3.3. P2MP Updates (RFC 6006bis) https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/ Dhruv Dhody, 5 min (14:20-14:25) [55/90] Jon Hardwick: Should we spin a new RFC or simply submit an errata? George Swallow: Coders are more likely to look at the RBNF than to read the text. They may not notice an errata. I say spin a new RFC. Adrian Farrel: Do both, the WG can publish a bis quickly. Jon Hardwick: Action for Dhruv to enter this in the errata system. 3.4. PCE for Native IP https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/ https://datatracker.ietf.org/doc/draft-wang-pce-extension-native-ip/ Aijun Wang, 10 min (14:30-14:40) [65/90] Jescia Chen: I have not read this carefully, but I am confused. How do you modify forwarding behavior? There is bgp-flowspec and pce-flowspec. George Swallow: Are you assuming every node in the slides is running BGP? Jon Hardwick: There ia an architecture and solution dicussion to be had first. There is already a TEAS document covering this, so I suggest you continue to discuss the architecture and use case in TEAS, then we can continue the dicussion on solution (PCEP) work if there is consensus in TEAS around this idea. George Swallow: Suggest you also include the IDR WG in the dicussion. 3.5. Connections and Accesses for Hierarchical PCE https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/ Huaimo Chen, 10 min (14:40-14:50) [75/90] Jon Hardwick: Are you implementing this? Huaimo Chen: Not yet, but we are thinking about it. Dhruv Dhody: We have function in PCEP-LS that solves some of the function required. Jon Hardwick: Please continue this dicussion on the list. 3.6. Optical Link-State Distribution in PCEP https://datatracker.ietf.org/doc/draft-lee-pce-pcep-ls-optical/ Young Lee, 10 min (14:50-14:55) [85/90] Jon Hardwick: This work assumes that we have already accepted PCEP-LS. PCEP-LS has been discussed before, but it's not clear what the support is from the WG, beyond the existing document authors. We have had negative comments that this work re-invents the function already in BGP-LS. A question I have is what support do we have in the PCE WG for PCEP-LS generally (not just this draft)? Anyone like to voice support in the room? Or anyone not agreeing that we should adopt it? Young Lee: I would remind eveyone that BGP-LS is for packet and we need optical support. Jon Hardwick: Are you saying that BGP-LS lacks TLVs to describe the optical domain, or that the devices you have deployed in the optical domain do not have a BGP stack running on them? Young Lee: It is both. Jon Hardwick: You can fix the lack of optical TLVs in BGP. However, it is harder to see how you can fix the lack of deployment of BGP in those networks. Haomian Zheng: We need to make clear what PCEP-LS is competing with. If BGP-LS, unfortunately optical networks don't have BGP and we will fail on IP+Optical without optical PCEP-LS. If competing with other protocols, we need a gap analysis. Currently PCEP-LS is the only solution for optical. Adrian Farrel: Putting in new TLVs in any protocol is doable; if optical TLVs do not exist in BGP-LS then they can always be added. So this is not a lever for creating PCEP-LS. The real reason is the lack of BGP in optical deployments. However, if we are looking at mechanisms then maybe we also need to consider netconf. Jon Hardwick: We need further dicussion, I'll start a thread on thread in the PCE list. 3.7. PCEP Link-State extensions for Segment Routing https://datatracker.ietf.org/doc/draft-li-pce-pcep-ls-sr-extension/ Jiajia Fan, 5 min (14:55-14:60) [90/90] - No comments. End of session 14:59.