=============================================================================== PCE Working Group Meeting IETF 96 (Berlin) 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: July 21, 2016, 14:00-16:00 (2:00pm-4:00pm) Location: Tiergarten, Intercontinental Berlin, Germany ------------------------------------------------------------------------------- 1. Introduction --------------- 1.1. Administrivia, Agenda Bashing (chairs, 5 min) (14:00-14:05) 1.2. WG Status (chairs, 15 min) (14:05-14:20) Jeff: after fixing the semantics of MSD, we are ready to go Dhruv: The authors dicussed the intended status and felt that due to the implementation maturity and number of them, we could change from "Experimental" to "Standards Track". Xian: Authors have addressed shepherd review comments. Xian: Basically ready, but would need WG to provide more feedback. 2. Work in Progress ------------------- 2.1 PCEP Hierarchy Extensions https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ Dan King, 5 min (14:20-14:25) No questions. Julien: Regarding moving to standards track, No strong opinion, esp because of multiple implementation. Will take it to the list. 2.2 Inter-area and Inter-AS Applicability https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/ Dan King, 5 min (14:25-14:30) No questions. Jon: Will move to LC, after the meeting. 2.3 PCEP Enhanced Errors https://datatracker.ietf.org/doc/draft-ietf-pce-enhanced-errors/ Xian Zhang, 10 min (14:30-14:40) Dhruv: When this work was presented (IETF 78) some of the procedures and corrosponding errors and notifications have evolved. The ways in which people are thinking of deploying PCEs are not necessarily the same. People think more now of deploying hierarchical PCE. I am not sure this document is applicable any more. We will need to review this document again to ensure it reflects this. Xian: I would like to discuss with Dhruv offline to review these issues. Julien: [at mic, chair hat off] yes, ideas have moved on but this does not make the older ideas invalid. We can update to include newer work. Jeff: Yes, it would be good to have some guidelines for the new work, as we have new mechanisms that need to be reflected Jon: Please see the action for someone to contribute text for the Security and Operational considerations section. 2.4 BGP-based PCE Discovery Mechanism https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/ Jie Dong, 10 min (14:40-14:50) Poll - Who has read this document? [About 12] - Who would like to see this become a WG document? [Slightly fewer] 3. New Work ----------- 3.1 PCEP Experimental Code Points https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/ Dhruv Dhody, 10 min (14:50-15:00) Adrian: Do this, but. Its not quite right yet. We will need to tweak the proposal. Experiments are good, and if the ranges are kept small they force developers to an early request for a code point or let go. If a code point is used for an experiment and the open source platform then release the version, it might mean the projct code point squats. Dhruv: Could we assign for a specific time period, 1,3,5 years? Adrian: Sounds like early allocation. I think we need to think about a third way. Lou: Respond to Adrian's point, there is a allocation policy, maybe they want to use a code point for a 1-2 years. Its a "specification required". Dhruv: When I read the allocation policy document, it was not clear that was possible. Lou: You can also use a "Reserved" method. [See RFC5226?] Adrian: This does not exist. It never did. Lou: What you're describing is not "experimentation". Experiments are isolated - you should not coordinate code points between experiments. That is an IANA function. Use IANA if that is what you want to do. Lou: I am also concerned about informal allocation of code points across multiple protocols. Dhruv: No, will exclude other/multiple protocols. Julien: [Pesonal view] Thats why I like focusing on the essentials. Just the message, object and TLV code point spaces. Jon: I would like to see an experiment registry. Given the IANA sections of a number of I-Ds I have recently reviewed, I would also like to add experimental ranges for error-types and notfications. Michael: We had a similar problem in TCPM, please look at RFC6994 as it might address some of the issues you highlight here. Poll - Who read the I-D? [A handful] - WHo think this is a good base for the discussion? [Similar amount] 3.2 Applicability of PCEP to ACTN https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/ Dhruv Dhody, 10 min (15:00-15:10) Jon: Yes, it is my fault that you have had to write this I-D. Its helped me to understand the context of ACTN. The PNC <-> MSDC is hierachical PCE. The VN Association is not clear as to why the PNCs need to know the VN info, its seems the VN Association info would be used for the MSDC and above. Finally, is PCEP-LS integral to ACTN? Dhruv: If you want to use other protocols with ACTN, thats fine. PCEP-LS is not mandated. Jon: Good, so its not fundemental. Is PCECC something that needs to be in this applicability document? Dhruv: The relationship with PCECC and ACTN is such that PCECC is just one PNC, and another PNC could be using SR or RSVP-TE. I will describe the relationship in the document as well. Jeff: With PCEP-LS you are creating complexity and capability that already exists with things like BGP-LS. Dhruv: It depends how you want to use it, if you use PCECC and you have PCEP already you can pull TE info via PCEP-LS and not have to use BGP-LS. There are extremes. Jeff: You will still be missing link attributes. Julien: You should focus on how PCEP-LS may be used for ACTN. Pawel Brzozowski: Besides IGPs and BGP-LS we also have YANG. We also have Ross telling us not to create many ways to do a single thing. We don't need another mechanism. 3.3 Hierarchical PCE Discovery https://datatracker.ietf.org/doc/draft-chen-pce-h-discovery/ Huaimo Chen, 10 min (15:10-15:20) Julien: Does the Parent PCE really need to discover further information about the Child PCE, if I have already manually configured this info (capability and reachability). Huaimo: We need to confirm the configration in the protocol. Julien: It is not discovery, it is a configuration check. Is this information dynamic? Huaimo: There are security consideration, which is why configuration must be validated. 3.4 Connections and Accesses for Hierarchical PCE https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/ Huaimo Chen, 10 min (15:20-15:30) Adrian: Your identified requirements mentioned H-PCE architecture (RFC6805), but I think there are methods available for discovery and dissemination of inter-domain links. These requirements might be solved by things like BGP-LS. Depending the deployment and configuration policy, you may find the operator will already know which links exist between domains. Huaimo: Some times they dont, here we provide a easy way to provide that information. Igor: What if there is no link between domains, how does the parent PCE compute a inter-domain path? Huaimo: Bad luck. Igor: If I report (parent PCE) I cannot compute a path, how do I handle this? Anton Ivamnov: We have BGP-LS, this should be closed. Julien: The usecase is the same, you are duplicating the work already done. 3.5 Native PCE TED https://datatracker.ietf.org/doc/draft-chen-pce-pcc-ted/ Huaimo Chen, 10 min (15:30-15:40) Adrian: The first slide is misleading, what you have is a partial diagram from RFC 4655. You want to extend this to a node not running a routing protocol and using PCEP to learn TED. Huaimo: Yes. ------------------------------------------------------------------------------- Session II Joint YANG session with MPLS & TEAS & PCE Time: July 21, 2016, 16:20-18:20 (4:20pm-6:20pm) Location: Charlottenburg II/III, Intercontinental Berlin, Germany ------------------------------------------------------------------------------- Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pavan and Jon taken by Lou and George. 1. Introduction --------------- 1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30) 2. YANG models discussion ------------------------- 2.1 YANG Data Model for TE Topologies https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ Xufeng Liu, 20 min (16:30-16:50) Dhruv Dhody: Relationship with SR model? XL: Types to be shared. DD: Do we need RW on per-node attributes? Tarek: There are cases where information is learned via IGP, but other cases where static may be supported, thus the need for RW DD: What do we do on conflicts? TBD Igor Bryskin: one of the clients (users?) wanted to do path computation based on TE information as well Pavan: How many have read? Not so many. Please read and send comments to the list. 2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ Tarek Saad, 20 min (16:50-17:10) Lou Berger: Send that [option request] to Netmod. Xian Zhang: No strong preference among options, but, do these options on tunnel model also apply to TE topology? TS: I think you are actually asking about somthing that is derrived from routing config, which is also using option #2 (schema mount). LB: Routing config is using it, although the another wildcard form. logical element and network instance in the RTGWG are also using this form. This would be the 1st use of mounting a specific schema. Loa Anderson: Issues to be fixed on valid ranges of label values. TS: Ack LA: Ambiguous names to be fixed on H-LSP part. LB: What about Extension Labels (RFC7274) TA: will need to consider. DD: Be careful on artifical segmentation around PCC/PCE... DD: The lsp-key is 5 tuple and it should support extensions towards other technologies, e.g., SR. TA: Will have split P2P and P2MP LSPs so will have index within each (sub) trees LA: ietf-te-yang inherits from 2 models; do we need to ensure special review for these cases? 2.3 A YANG Data Model for MPLS Static LSPs https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ Tarek Saad, 20 min (17:10-17:30) Iftekar (Infinera): Who's taking care of switch over? TS: Static configuration. Pre-programmed backups are possible. Behaviors widely depend on DP capabilities. LB: What about OpenConfig's "applied state" discussion? TS: No IETF consensus about its usage so far. LB: Indeed, reco is not to jump to fast, too much error-prone. TS: General consistency matters. LB: From routing area discussion: use to be limited. View as author? Pavan: Agreed on consistency, but eithier way is fine. LB: Simplifying our models might be nice. Maybe we should ask the room. Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback already happened. XL: Not so much work. Structure to be simplified. LA: Would it work if both simplified and more complicated module were pushed? LB: Would work, but more implementation load. 2 different ways for every information element; Having just one way to access the information implies less code. LB (chair hat on): How many care? How many for simplified? How many for OpenConfig approach with augmentation? How many for OpenConfig as is? 2.4 TEAS Transport Service Model https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/ Xian Zhang, 15 min (17:30-17:45) Tarek S: I don't understand what's missing from other modules for "step 1". XZ: SB relies on PCEP, this is a service model. Daniele Ceccareli: Is technology-specific only on tunnels or also at service level? XZ: A couple of attributes are relevant for services. DC: OK, so both tunnels and service include technology-specific. Anurag Sharma (Infinera): Commonalty with tunnel: required work? XZ: Many things from tunnels turn optional/unnecessary. Himanshu Shah: Would end up creating something covered by other service models. George Swallow: There seem to be confusion. Service layer may be different from transport layer (e.g., Ethernet and OTN). Jon: This document is about transport as a service, not end user service HS: Need another document to connect all the dots DC: We can have higher layer services on top of pipe as well as service filling in pipes. We don't have a common service model, like an umbrella. XZ: We are looking at it differently, where we can have the ethernet or OTN service DC: Any plans in mind to solve non-te services? XZ: Plans only for transport/TE. Igor Bryskin: There is no difference between transport or service so lets just use (existing) tunnel model XZ: Indeed, difference is not clear. 2.5 PCEP YANG https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Dhruv Dhody, 15 min (17:45-18:00) Jeff Tantsura: Key-chain is close to LC. Julien: Who has read document? Who thinks it should be a WG document? Who thinks it shouldn't be a WG document? Clear consensus in the room. Decision will be confirmed by a poll on the PCE list. 2.6 YANG Data Model for MPLS LDP and mLDP https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/ Kamran Raza, 15 min (18:00-18:15) No question 2.7 LSP-PING-YANG https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03 Greg Mirsky (remaining time; started at 6:07) Italo Busi: Are you including MEG, MEP, MIP, etc? GM: LSP ping doesn't need those. No intention to introduce them there. Zheng? (Huawei, co-author): Confirmed <6:12 - Meeting adjourned> -------------------------------------------------------------------------------