Re: [Pce] Review of draft-ietf-pce-segment-routing-policy-cp-15 from SR Policy Arch POV

Dhruv Dhody <dd@dhruvdhody.com> Mon, 08 April 2024 16:22 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 53B9AC14CEFF for <pce@ietfa.amsl.com>; Mon, 8 Apr 2024 09:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 9Tv5R70rao0z for <pce@ietfa.amsl.com>; Mon, 8 Apr 2024 09:22:52 -0700 (PDT)
Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 AABAFC151545 for <pce@ietf.org>; Mon, 8 Apr 2024 09:22:52 -0700 (PDT)
Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5a4f7a648dbso2605629eaf.3 for <pce@ietf.org>; Mon, 08 Apr 2024 09:22:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1712593372; x=1713198172; 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=/eGhCPoEA+lx2VrJNFuMXHr3eN/Y7K+e1gXSGuf3K5M=; b=KmlmlJYp/45F5e9MHcbRnInKB/ZTxp+y8Eqpio0acr301loey/GfNPjluHv7QE/jg8 N8UIETutbJFrh1sh+QboUDznaABzz1W8i85ofo571dv2g1awHNpx1bMwff6XWyOmOJlx 0zjVpKiSGMxyMncDpkHxIdaxXm+GG7Lr81EMe+mmscDHLFzCZEh4GCTFCs1L8CKune4I l/+s3xRKWbRATbDBrAhgyGKiJfuzAJhfel6hHMnEiYUAW8M/voc1HC8a+gYKVHeleaM5 4YSf8T7VZmLRcGezKGAAYbxcXVzAJuWonrEhw/VrQXN4P84b5ZW1sqmYs29EoAHYIO7s meww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712593372; x=1713198172; 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=/eGhCPoEA+lx2VrJNFuMXHr3eN/Y7K+e1gXSGuf3K5M=; b=RT8ozYhX+uhXka9M/Ypcv2BtYGhNWziswrL4Eoc9D7ns8dAp0V/I37Y0oVhijkeABj 5buEZc/IicHwSZgtUtTWgoztTguv6s2sKvVmamkOH2CkqJuz2PDhsOHpUfzZ+LuHKKvR EwhBjRmCfrVhAMKZ4erArpIw2nCu3Ou0VpAtZga9EPY26Sf2vDd4YC7hGkqeZfbQnCWi vB3945JTnpX1URx+HrE5hqPHQEo4IRkTHGSUK6j0C/gbtFefwwcYcNBQKDeaNHhQMroL 3cgmZc3xiyBwd+bXxEjDEtC0sVMbGcLz4T6xyL0gkR3zXG9GiuBzEYVhFfaIeEMiEgZ0 lJZA==
X-Forwarded-Encrypted: i=1; AJvYcCVXJmTNjLWPTgQvhgdu9j6KplGIrDfPhapT7is7y7cCb7dtD8Jh77rFKPRKSSV+9qE+61PB3JjyKWkSEKo=
X-Gm-Message-State: AOJu0Yz3tvM0smNwWkkIXIlMNN2LWBC9uWV3yH4COM+2P2+a8uK02z8P jhZfEAjHSdjrc4x2a5/uZLa4zmySD4TRD6nuTIJRQrlM77SzMhn21QHvUYbVnxlA1Lef7k29JwJ e1qt/9FWAUFKoHc83FNZRI7sObNrZuGCVUaN05w==
X-Google-Smtp-Source: AGHT+IEJK2x3JnJJUbNgsAyXQ+DhxmoJ182O9fA0rc7nQyWWvcHbZAEKchc/e2tsKe3HVtt/IdwAGm2TyGSOadnyq/Y=
X-Received: by 2002:a4a:3050:0:b0:5aa:3e8e:e1f with SMTP id z16-20020a4a3050000000b005aa3e8e0e1fmr2573314ooz.5.1712593371558; Mon, 08 Apr 2024 09:22:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPy_uh-ZdomgDmD83=gmBq_0OvA=H8_yXgzMtrZNbsySSQ@mail.gmail.com> <CAB75xn4tzQt7+S4i+RnOvge6gG9nE_KAqSURPHB8gvxy589d4A@mail.gmail.com> <CAH6gdPwkyaNx53BF5CKGLQkBKO-ZTocvHmiA7FgO=FTJ=BPipg@mail.gmail.com>
In-Reply-To: <CAH6gdPwkyaNx53BF5CKGLQkBKO-ZTocvHmiA7FgO=FTJ=BPipg@mail.gmail.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Mon, 08 Apr 2024 21:52:15 +0530
Message-ID: <CAP7zK5Z=knGW+YY4-_bduq5k+Bu=ETAhUqnCXArfinN8ikKugw@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, pce@ietf.org, draft-ietf-pce-segment-routing-policy-cp@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008e941106159837f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/jIF-l9U1uld3fFGR9-rMYj-ssaM>
Subject: Re: [Pce] Review of draft-ietf-pce-segment-routing-policy-cp-15 from SR Policy Arch POV
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2024 16:22:53 -0000

Hi Ketan,

Jumping directly to...

>
>> 15              draft-ietf-pce-segment-routing-policy-cp-15
>>>
>>> 17 Abstract
>>>
>>> 19   Segment Routing (SR) allows a node to steer a packet flow along any
>>> 20   path.  SR Policy is an ordered list of segments (i.e., instructions)
>>> 21   that represent a source-routed policy.  Packet flows are steered
>>> into
>>> 22   an SR Policy on a node where it is instantiated called a headend
>>> 23   node.  An SR Policy is made of one or more candidate paths.
>>>
>>> 25   This document specifies Path Computation Element Communication
>>> 26   Protocol (PCEP) extension to associate candidate paths of the SR
>>> 27   Policy.  Additionally, this document updates [RFC8231] to allow
>>> 28   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
>>> 29   This document is applicable to both Segment Routing over MPLS and to
>>> 30   Segment Routing over IPv6 (SRv6).
>>>
>>>
>>>
>>> *[major] This document has the specifications that actually align the
>>> PCEPextensions (e.g. RFC8664) for SR defined prior to this document to the *
>>> *SR Policy architecture RFC9256. This should be the most important thing
>>> to call out and that this spec formally updates RFC8664 and *
>>> *RFC-draft-ietf-pce-segment-routing-ipv6.*
>>>
>>>
>> Dhruv: Happy for the authors to make it clearer but I don't think there
>> is a need for a formal update. "Update" makes sense when there is some text
>> in those RFCs that require changes. It is just a normal extension. From
>> PCEP POV, SR-MPLS and SRv6 extensions for those path setup types exist on
>> their own. If SR Policy is in use, then of course this document should be
>> used.
>>
>
> KT> What is being signaled via RFC8664 is something that is not defined in
> SR Architecture but those specs are still called SR extensions. Putting a
> formal "update" points readers that this document is what extends those
> previous documents for SR Policy (and thereby SR) extensions.
>
>

Dhruv: It is a classic discussion of what does "update" mean :)
See https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag
Till things change, in PCE WG, we apply "update" only when there is a
change in text in a previously published RFC. I personally would like to
keep it that way. Authors can add text in abstract/introduction to make
your point explicit.

Thanks!
Dhruv

>
>>