PCE Working Group Meeting - Tuesday, July 18, 2017; 3:50-5:50 PM Slides: https://datatracker.ietf.org/meeting/99/session/pce Meetecho: http://www.meetecho.com/ietf99/pce 1. Introduction 1.1. Administrivia, Agenda Bashing (chairs, 5 min) 1.2. WG Status (chairs, 20 min) [25/120] - Note Well is updated, please check RFC8179 - Working Group has a new Secretary, welcome to Dhruv Dhody - Thanks Daniel King for his service Daniel King: For draft-ietf-pce-inter-area-as-applicability, New update, end of next week. Jonathan Hardwick: For draft-ietf-pce-path-setup-type, Check with implementers and make a final decision on RSVP-TE path setup type. Julien Meuric: For draft-ietf-pce-pcep-yang, Open Issues - it's an issue beyond PCEP, Whether to keep notification in the model or not. Dhruv Dhody: We are checking with yang doctors, we asked if we should rely on yang push or keep notifications in the model. Daniel King: For draft-ietf-pce-hierarchy-extensions, to be updated - end of next week. 2. WG I-Ds 2.1. PCEP Extensions for Association Groups (Dhruv Dhody, 10 min) [35/120] draft-ietf-pce-association-group Jon: If you have a dynamic association group ID, does the ID get used from the head-end (PCC address space)? What happens for multi-head LSP? Dhruv: Yes and in case of multi-head, association id is from PCE or a generic value (0.0.0.0). But note that association id, type and source together act as key. In case of multi-head, the association source IP address is either PCE or value such as 0.0.0.0. In case of dynamic association, we want to make sure that the association identifier is does not clash with association id that would be configured by operator . Jon: Why did not make the ID range explicit, and assigned/managed by IANA? Dhruv: The original proposal had explicit allocations but this was removed after feedback from other authors/contributors. Since some association could be only dynamic or operator-configured, the wastage of some association identifier space should be avoided. Rakesh Gandhi: For bi-directional, we have multi-head LSP in same associations and we would want to use the full association identifier space. 3. New I-Ds 3.1. PCEP Extensions for Residual Bandwidth (Daniele Ceccarelli, 10 min) [45/120] draft-lazzeri-pce-residual-bw Jon: Clarification question for Daniele - Is this applicable for only one source requesting the LSP, so that reporting residual BW can be used? What happens if multiple PCCs are setting up LSPs and consuming resources separately? Daniele Ceccarelli: We had considered single source (a single H-PCE), and in case of multiple, some synchronization between them. Scope was a single source. Dhruv: Even if only single source node, the proposed mechanism will only work if there is no other path computation requests asking for the same resource. It is possible there should be a timing issue, i.e., the residual resource should only be valid for a duration of time. Shouldn't this be similar to delay metric, the delay at the time of path computation in a stateless PCRep message and receiving delay later via telemetry. Daniele: In the worst case, you cannot get any advantage, but it improves if you are lucky. Dhruv: Agree. 3.2. PCEP Extensions for Flexible Grid (Young Lee, 10 min) [55/120] draft-lee-pce-flexible-grid Julien: Regarding Frequency Slot Restriction - Why not reuse the existing label set encoding defined in GMPLS for frequency slot? Rather than request a new Spectrum Allocation TLV? Young: We actually do reuse label set encoding, but we have "m" and "n" slot width identifiers fields. Out of label set mechanism (action field), we proposed using only one mechanism - bit map encoding similarly to the YANG efforts for WSON/Flexi-grid. Julien: More cleanup of text is needed 3.3. PCEP Extensions for Multilayer LSP Association (Fangwei Hu, 10 min) [65/120] draft-xiong-pce-multilayer-lsp-association Jon: Who has read this draft? [3 hands raised] Jon: Need more engagement from working group before we can poll for adoption. 3.4. PCEP Extensions for Stitching with H-PCE (Young Lee, 10 min) [75/120] draft-lee-pce-lsp-stitching-hpce Julien: Would you consider merging BRPC and this draft into one? Young: We are open to that. Jeff Tantsura: The label should be binding-sid. Julien: we are also considering having a single solution for binding, stitching, etc. We should limit number of documents in parallel. Young: We can discuss with authors of three drafts off-line. Sergio Belotti: The intention and example is clear, but the draft lacks the explanation on the procedure and intention. Young: We can do that. Jeff: Consider MSD, you may run out of labels, we can talk off-line. 4. Previously Discussed Topics 4.1. PCEP Extension for Flow Specification (Adrian Farrel, 10 min) [85/120] draft-li-pce-pcep-flowspec Jon: I think it is in scope. Corollary to PCE initiate. Adrian Farrel: It is surprising that we don't have this, and this has been solved via multiple approaches such as BGP, netconf, CLI... Jeff: In scope, very much needed. Not sure about RD. Daniele: Agree with Jeff, how often would this binding occur. Adrian: It may depend on how frequent the LSP arrival rate is, which is an unknown parameter. Jeff: Currently this might be done via nexthop resolution, that would be the only way to do this granularly. 4.2. PCE as Central Controller (Dhruv Dhody/Satish Karunanithi, 10 min) [95/120] draft-zhao-pce-pcep-extension-for-pce-controller draft-zhao-pce-pcep-extension-pce-controller-sr draft-palle-pce-controller-labeldb-sync Jon: Can you justify, why we need a new message, why not use one-hop LSP using PCInitiate? Dhruv: We considered this, but for SR, it was a bit tricky and to retrofit it there was not clean. It was an implementation choice. We are open to WG feedback on that. Adrian: I am in the same camp as Jon, and we should try our best to use existing message. Jon: It is important, if the IGP is bypassed. We need to justify before making a decision. Dhruv: We should turn to the architectures and use cases drafts, and investigate on whether PCEP has any advantages in case PCE is also managing the label space. <> Adrian: If PCE is SDN controller, we don't use RSVP-TE, it is PCE that touch the nodes. In case of SR, we don't use IGP, it is PCE that touch the node. 4.3. PCEP for Distribution of Link State and TE (Young Lee, 10 min) [105/120] draft-dhodylee-pce-pcep-ls Bin Young Yun: PoC with PCEP-LS, We implemented three recovery schemes and are interested in the restoration times. We think these extensions are useful. For time critical recovery, this is quite useful. Julien: We already have multiple solutions ISIS-TE, OSPF-TE, BGP-LS, Yang model et al., why do we need another one? Young: OSPF-TE and ISIS-TE has a slower convergence time than this proposal. This proposal is not another solution, but an improvement to existing IGP-TE. Proven via experiments. Julien: You can improve IGP. Use Yang. BGP-LS exist. Also PCEP is not deployed everywhere. Young: In a centralized world, use of PCEP is better and Yang is text based and doesn't give the same performance as a binary based protocol. No one support incremental update on attribute change. Jeff: Convergence is not an issue. Not convinced this is required for packet, agree it is useful for optical environments, no other alternatives exist. If you have customer asking for packet, we should do this. Young: We can all agree on optical (Flexgrid, GMPLS). Haomian Zheng: We have conducted performance study with this proposal with text-based proposal such as YANG. We see two-three times faster than the text-based model. Optical/Microwave demand a PCEP based solution. We need a base PCEP-LS, over which these extensions can be built. Julien: All optical n/w have IGP (at least for management), not all have PCEP. Michael Scharf: XML/Json can be parsed fast, parser implementation issue. Haomian Zheng: PCEP-LS co-exist with other solution, rather than compete. Julien: IETF develops standards, or catalog? Young: Can we ask WG what do they think? Jon: We are using PCEP to do what is done via IGP, I need to refer this discussion to the AD to see if we can take this work on given it may be out of scope of our charter. Young: I would like to ask how the WG thinks of this proposal. We need to make a decision based on that. Lou Berger (as TEAS co-chair): ACTN is basically SDN for TE networks. If we have PCE/PCEP as a mechanism to go down to the device in ACTN. We have been working on a assumption that PCE as SDN controller, it is easy to see this work falls into the TEAS ACTN architecture. Poll initiated by Jon 1. Who wants to see this work adopted? [9 hands] 2. Who does not want this work adopted? [3 hands] Lou: To Julien, is PCEP is appropriate for SDN? Or only for distributed model. Julien: Avoid duplication, this feature is covered by other mechanism. Jeff: PCEP might not be build for this much amount of information, we need more semantics/focus on optical/microwave, and not on dynamic packet networks. Adrian: Think of what harm can this do? rather than the benefit. Julien says competing mechanism. But it does not damage anything, market could decide. Julien: Operators worry about too many mechanism, leading to interoperability issues. Young: PCE is doing much more than path computation. If PCE is Central Controller (PCE-CC), why would this work be not in scope from that perspective? Jon: Strong support as well as strong issues, so no clear consensus. Next step is talk to AD and discuss on the list. <>