IETF 121 PCE WG Minutes

Wednesday, 6th November 2024, Session III
15:00 - 16:30 (Dublin, Liffey A)
15:00 - 16:30 (UTC)

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Andrew Stone
• Note Taker: Andrew Stone
• Slides
• Video
• Chat-log
• Meetecho Recording

Introduction

1.1. Administrivia, Agenda Bashing (Chairs, 5 min) [5/90]

1.2. WG Status (Chairs, 10 min) [15/90]

• [Yi lin] - Regarding the ETSI liaison - it is more about asking for the protocols asking for control of the fgOTN. Currently, in CCAMP and PCE, we already have some drafts that analyse using GMPLS and PCEP for control of the fgOTN, this contribution could be one of the responses to the liaison.
• [Dhruv Dhody] - Thanks, it would be good to have a response on the mailing list to include your thoughts.

1.3. State of WG I-Ds, open issues, and next steps (Chairs, 10 min) [25/90]

• [Cheng Li via chat regarding state-sync status-update slide comment] - Update coming after the meeting
• [Quan Xiong via chat regarding draft-ietf-pce-entropy] - Thanks, will add an implementation section in the draft
• [Andrew Stone via mic regarding operational draft] - Yes, there is lots of good content in there, I will reach out to the authors to see the next steps about splitting that up

Segment Routing

2.1 PCEP extensions for Circuit Style Policies (Samuel Sidor, 10 mins) [35/90]
draft-ietf-pce-circuit-style-pcep-extensions

• [Dhruv] - Concerning WGLC, what is the status in SPRING as of now? Was it presented today during the session?
• [Ketan Talaulikar] - Not an author, but authors have asked for WGLC. There are some minor comments to be addressed, which should come soon.
• [Dhruv] - Let's time it appropriately, let SPRING pass first
• [Samuel Sidor] - On the mailing list discussing a corner case, more in the opposite case, SPRING kind of has a dependency on this since SPRING depends on extensions in - PCEP. (post-edited via recording)
• [Dhruv] - The audio was a bit unclear in the room, helpful to write it down
• [Samuel via chat copy-paste since audio speaker in room unclear] - I was just describing that it is more about SPRING CS draft depending on extensions PCEP CS draft (even if that is also not a strong dependency)) rather than the PCEP draft, depending on the SPRING draft.
• [Dhruv] - SPRING doc references a bunch, might need to become a cluster of all three docs going LC around the same time
• [Zafar Ali] - Yes, the authors have asked for the last call, but they are not related and don't need the sequence

2.2 PCEP extensions for SRv6 Policy SID List Optimization (Zafar Ali, 10 mins) [45/90]
draft-ali-pce-srv6-policy-sid-list-optimization

• [Andrew] - We already talked before, and mentioned it in BGP but mentioning it here for PCEP, would be good to have a section about MSD for validations since impacts ERO. Extra SID, and maybe in some cases you don't pop it off, it might overflow
• [Zafar] - Thanks, I will add appropriate text
• [Dhruv] - Not sure, from an encoding pov, what's the benefit of putting in an LSP extended flag
• [Zafar] - To make sure it's per LSP since the unit of signalling is LSP
• [Dhruv] - You mentioned that it needs to be the same for all, we can discuss where to put this, it feels like a property of SR-TE policy itself. On the other side, is it generic enough to put in LSP? Since it's limited to path setup via SRv6. My gut feeling is inside the SR policy container might have worked out better
• [Zafar] - Yeah, from that pov, this is SRv6 specific, that's why we put capability in SRv6.
• [Dhruv] - Also, think about whether capability is needed or not. Do we need the explicit flag to indicate that another flag exists?
• [Zafar] - Capability was added for backward compatibility reasons but depending on the traffic steering you need the indicator.
• [Cheng] - I do agree we need a flag in the SR Policy level and CP level but do not think we need a flag for the SID list. We can't assume that all SID lists have it to reach the endpoint, still discussion offline. Can bring up to mailing list can discuss there.
• [Zaraf] - Sounds good. For the record, as mentioned earlier depending on the type of traffic steered, all the SLs need to get the same treatment. With that in mind, let's discuss if there's ever a case where we have to do per SL
• [Samuel] - Comment about SR policy or not, even if we do something like the policy name is signalled for a CP. Either should be signalled once for complete policy, but we kind of signal with the CP. We do need to duplicate the policy object anyway
• [Zafar] - Agree the unit of signalling for CP is LSP, but happy to have that conversation

Stateful PCE

3.1 PCEP Extensions for updating Open Message content (Andrew Stone, 10 mins) [65/90]
draft-stone-pce-update-open

