PCE Working Group Meeting – 10:00-12:00 Friday, November 22 Morning session I o Chairs: Dhruv Dhody, Julien Meuric (remote) o Secretery: Hari (Hariharan Ananthakrishnan) o Slide: https://datatracker.ietf.org/meeting/106/session/pce o Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-pce?useMonospaceFont=true o Meetecho: http://www.meetecho.com/ietf106/pce o Video: https://www.youtube.com/watch?v=Kqz7fqkVNcw 1. Introduction 1.1. Administrivia, Agenda Bashing (chairs, 5 min) [Dhruv Dhody] Thanks Adrian for helping out during chair transition. Request to use mailing list and be vocal on the list. 1.2. WG Status (chairs, 10 min) [15/120] 1.3. State of WG I-Ds and next steps (chairs, 10 min) [25/120] [Mike Koldychev] Already implemented pce-segment-routing-policy-cp, would like early code point allocation and to expedite the adoption. [Dhruv] Thanks. Will discuss with Julien. 2. Segment Routing 2.1. Multipath ERO (Mike Koldychev, 10 min) [35/120] draft-koldychev-pce-multipath-00 [Yi Lin] Why not use existing method in PCEP for carrying multiple paths in one message (e.g., multiple Updates in 1 PCUpd message)? [Mike] It was discussed on the mailing list as well. One update links to one set of constraint, we want same constraints for multiple paths. [Dhruv] Was discussed and selected as preferred approach (last meeting and list) [Juanna Dang] Does multi-path support load balancing? Another work (ICAN) has covered the load balance scenario. [Mike] UCMP is supported. Please raise this issue on the list and I will take a look [Andrew Stone] This use case is also applicable to replication segment. Supports Adoption. [Stephane Litkowski] If one of the path is changing are we advertising both? From implementation point of view, we want to avoid extra processing. [Mike] We need to advertise both, we do provide per ERO ID. The implementation can match the ERO from previous update to the current one. There is some processing involved to compare the labels. [Dhruv] RBNF needs to be updated across all the message. Can this be a sub- object in the existing ERO, so that we can avoid updates to RBNF of existing messages? [Mike] We did analyze that option. Separator objects in ERO will make it complicated. If we make it as a sub-object, we cannot have TLVs. [Pavan Beeram] It would have made sense if there was a strong case for transit action. Since all the attributes that we were considering are ingress related there was no strong case for making ERO sub-object. [Dhruv] Please update the document with RBNF. Also what happens to RRO? In this document we have focused only on ERO. Lots of open questions, do handle in the next update. How does it work with protection association or backup path IDs? I will give my comments when we have an updated I-D. [Mike] RRO will be along the same lines. 2.2. Entropy (Quan Xiong, 10 min) [45/120] draft-peng-pce-entropy-label-position-01 [Stephane] What is the value of doing this when compared to letting ingress place the ELI/EL on its own. PCE might not be aware of the capability of ingress to push ELI/EL and at what depth of the stack. I don't see a value of doing this at PCE. Its better for the ingress to deal on its own as there is no assurance that ingress will be able to honor PCE's label stack. [Quan Xiong] PCE has more information like ERLD, MSD etc. [Stephane] That cannot determine if ingress can actually "push" ELI/EL, this is implementation dependent. [Dhruv] Stephane, Would you be happy if PCC can send a message with information that it was successful in adding ELI/EL? or do you think PCE will never be able to give the right answer? [Stephane] We are missing the capabilities of ingress inserting multiple ELI/ELs, MSD is not enough. MSD is a generic information in how many labels it can push. [Tarek Saad] In case of inter-domain, PCE would be useful. If there is a need to extend the capability of ingress, then we should add that. [Dhruv] Not just the capability that you can do this computation, but what is the capability of ingress when it comes to multiple ELI/EL pairs. I need to recheck about capability in your open message and can IGP/BGP communicate that as well. Keep the discussion in mailing list. [Quan] The capability and extension for BGP/ISIS has been approved in other working groups. [Dhruv] That is ERLD, Stephane is suggesting that you need something more. Please discuss and come back to the WG. [Dhruv] Regarding extended flags, we have run of any flags in our LSP object, we definitely should fix this. Doing that independently is the best option than clubbing with this. If you can put this outside the document then we can move that. [Stephane] I fully agree [Cheng Li] I fully agree as well [Pavan] I think there is presentation later on for additional flags for path protection. There are few LSP specific attributes being defined. Was there any discussion about replicating LSP attributes from RFC 6510 and Hop attributes extn? [Dhruv] Lets discuss after that presentation so that the WG is aware of what you are talking about. 3. Central Controller 3.1. Update to PCECC I-Ds (Cheng Li, 15 min) [60/120] draft-ietf-pce-pcep-extension-for-pce-controller-03 draft-zhao-pce-pcep-extension-pce-controller-sr-05 draft-dhody-pce-pcep-extension-pce-controller-srv6-02 draft-dhody-pce-pcep-extension-pce-controller-p2mp-02 [Tarek] There is another proposal to program P2MP replication segment. We didn't present this time, planning to present next time. We can compare and contrast. [Dhruv] Please use the list for discussion. 4. Other 4.1. Path Protection Enforcement (Andrew, 10 mins) [70/120] draft-stone-pce-path-protection-enforcement-00 [Dhruv] Can I ask a clarifying question? What is the requirement of MUST NOT have a protected path ? [Andrew] You might have LSPs based on their SLAs, you want them to go down and use other protection mechanisms as opposed to LFA [Mike] This feature is very useful. Cases like prefer unprotected, or must be unprotected are actual use-cases. [Dhruv] I was reading RFC 5440, name of the bit is desired, text says when set the path computation must include links protected by FRR. Must is not used in a normative way. [Andrew] I found that text odd, it was written before Segment Routing existed. At that time even though its a hard constraint, it couldn't influence the CSPF computation. RSVP suggested soft, so i don't think there is a right/wrong answer here. [Dhruv] I would like to have a 'Don't care' option. [Andrew] If both flags are set to 0, it means I don't care. The use-case only have three states, because of bits we have four states. [Dhruv] I feel its bit conflicting because once we say 'prefer' that means you do care. [Andrew] One influences the CSPF calculation other influences the selection of SID on the link. [Pavan] In RSVP-TE we have attributes flags TLV, R flag that tells required/ desired, do we bring those semantics to PCEP? [Dhruv] Regarding optional/mandatory we had it at the object level. We missed it in stateful, there is a draft. At flag level we don't have a mechanism. If there is a generic solution could be useful. [Eshan Rezaaifar] What happens if we cannot find a link with fast reroute? Its not clear what happens if you cannot find the path. [Dhruv] We need to fix the implementors interpretation of RFC 5440 and removed ambiguity. 4.2. Resource Sharing (Haomian Zheng, 10 mins) [80/120] draft-zhang-pce-resource-sharing-11 [Mike] You only talk about PCE request in the draft. If its stateful, there are two LSPs in the association group, its not clear if we change one then it should be applied to another as well. [Haomian Zheng] Approach is applicable to stateful. [Mike] From path computation point of view, if we change one LSP, should we change the other LSP ? I guess [Dhruv] Thats applicable for all associations in the stateful world. [Dhruv - Poll] How many of you read the document? Quite a few people have read the latest draft. Please raise support on the list if there is a 2nd adoption call. 4.3. New TE Constraints (Quan, 10 mins) [90/120] draft-peng-pce-te-constraints-01 4.4. PCEP for BIER-TE (Ran Chen, 10 mins) [100/120] draft-chen-pce-bier-06 [Dhruv] Are there any questions. Thanks for the addressing the comments and clarifying that this document deals with BIER-TE only. Do you have any plans for PCECC for BIER? [Ran Chen] We would like to cooperate on it. [Dhruv] I will reconfirm this with AD and BIER chair on co-ordination. [Dhruv - Poll] How many people have read this document ? Few show of hands [Dhruv - Poll] How many think this work is useful ? Same number. [Dhruv] I will take this to the List. We have adoption queue, bear with us. 4.5. SR Path Ingress Protection (Huaimo Chen, 10 min) [110/120] draft-chen-pce-sr-ingress-protection-02 [Dhruv] Presenter not available yet. [Haomian] He is still not available. [Andrew] Singapore is really warm. [Dhruv] That document was discussed last time. The key question on motivation is still open. [Dhruv] Thank You. Meeting Adjourned.