PCE Working Group Meeting – 10:00-12:00 Thursday Morning session I o Chairs: Julien Meuric, Dhruv Dhody, Adrian Farrel o Secretery: Hari (Hariharan Ananthakrishnan) o Slide: https://datatracker.ietf.org/meeting/105/session/pce o Etherpad: https://etherpad.ietf.org/p/notes-ietf-105-pce?useMonospaceFont=true o Meetecho: http://www.meetecho.com/ietf105/pce o Video: https://www.youtube.com/watch?v=fcb1sDV2OBM 1. Introduction 1.1. Administrivia, Agenda Bashing (chairs, 5 min) - Welcome Hari as WG Secretery - Thanks to Adrian for serving as Chair during the transition 1.2. WG Status (chairs, 10 min) [15/120] [Loa Anderson] Publication of all drafts in Cluster C340 is 5-6 weeks away. 1.3. State of WG I-Ds and next steps (chairs, 10 min) [25/120] [Zafar Ali] (draft-ietf-pce-pcep-stateful-pce-gmpls) Available for helping. [Rakesh Gandhi] (draft-li-pce-sr-path-segment) PCEP Path segement includes both SR-MPLS and SRv6. While SR-MPLS is a WG doc; SRv6 is not. We need to sort this before adoption call. [Dhruv Dhody] Please talk with the authors from the other docs offline. [Cheng Li] Already did. [Dhruv Dhody] Lets keep Wiki upto date if authors need more work. 2. Stateful PCE 2.1. Operational Clarifications for Stateful PCE (Mike Koldychev, 10 min) [35/120] draft-koldychev-pce-operational-00 [Igor Bryskin] Suggest 'Connection DB' as a better name. 'Path' would be confusing. [Andrew Stone] Regarding the bullet point 'PCReq shall not modify LSB DB'; should it be MAY as PCE may reserve bandwidth against it? Question for the WG. [Adrian Farrel] 1. Be careful about format of DB used in implementations. How DB should be stored is upto your competitors. 2. There are cases related sticky resources where PCReq could modify PCE state. 3. A new I-D by me that updates 8231 clarifying the use of bits. If we are making changes to 8231, we should think if we should bundle the changes. [Mike Koldychev] There is a case where PCReq is used as a probe in which case no state is created. We are open to WG consensus regarding PCE state creation via PCReq. [Lou Berger] Agree with Adrian regarding DB as requirements but conceptually useful and good to have common terminology. Protection Paths - How are we going to represent them? [Mike] That's just associations [Lou] Different ways to model it and leave them uncorrelated or formal linkage. [Mike] We should specify the key for the DB. LSP ID vs Tunnel ID [Lou] Appropriate for YANG data-models. We define the behaviour on wire and not inside the node. [Italo Busi] In TEAS, we are modelling association between tunnels, why not in PCE? [Mike Koldychev] You can have association in Tunnel if every LSP in tunnel is part of the association. But doing association per LSP gives us more flexibility. [Adrian Farrel] We have double disconnect on terminology. A tunnel is a pipe in underlying transport world, in RSVP-TE world a tunnel is a conceptual collection of potential connections we call LSPs. [Igor Bryskin] LSPs in the same Tunnel is by default 'associated', like working and protection; Tunnel can be further associated explicitly. Not sure about association between LSPs in different tunnels. [Tarek Saad] Multiple types of association is possible. Granularity at LSP level is fine but one can still choose to have association between tunnels or LSPs. [Rakesh Gandhi] Association is per LSP, but LSPs can be across different tunnels. That's how this is modelled in TEAS as well. [Mike] Maybe the rule could be made generic. [Dhruv Dhody] Suggestion would be to scope the work between the updates to 8231 (and work with Adrian's draft) and informational clarifications to 8231. The clarifications could be based on message exchange instead of database at rest. [Andrew Stone] Database helps in clarifying how the various fields in wire are interpreted. [Mike] The database change can be triggered via multiple messages, so the message should be less important than the database operation. [Pavan Beeram] Encourage to look in the TE Tunnel YANG modelling work, where lots of things are already considered. 2.2. State Syncronization between Stateful PCEs (Haomian Zheng, 10 min) [45/120] draft-litkowski-pce-state-sync-06 [Dhruv Dhody] This work is referred in our recent published work of Stateful H-PCE and ACTN. [Poll] How many have read? Quite a few [Poll] How many think this is something that the WG should be working on? Similar Number [Poll] Any objection? None 2.3. Mark Objects as optional in Stateful PCE (Haomian Zheng, 10 min) [55/120] draft-dhody-pce-stateful-pce-optional-04 [Tarek Saad] Is there a way to say 'best-effort ignore' of P/I flag? [Dhruv Dhody] Per RFC 5440 P flag in PCReq means that PCE is free to ignore but in this case PCE would try to find path first with the constraint but if path is not found then it is free to ignore it. So this is best-effort. [Tarek] In modelling effort we modelled this behaviour. [Igor Bryskin] How do you handle compromise between two optimization function or constraints? For instance inclusion leads to more delay and ignoring the inclusion leads to less delay. [Haomian Zheng] It is normal for path computation and handled via objective functions. [Igor] We handled this in TE modelling by providing weights to the optimization. [Julien Meuric] Interesting point but beyond the scope of this I-D. [Adrian Farrel] Regarding 8231 updates, you are NOT proposing any changes to 8231, but an extension. [Haomian] Yes. 2.4. Vendor Information Object in Stateful PCE (Cheng Li, 5 min) [60/120] draft-dhody-pce-stateful-pce-vendor-07 [Julien Meuric] This seems correct as it is reusing existing object. Question on the usefulness will be interesting to know from the WG. [Mike Koldychev] Yes, very useful for vendors to implement. [Julien] Could it be an update to 8231? [Dhruv Dhody] You would have to update 8281 as well because of PCInitiate. [Aijun Wang] Is there any restriction in RFC 7470 to receive any TLV in other message. [Dhruv] This doc says we can also carry the VENDOR INFORMATION object, not just the TLV. [Jeff Tantsura] Support this, it is useful. 3. Segment Routing 3.1. Encoding ECMP/UCMP information in PCEP (was 'Supporting Multiple ERO (SID- List) in PCEP') (Mike Koldychev, 10 min) [70/120] [Pavan Beeram] 1. You can still retain existing RBNF if you introduce a sub- object for ingress hop option rather than a new object. 2. What do you mean by different PCEP Tunnel? [Mike Koldychev] Tunnel is identified by PLSP-ID in PCEP. [Dhruv Dhody] PCEP RBNF is different. You need to update it to include ERO List. [Adrian Farrel] How the weighting of traffic across the set is different from flowspec work? Isnt just telling what traffic to put in the LSP. [Mike] Will reply in mailing list [Cheng Li] Why not just use association group? What is the relationship with SR Policy I-D? [Mike] We cant use association group in the first case, because PCC doesn't know in advance how many paths. We could use it for the second case you can group different objectives. [Tarek Saad] You said two approaches are orthogonal but can co-exists. Its confusing. The 1st option is a special case of 2nd. We should be generalizing. [Igor Bryskin] If I ask for 100G path, can PCE return multiple paths say 40G and 60G. [Mike] This is use case 1. You can also give different constraints (use case 2). [Igor] Can PCE provide multiple options with different set of paths? [Mike] Currently its just one. [Jeff Tantsura] We are mixing use-cases. We should de-couple them. 3.2. P2MP SR Policy (Hooman Bidgoli, 10 min) [80/120] draft-hsd-pce-sr-p2mp-policy-00 [Tarek Saad] We should be open to the replication segments on transit node to be shareable. [Hooman Bidgoli] In unicast you have a VRF label but in multicast we are still using P2MP LSP to identify the (S,G). We will work on it. [Cheng Li] Should we maintain some state on the replication node? [Hooman] There is state on the data path. Depending on the implementation there will be a state. [Rishab Parekh] Yes to Tarek comments, it is possible to share the state of replication state. It is feasible, but it comes at a cost. [Julien Meuric] Please continue to discuss on the list. 3.3. SR Path Ingress Protection (Huaimo Chen (remote), 10 min) [90/120] draft-chen-pce-sr-ingress-protection-00 [Dhruv Dhody] Raised questions on the list. Need more explanation on why the backup ingress needs to do the protection when source needs to do this anyway. I guess it is to make the backup path active only when it detects primary ingress failure. Could this be generalize such as reusing flowspec? [Stephane Litkowski] It is similar to path-protection association draft. What is the value add of this draft? [Dhruv Dhody] Difference is w.r.t detection of primary failure. This draft says that its the job of the back ingress and then to switch traffic. 3.4. SR-MPLS Inter-domain (Qilei Wang, 10 min) [100/120] draft-xiong-pce-stateful-pce-sr-inter-domain-01 [Dhruv Dhody] Why path segment is being used for stitching? This needs clarification in SPRING/MPLS first. 4. Other Topics 4.1. Security capability in the PCE discovery (Qin Wu, 5 min) [105/120] draft-ietf-lsr-pce-discovery-security-support-01 [Julien Meuric] 1. LSR WG is the right WG to progress with sharing information to PCE 2. Regarding 2, from PCE standpoint, it is better to remove the restriction now. 4.2. Stitching LSP Association (Qilei Wang, 10 min) [115/120] draft-hu-pce-stitching-lsp-association-01 [Cheng Li] Previous presentation (3.4) should a informational draft. [Qilei Wang] I agree. [Yi Lin] T bit for transit is not necessary. [Qilei] Will pass on the comments to the authors. We can discuss in WG mailing list. [Dhruv Dhody] The usage of path-segment for stitching should be resolved before progressing. Meeting Adjourned, see you in Singapore.