[Pce] Re: Pending item for draft-ietf-pce-state-sync
Dhruv Dhody <dhruv.ietf@gmail.com> Tue, 09 July 2024 09:19 UTC
Return-Path: <dhruv.ietf@gmail.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 15CA0C19ECB8; Tue, 9 Jul 2024 02:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Rp1e1bukRZvQ; Tue, 9 Jul 2024 02:19:00 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 29F20C169432; Tue, 9 Jul 2024 02:19:00 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id ada2fe7eead31-48febcc8819so1700453137.3; Tue, 09 Jul 2024 02:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720516739; x=1721121539; 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=b2royU64q15YG8EHW9KFMNYyKPCeGu/Ysx8hXCPP/ak=; b=TTFfQ6h7C5ZgzcXCFm06piUmODULroYM6FgkaFOxzsPtNVKNJA2D54/rYTb6zJiQwB i/YIWMdHoI6DCVN6pwDALgyze2FGkwjMU1p1Bx0IhKQc1iEGFED6ksPLu+CyHUAdL+YX 9L3xP9gpGKbIP3t8wO8Wk75uu//JDa33r8Ln44Pv/i0INCXXUJ1lcSXZvhHVMmHq0lsf UtmL61yhIJjUKMlh+oOpHsDxVU1HK49EOBaYGhFVxO7EVbbYPD+Urdg5/qWNlpcFiG4U b4WoSMkUC38RuiybGli81xIlYpEKyOEqmj3/JNTebuSu0+uJRJ1vNCkSnuFNWJx2sj1E MHTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720516739; x=1721121539; 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=b2royU64q15YG8EHW9KFMNYyKPCeGu/Ysx8hXCPP/ak=; b=S4O3OhPYTk/a7odhUpmNHQc6LHKqPVk5pSOvqD/uk6rN+ZX/5VyTfB11zXt8DOLADP ZMe66CK1H+V+Z/YL/6DKmYy+RgpDRisu5CORmlA24XcMrLF8LHw4JLcNrW1t9Bm7QMn7 JfjFhl9oQMMA0DU4kD0xEz1Nr6Cgf+z42lIzKfJONoGPtzwHwZTl7jyXIGNV0YC9s7KH pwik3hRJS+GdjwkxxexZlLJ8/qhxFhdsQpArC6X/mlh9nu3r5RQthqpe6k3YTzGsQoOl qCpD6XQQ+mfTsnredr/BdPlcX7krvqFYSzr8BIexsCTdvN4QVIaw+PIKjuy1mq8zoRm6 h6PQ==
X-Forwarded-Encrypted: i=1; AJvYcCVoD3FFmNflvfP8JBerttHZPG1pQC9jNkGUHu8WnMagnwdnK/QIoMM7cPLxRvtkONaVWS+g51fKiBbLPDtCb2hj6o2sN93gASOT0zvFOmY7Wt3QP2WMrze0Ix1kbfU0nlj8ej5yCoq2ioGBuv3VFAFxwgIfNEA=
X-Gm-Message-State: AOJu0Yw59VVwG1kTUJF2fjyTvulpnDc1FmY1O/QrZF+P6csKCJUPCJvj M2khxSJpt43NHNhWB/77dw7hkwe9fJuF2ePK7GUTCuh8xxmoKpfy3gsJ7BYVlXSyynoarWMTrr1 R3iZLYwFwOXCSXWQ+7zIS/R2cgSF9ZKwg1b8=
X-Google-Smtp-Source: AGHT+IEwJENgIolHKHQU0ouXK3TcsoTdA2+PFlhvFHOkH2utDHlpapzMTw7RbFrQ2ALsIlkgNc3EzJQD/UbbhBW6RAQ=
X-Received: by 2002:a05:6102:c49:b0:48f:ebc3:a006 with SMTP id ada2fe7eead31-490321474f6mr1782118137.15.1720516738698; Tue, 09 Jul 2024 02:18:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5Y8AWcs6k7rdZrqzgde2-Ci-9KD8tEb0F+eyEqgDrS==A@mail.gmail.com> <CH0PR08MB7353F0E3A6CE25B899B41CAE91DA2@CH0PR08MB7353.namprd08.prod.outlook.com>
In-Reply-To: <CH0PR08MB7353F0E3A6CE25B899B41CAE91DA2@CH0PR08MB7353.namprd08.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Tue, 09 Jul 2024 10:18:21 +0100
Message-ID: <CAB75xn7Envrg0PTparRQ33DV5yPwoakkg+ftc98rmY6QzBwZkA@mail.gmail.com>
To: "Andrew Stone (Nokia)" <andrew.stone=40nokia.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a55b0061ccd0506"
Message-ID-Hash: 55OYLQXGE5YEJM6G2YO76PPHP6OP3ONA
X-Message-ID-Hash: 55OYLQXGE5YEJM6G2YO76PPHP6OP3ONA
X-MailFrom: dhruv.ietf@gmail.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: "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/wr1IlMR0loj59-Zaq3T9obHE0go>
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 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
>
- [Pce] Pending item for draft-ietf-pce-state-sync Dhruv Dhody
- [Pce] Re: Pending item for draft-ietf-pce-state-s… Andrew Stone (Nokia)
- [Pce] Re: Pending item for draft-ietf-pce-state-s… Dhruv Dhody
- [Pce] Re: Pending item for draft-ietf-pce-state-s… Samuel Sidor (ssidor)
- [Pce] Re: Pending item for draft-ietf-pce-state-s… Dhruv Dhody
- [Pce] Re: Pending item for draft-ietf-pce-state-s… Samuel Sidor (ssidor)