[Pce] Re: Pending item for draft-ietf-pce-state-sync

["Samuel Sidor (ssidor)" <[e-mail]>]

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?

Thanks,
Samuel

From: Dhruv Dhody <[e-mail]>
Sent: Tuesday, July 9, 2024 11:18 AM
To: Andrew Stone (Nokia) <andrew.stone=[e-mail]>
Cc: [e-mail]; [e-mail]; pce-chairs <[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Saturday, July 6, 2024 at 7:52 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Andrew Stone (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, pce-chairs <[e-mail]<mailto:[e-mail]>>
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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>