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

Dhruv Dhody <dd@dhruvdhody.com> Tue, 09 July 2024 11:43 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64ECC180B5A for <pce@ietfa.amsl.com>; Tue, 9 Jul 2024 04:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shq8mo9X2JHG for <pce@ietfa.amsl.com>; Tue, 9 Jul 2024 04:43:34 -0700 (PDT)
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FBCC16941B for <pce@ietf.org>; Tue, 9 Jul 2024 04:43:34 -0700 (PDT)
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-25e3d388580so2863170fac.0 for <pce@ietf.org>; Tue, 09 Jul 2024 04:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1720525413; x=1721130213; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EuJiS3mo97DeSXLoBOSyq447DYbXa2Lo6v0bk3zxnLY=; b=M7USFIf66TujqoGQvWT48E6/zv5dspNvHG7dVDwS+U2Zm+Xu0Frm4ymsp6UwDEgpLa d2wVOm74lbba8HSF4OqbMt5g7LZvBJRWINUqzTd4yx4BEA3u1To6gNITaJzE5irwPZD/ doHopvF5OoUP7an+zWvv9/SWuvkWT/sONPrIEIqrlXpaVQVC00s63STz2sdDQFs0mdRr D204tpiOCwijmXltMsMAr4n6wZ+HDauubw/LnMKR0YuYdqOhmCD/HfXa7DsrdxpI8Tju vKdql/yfIJvqm+oltDpH2MyzPyv4NJBD5Ch4VtTyxvx1udWzEMWrgxkaL+h/E/kln+6Z Jv8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720525413; x=1721130213; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EuJiS3mo97DeSXLoBOSyq447DYbXa2Lo6v0bk3zxnLY=; b=nsNsAWnQxhokgFKzmY296+LikiFOYbro8HAyMc+XSLThlvG8UjWZxm7TM+ubOwm9s6 AKh+44zcI2LF6bWNV/ZTl5AFRiOif1TkUkP3tJ5X6oDnCX5Eo5OBkmKVENo8eWZTdVN0 6LnHzJmo5j1TLz9cZHRsZpqGSidbpwCduOYdU1Bx7IM/3ozewCcO3ytfSQ0fjRr8b2FM 6p8b+yofh4UX1oUelb9A4gDAneDPws7KKtAHQj5v7d7qRN0wuWQIscncGF4K2M8f5Kwk eW27ENEOBJl05SOOnGn7kHrboFmK4vfPf3/RgRz6Fy9bbsMuOLdqCFIYIkiyEG+bZg8o E9rA==
X-Forwarded-Encrypted: i=1; AJvYcCXg3aNrXw1UFYh+KN+4g7HfMI0Oc0gzVw3QH3TZmZ/Ul5wsqV/KlW07WrnoOHOBKHBcYAEPWnF/dHR/dlc=
X-Gm-Message-State: AOJu0YxbOfsRroL2sH7K0a6aeKpmMYb5zUMojH8OsP5LQDRNZiftzLD9 l84QRZJcDTdbhHshNqN+jEGTpa8XDrvIAdd9gSHFcoTbXT/MaBEUHwk7l6PC9r91ARiVHb9c5k+ Ubr17D0q8nQa0lXxROxIrXwEtyWBUbkadtW6rXg==
X-Google-Smtp-Source: AGHT+IHGd9Uuf2IlxctMz4bkmzyWkIB6G1LQzH782ZfcLco8Etf3t+XbYwrbDZYM9+vDpmKJJz/GQ8QZd7Q6ty0oJ9Q=
X-Received: by 2002:a05:6870:fb94:b0:25d:4f3c:c072 with SMTP id 586e51a60fabf-25eae7eeb2fmr1947349fac.17.1720525412754; Tue, 09 Jul 2024 04:43:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5Y8AWcs6k7rdZrqzgde2-Ci-9KD8tEb0F+eyEqgDrS==A@mail.gmail.com> <CH0PR08MB7353F0E3A6CE25B899B41CAE91DA2@CH0PR08MB7353.namprd08.prod.outlook.com> <CAB75xn7Envrg0PTparRQ33DV5yPwoakkg+ftc98rmY6QzBwZkA@mail.gmail.com> <IA0PR11MB7792DE3FD67EF6FBACF57191D0DB2@IA0PR11MB7792.namprd11.prod.outlook.com>
In-Reply-To: <IA0PR11MB7792DE3FD67EF6FBACF57191D0DB2@IA0PR11MB7792.namprd11.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Tue, 09 Jul 2024 12:42:56 +0100
Message-ID: <CAP7zK5acAWHHjirAz1KM1NVAEcvf_u4tUc1twA8b-VZP6Gh3rg@mail.gmail.com>
To: "Samuel Sidor (ssidor)" <ssidor@cisco.com>
Content-Type: multipart/alternative; boundary="0000000000000e04ad061ccf0a32"
Message-ID-Hash: YC5DDG6HJLVWANWHE7U2IOGZIHREGDC2
X-Message-ID-Hash: YC5DDG6HJLVWANWHE7U2IOGZIHREGDC2
X-MailFrom: dd@dhruvdhody.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Andrew Stone (Nokia)" <andrew.stone=40nokia.com@dmarc.ietf.org>, "draft-ietf-pce-state-sync@ietf.org" <draft-ietf-pce-state-sync@ietf.org>, "pce@ietf.org" <pce@ietf.org>, pce-chairs <pce-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: Pending item for draft-ietf-pce-state-sync
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/KD5t7AViMxRtPisysxvvtVujGZ0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi Samuel,

On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) <ssidor@cisco.com>
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 <dhruv.ietf@gmail.com>
> *Sent:* Tuesday, July 9, 2024 11:18 AM
> *To:* Andrew Stone (Nokia) <andrew.stone=40nokia.com@dmarc.ietf.org>
> *Cc:* draft-ietf-pce-state-sync@ietf.org; pce@ietf.org; pce-chairs <
> pce-chairs@ietf.org>
> *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=
> 40nokia.com@dmarc.ietf.org> 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 <dd@dhruvdhody.com>
> *Date: *Saturday, July 6, 2024 at 7:52 AM
> *To: *draft-ietf-pce-state-sync@ietf.org <
> draft-ietf-pce-state-sync@ietf.org>, Andrew Stone (Nokia) <
> andrew.stone@nokia.com>
> *Cc: *pce@ietf.org <pce@ietf.org>, pce-chairs <pce-chairs@ietf.org>
> *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 -- pce@ietf.org
> To unsubscribe send an email to pce-leave@ietf.org
>
>