Hi Samuel, On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) <[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]> > *Sent:* Tuesday, July 9, 2024 11:18 AM > *To:* Andrew Stone (Nokia) <[email protected]> > *Cc:* [email protected]; [email protected]; pce-chairs < > [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) <andrew.stone= > [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]> > *Date: *Saturday, July 6, 2024 at 7:52 AM > *To: *[email protected] < > [email protected]>, Andrew Stone (Nokia) < > [email protected]> > *Cc: *[email protected] <[email protected]>, pce-chairs <[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 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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
