Hi Dhruv, Agreed, let’s skip it. Controlled-ID draft already mentioned state-sync I-D in Section 6, so it can also clarify way to exchange controlled ID ranges if needed (those will be synchronized automatically as part of “any other TLVs encoded in the OPEN object received from the PCC” if decision will be done to include them into Open object).
Regards, Samuel From: Dhruv Dhody <[email protected]> Sent: Tuesday, July 9, 2024 1:43 PM To: Samuel Sidor (ssidor) <[email protected]> Cc: Dhruv Dhody <[email protected]>; Andrew Stone (Nokia) <[email protected]>; [email protected]; [email protected]; pce-chairs <[email protected]> Subject: Re: [Pce] Re: Pending item for draft-ietf-pce-state-sync Hi Samuel, On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> wrote: Hi Andrew, Dhruv, Proposed text looks fine to me. Do we also need to consider future result of discussion for controlled ID? E.g. if decision will be done to use Notification message for ID space advertisement, will we need to synchronize content of those on top of TLVs from Open object? Personally, I consider controlled ID (and PCECC) to be out of scope of the state-sync I-D. We can make that explicit in the I-D. In future another specification can tackle it if there is a need and can use the technique that you suggest. Thanks! Dhruv Thanks, Samuel From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 9, 2024 11:18 AM To: Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; pce-chairs <[email protected]<mailto:[email protected]>> Subject: [Pce] Re: Pending item for draft-ietf-pce-state-sync Hi Andrew, On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Dhruv, PCE WG Thanks for bringing this up again. PcNotif object with an add/remove semantics is exactly what I was thinking about as well in terms of how to carry this. I think we could (later) expand this to PCC->PCE communication to permit on-the-fly updates/changes to PcOpen criteria to avoid requiring session flap should knobs be flipped. With that said, I do like the proposed scoping of this via notification type so that way delete mechanics can only be applied for state sync. Minor recommendation to clarify the PcNtf should be sent before StateSync / PcRpt messages: On session establishment with a state-sync PCE, the PCE MUST also exchange notifications for each of the PCCs it already has a session established prior to State Synchronization described in section 3.2. Dhruv: I suggest adding this here -> * Notification-value=1: Add PCC's Open Information. On session establishment with a PCC, a PCE with state-sync capability MUST send this notification to other state-sync PCEs with the SPEAKER- ENTITY-ID TLV with values that identify the PCC and any other TLVs encoded in the OPEN object received from the PCC. On session establishment with a state-sync PCE, the PCE MUST also exchange notifications for each of the PCCs it already has a session established. The PCE MUST exchange this notification prior to the State Synchronization (described in Section 3.2). Note that the PCNtf can be used to carry multiple NOTIFICATION objects, one for each PCC. On receiving this notification, PCE adds the information to its database. Overall text proposal looks good to me. I would assume this belongs in a 3.x section in the document. I suggest that this could be a subsection "3.5.1. Information Received via Open Message from PCC" Thanks! Dhruv Only caveat I can see is there would be no mechanism to potentially carry flag values from the PcOpen object, however, there's currently no flags defined after all these years and I suspect if they ever were defined they likely may not be relevant for state sync anyways. Should it ever be required, it would be straight forward to define a new TLV for pce-state sync to carry that anyways. I do not think we need to handle this now. Thanks! Andrew From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Date: Saturday, July 6, 2024 at 7:52 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, pce-chairs <[email protected]<mailto:[email protected]>> Subject: Pending item for draft-ietf-pce-state-sync CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. Hi, There has been one pending item in draft-ietf-pce-state-sync. During IETF 119, we discussed adding support for the PCE to send the information it received in the PCC's open message to the other state-sync PCEs. Here is my initial proposal of using a new notification type for this purpose. I have some initial text that authors and WG can consider. We can discuss this during IETF 120 as well if required. --- 3.5.1. Information Received via Open Message from PCC To ensure uniform information across all PCEs, each PCE needs to relay the information it receives from the PCCs in the Open message to other PCEs via the state-sync session. This includes various PCC capabilities and parameters such as Maximum Segment Identifier (SID) Depth (MSD). As per [RFC5440], the PCEP Notification message (PCNtf) can be sent by a PCEP speaker to notify its peer of a specific event. A PCE should notify the other state-sync PCEs of the information it receives from the PCCs open message. Section 7.14 of [RFC5440] specify the NOTIFICATION object. This document adds a new Notification-type=TBD6 (Inter-PCE State-sync) and two Notification- values (Notification-value=1 (Add PCC's Open Information) and Notification-value=2 (Remove PCC's Open Information)). For Notification-type=TBD6, the NOTIFICATION object encodes the SPEAKER-ENTITY-ID TLV and any other TLV that can be carried inside the OPEN object as a way to signal the PCC's information it received via the open message to other state-sync PCEs. * Notification-value=1: Add PCC's Open Information. On session establishment with a PCC, a PCE with state-sync capability MUST send this notification to other state-sync PCEs with the SPEAKER- ENTITY-ID TLV with values that identify the PCC and any other TLVs encoded in the OPEN object received from the PCC. On session establishment with a state-sync PCE, the PCE MUST also exchange notifications for each of the PCCs it already has a session established. Note that the PCNtf can be used to carry multiple NOTIFICATION objects, one for each PCC. On receiving this notification, PCE adds the information to its database. * Notification-value=2: Remove PCC's Open Information. On session down with a PCC, a PCE with state-sync capability MUST send this notification to other state-sync PCEs with the SPEAKER-ENTITY-ID TLV with values that identify the PCC to remove the information from the database. A PCE may receive this Notification from multiple PCEs that a given PCC has a session and can use a similar mechanism as described in Section 3.4 to keep the freshest state. In case of the termination of state-sync session, this information is also cleaned up alongside LSP-DB. --- Would this be a good way forward? Am I missing something? Is there any other proposal on the table? Thanks! Dhruv (no-hats!) _______________________________________________ Pce mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
