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]