• [Ketan] - I think perhaps we can learn and borrow from BGP, dynamic capability, and a new message, all the objects can be encoded there with a marking that XYZ message capabilities cannot be modified or cannot be included in open refresh. List which capabilities could be included in both open and open refresh
• [Andrew] - Yes, perhaps in a separate message. Whether or not it can be sent is in the initial open capability itself
• [Andrew] - yes, for gotcha, and if the reference is already there from BGP let's borrow
• [Adrian] - I understand what you want to do and why, and sort of half support doing it, but then things get messy. In particular, how to handle state change is not specified, obviously, you don't want to, but it opens up a mechanism that then needs to be backfilled for everything out there. If you don't, then who?
• [Andrew] - Good question, perhaps another is, should we? Or evolve over time.
• [Adrian] - If it evolves over time, it could be splat in the field
• [Andrew] - Should we examine all existing?
• [Adrian] - That worries me, both sides need to agree. Unfortunately, there's so much stuff out there. I support the idea if we add a flag in the open and say I can tolerate these messages changing, maybe an open refresh TLV, like a bitmap of all the things I suppose open refresh on
• [Andrew] - Right, don't even send me if I don't support and flap
• [Adrian Farrel] - Right, and that might cover a lot, like, if there's a queue of requests because you support function, but now you withdraw that function, what do you do with that queue
• [Andrew] - Yes, it seems similar to Ketan. Describe how I can and cannot support modifying this open
• [John Scudder] - Following up on both of the previous comments. Regarding Ketan, not aware of anyone who implemented dynamic capability or did not have much traction. My impression is that, like what Adrian mentioned, it has pointy bits. Doesn't mean not to do it, but tread carefully. The second part points to another approach on the BGP side - which is also not as successful as one hopes, if changing bits in flight is too painful, you could look at making resetting a session less painful. Make it a low-cost event, but don't have a solution
• [Andrew] - Regarding the first, do you think it's because it is too broad and open? Wondering if what I'm hearing from the group is maybe we should open how to do capability but not backfill, only new stuff
• [John] - Think it's two, one is what you said, going back is painful. For the second part, I think there's potentially a good way forward if we just do this on a going-forward basis
• [Stephane Litkowski] - Isn't this something we can handle like the GR approach, flap the session, keep the state, and do mark and sweep
• [Andrew] - Yes, a lot of implementations keep the state, but you still need to do that sync.
• [Stephane] - Yes, mark and sweep it might be cleaner. Is the flapping session hurting? The time you spend sending over the wire
• [Andrew] - There could be things ongoing, like delegation middle of computing for and alarms going off, etc. But like you and Adrian mentioned, maybe a soft reset kind of thing
• [Andrew] - There could be things ongoing, like delegation middle of computing for and alarms going off, etc. But like you and Adrian mentioned, maybe a soft reset kind of thing
• [Dhruv] - I think it's worth exploring what Stephane mentioned, we also have worked on a state sync optimisation draft, something we can build on in those approaches. Thanks for all the input

3.2 LSP State Reporting Extensions in PCEP (Samuel Sidor, 10 mins) [55/90]
draft-sidor-pce-lsp-state-reporting-extensions

• [Andrew] - The BSID fallback, administratively, is that an update to existing or stand on its own? Extract the BSID fallback on its own document.
• [Dhruv] - Is there something in the RFC that needs to be updated? Or more of an extension?
• [Andrew] - Don't know, existing says send nothing or send, this now says send something, but you might get back something different.
• [Dhruv] - If there's some text now deviating from existing, then it's an update
• [Samuel] - Is that an update even if there's a new capability not applicable to all PCCs?
• [Andrew] - Yeah, true fair enough. My only other comment is the two flags - I quite like it. Thanks.
• [Quan] - Remind, the E flag in the LSP extended flag has been used in the entropy label, so it is better to choose another letter or another flag
• [Samuel] - We can do that thanks for bringing it up
• [Dhruv] - Regarding transit eligibility, if the binding label is assigned, then you are transit eligible. Does it need an explicit signal?
• [Samuel] - Depends, BSID can be used for other purposes and want to explicitly specify. Still want BSID, but not for path computation in PCE. Just the existence of the BSID is not sufficient
• [Ketan] - RFC9256 does talk about BSID in general, and it's one of the ways of steering based on the BSID, and BSID can be assigned regardless of SR Policy. Some implementations do that all the time. Separate indications would be good.
• [Dhruv] - Agreed, I just want this in the document as well. Regarding explicit, is it always strict, or can you have loose explicitly configured?
• [Samuel] - When loose, it can be IRO encoded as ERO.
• [Dhruv] - It makes sense to say that it is about a strict explicit path
• [Samuel] - Yeah, we can update to clarify with the IRO
• [Ketan] - RFC9256 could be loose explicit

Others

4.1 PCEP Extension for Bounded Latency (Quan Xiong, 10 mins) [75/90]
draft-xiong-pce-detnet-bounded-latency

• [Janos Farkas] - Status update on DetNet, recently adopted draft, which will help with solutions. We still have not made any selection yet, discussing it tomorrow - the next step for selection. Many of the extension proposals have been regarding certain queueing proposals. Still not sure what is to be added to PCEP from a DetNet WG perspective
• [Dhruv] - Thanks we can still talk about how fields are encoded while DetNet is figuring other things out. My comment is mainly regarding the sub-object; the document says ERO is only made of the new DetNet sub objects - but don't you need the path info as well? Clarity is currently missing on how this interacts with existing EROs.
• [Janos] - One more note: not sure if this aligns with the DetNet RFC information model. The trigger was the term jitter; my recollection is we use packet-delay-variation, which is more specific
• [Dhruv] - Even in PCEP, we use delay variation. Since you define ERO, you need RRO as well. For DLI type, it's okay to do this, but last time we did something like this for SR-ERO; we had a discussion on the NAI encoding choice due to the flag fields used. In this case, each DLI type has its encoding and it is much cleaner.

4.2 Using PCEP over QUIC connection (Tingting Han, 10 mins) [85/90]
draft-yang-pce-pcep-over-quic

• [Andrew] - The slide mentions PCEP control channel and address families (AF), probably, it is copy-paste from BGP over QUIC because PCEP does not have AF.
• [Tingting] - Yes, we borrowed from BGP
• [Andrew] - I don't see much benefits from QUIC in PCEP. The session is a long-live connection, so there is not much benefit from the initial handshake and no multi-channel benefits such as addressing families in BGP
• [Adrian] - I agree with Andrew's statement, but we do not say that someday QUIC will take over TCP, so we need to run PCEP over Quic. Please have a look at Netconf over QUIC document to make some comparisons and apply them.
• [Dhruv] - Should discuss why this is needed. In discussions with authors, it was mentioned there were some test runs for when the router and controllers are far away, it would be good to get those numbers out to discuss them openly to see if there is an actual need.
• [Tingting] - Thank you