Re: [Pce] Shepherd Review of draft-ietf-pce-segment-routing-policy-cp-14
Ketan Talaulikar <ketant.ietf@gmail.com> Mon, 08 April 2024 12:03 UTC
Return-Path: <ketant.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 BB19FC14F69A; Mon, 8 Apr 2024 05:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 2fYJABXLL6L5; Mon, 8 Apr 2024 05:03:20 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 69ECDC14F6BE; Mon, 8 Apr 2024 05:03:20 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-56e448d6f9cso728412a12.0; Mon, 08 Apr 2024 05:03:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712577799; x=1713182599; 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=0tSc1cacbJsActFM+Ewf0ZzV8pYfU6Za2+8z3YEurk8=; b=Fnn/AA8eL1NO29GDqRJbF/WZrbtnR5xl6myH9JA59Wbnb3YnGDEUW7mbmhs+0GjW4k flv0fwjca9oRVAJ94zYKUxwjDixyQj+syP5AYRN6E9M0TobcQYN0P0+j7lXRnDVdv3La pkVsX0r7JKOBcgufr9phUI6UarV6ji18bGTJrwokzC6sDmV/x77KrLJsEQhpR6wx6Ry0 NtuhUZzgitb18SNVcSWfnsE717NncpZC4Uilt2oWkqYxTN2e8jlPizlefIaqQz2TzTJl 41K2S98ayR9cQxlfQ46wNCYF9a0/Kw+jvdvUqF1Y7WIsQefFmIJnfCpngJ7JtEY9woc2 FP4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712577799; x=1713182599; 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=0tSc1cacbJsActFM+Ewf0ZzV8pYfU6Za2+8z3YEurk8=; b=w2FUV1AKJxrVdtMS7ViaXWApsSQgDh9eiT3ooFflsPdIwl6o9ekc4vllqvTRtwc/9Q Iw7hC9MsQxkF2WycRAOHZTHSMefb/jNgqIqzUmlLX1Y7tOfDZPUjlIcC9foAWzpC6GZ1 oyF236Zgs9Tp8hmAJ9gTsxBMFC2sX2fQIe0L5WDLKSfrhJp7lOA6/aQI6f1f9zXRloca W0Cu6rfPDREkpXCj4H1oZ2U1/WnoWbJD95nuy0Usj56Z/Nf+jESLkStsLbSjVP8K0moN f8ooqhV1bbp+Cdhjglkev/Bs8RyfgWIpdDNdq7VN15ZL0XQgivQ+u1p8jgWOHE2XquV9 x/yw==
X-Forwarded-Encrypted: i=1; AJvYcCVoGcHOisSR93KXkKzBPi2/QCyPY5gMPF6SeY2TtPhXXd0wXQAEdUd29ouZpECepJbPLoTJVEhXrYGQA5v0hyeuVWkfatUaZEydYE5KpNAkUsXAS7jxDN4GyaVbBx6pHyYwbhSoBggpkKq0QiXooMvBX2bjbyt73aZyQKylc+dMA7TQoeQ=
X-Gm-Message-State: AOJu0YyS9je2CRZqoN7PDXNv6QUByANWdZPY9yglYgan1pqz7YkqFHkX 4p423982Vmdxs0wT0owHNWBOGCv7SehQBuyOC54t8xqvqB+1dPNp/+kqXjoX1g+yOrJQPN5IEKY 7JbtKWuSe/ZYssP5cO4XXW89sGYs=
X-Google-Smtp-Source: AGHT+IHaqsWdYvwdj/vCNqzbW9RGyeQSa3bI3Mh50JRYklyuW/wgDtSsY2YTYUCZa3WDGvasYbfILzlhKznleYGnGD4=
X-Received: by 2002:a17:906:b78e:b0:a51:bd13:96ce with SMTP id dt14-20020a170906b78e00b00a51bd1396cemr3554446ejb.3.1712577798627; Mon, 08 Apr 2024 05:03:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5YzdeEPYyWCZ7Do=sANJzrsKrembpV0o5pFgHc+JKtYsA@mail.gmail.com> <qa2y27bh8dYAu5qTyhXMDljwNDp8TN6rki7KVKNpzo6bAavOvuOvrGzsFuGtcxXuDiVTr4D8_dhFa4fQH6gXQnANu_Ngyd7y308iKkoeWlg=@proton.me> <CAP7zK5agG-ggZHgSbFLbHtjtvfrXLpWz_kRJy4BvuvBkuB655g@mail.gmail.com>
In-Reply-To: <CAP7zK5agG-ggZHgSbFLbHtjtvfrXLpWz_kRJy4BvuvBkuB655g@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Mon, 08 Apr 2024 17:33:07 +0530
Message-ID: <CAH6gdPxn7LbNcZizJYf=2K2kzDpdCrVzoK_kXhzVfDYZSCkmSA@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: Mike Koldychev <mkoldych@proton.me>, draft-ietf-pce-segment-routing-policy-cp@ietf.org, pce@ietf.org, pce-chairs <pce-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005665eb06159497cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/YCQ-YCsPifeRLKywyh6N4t4zWa4>
Subject: Re: [Pce] Shepherd Review of draft-ietf-pce-segment-routing-policy-cp-14
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 12:03:24 -0000
Hi Dhruv, I've also posted my review of the document from the POV of consistency with SR Policy Arch and BGP SR Policy SAFI documents https://mailarchive.ietf.org/arch/msg/pce/xExbrHXRsC66fGUdy5wtvQlbXc4/ I hope these help improve the document by providing a better overall context of these very important PCEP extensions for SR. Thanks, Ketan On Sat, Apr 6, 2024 at 7:46 PM Dhruv Dhody <dd@dhruvdhody.com> wrote: > Hi Mike, Authors, > > Please make a new version of the I-D where you handle the following items. > We can then send the I-D to the IESG. > > (1) Please handle Ketan's concern and add the IANA note as he suggested - > https://mailarchive.ietf.org/arch/msg/pce/ZaYof63GNYdplFUOLo6G6hJlx3c/ > > (2) A few comments/query got missed, please update or respond if no > changes are needed... > > - Section 5.2, I am unsure about the interaction between the unsetting of > P-flag (PCEP speaker does not support the TLV) and the default value (128 > when the TLV is not present). Isn't it a bit weird? > - Section 5.4, Should Oper/Config get a registry for ease of adding new > flags in future? > > (3) Some new comments on checking the diff > > - abstract, s/[RFC8231]/RFC 8231/ (no references in abstract) > - s/ANY/any/ > - RFC 7525 is obsolete by RFC 9325, please update! > > (4) I am working on the shepherd writeup - > https://notes.ietf.org/HziLkaoxS6iYoQ3sOcwk-A?view ; will update in the > datatracker once you post a new version handling these. > > Thanks! > Dhruv > > On Mon, Mar 18, 2024 at 7:40 AM Mike Koldychev <mkoldych@proton.me> wrote: > >> Hi Dhruv, >> >> I've incorporated your changes and all the other comments that I have >> received so far. Hopefully I didn't miss anything. Version 15 is uploaded. >> Thanks a lot for your comments and updates! >> >> Thanks, >> Mike. >> >> On Saturday, March 9th, 2024 at 8:23 AM, Dhruv Dhody <dd@dhruvdhody.com> >> wrote: >> >> Hi Authors, >> >> I have finished the shepherd review of >> draft-ietf-pce-segment-routing-policy-cp-14. Please handle these comments >> before we ship this I-D to IESG. >> >> ## Major >> - Section 5.6, you need to add update: RFC 8231 in the draft metadata. >> This should also be captured in the abstract. The prefered way is to >> clearly identify the text in RFC8231 that is changing with "OLD:" and >> "NEW:" format! >> - Section 8, Security considerations need to also cover the non-SRPA TLVs >> which are not considered in the current text. >> >> ## Query >> - Section 4.1, >> ```` >> If the PCC receives a >> PCInit message with the Association Source set not to the headend IP >> but to some globally unique IP address that the headend owns, then >> the PCC SHOULD accept the PCInit message and create the SRPA with the >> Association Source that was sent in the PCInit message. >> ```` >> What is the purpose of this text? PCC should use the source as set by the >> PCE - isn't it given? Am I missing something? Boris also pointed this out >> in his review. >> >> >> ## Minor >> - Abstract is not very useful for a non-expert. Maybe change something >> like - >> ```` >> OLD: >> A Segment Routing (SR) Policy is a non-empty set of SR Candidate >> Paths, which share the same <headend, color, endpoint> tuple. SR >> Policy is modeled in PCEP as an Association of one or more SR >> Candidate Paths. PCEP extensions are defined to signal additional >> attributes of an SR Policy. The mechanism is applicable to all SR >> forwarding planes (MPLS, SRv6, etc.). >> NEW: >> Segment Routing (SR) allows a node to steer a packet flow along any >> path. SR Policy is an ordered list of segments (i.e., >> instructions) that represent a source-routed policy. Packet flows >> are steered into an SR Policy on a node where it is instantiated >> called a headend node. An SR Policy is made of one or more candidate >> paths. >> >> This document specifies Path Computation Element Communication >> Protocol (PCEP) extension to associate candidate paths of the SR >> Policy. It applies equally to the SR-MPLS and Segment Routing over >> IPv6 (SRv6) instantiations of segment routing. >> END >> ```` >> - Similarly I find Introduction to be very light on details. Consider >> adding text by looking through recently published RFCs for instance. >> - Terminology: >> ``` >> OLD: >> SRPA: SR Policy Association. PCEP ASSOCATION that describes the SR >> Policy. Depending on discussion context, it refers to a PCEP >> object or to a group of LSPs that belong to the Association. >> NEW: >> SRPA: SR Policy Association. A new association type 'SR Policy >> Association' is used to group candidate paths belonging to the SR >> Policy. Depending on discussion context, it can refer to the PCEP >> ASSOCIATION object of SR Policy type or to a group of LSPs that >> belong to the association. >> END >> ``` >> - Section 4, please add this text at the start - >> ```` >> As per [RFC8697], LSPs are associated with other LSPs with which they >> interact by adding them to a common association group. As described >> in [RFC8697], the association group is uniquely identified by the >> combination of the following fields in the ASSOCIATION object: >> Association Type, Association ID, Association Source, and (if >> present) Global Association Source or Extended Association ID, >> referred to as Association Parameters. >> ```` >> - Section 4.2, since none of the TLV are multi-instance. Can we simplify >> this text - >> ```` >> OLD: >> Unless specifically stated otherwise, the TLVs listed in the >> following sub-sections are assumed to be single instance. Meaning, >> only one instance of the TLV SHOULD be present in the object and only >> the first instance of the TLV SHOULD be interpreted and subsequent >> instances SHOULD be ignored. >> NEW: >> This document specifies four new TLVs to be carried in the SRPA object. >> Only one TLV instance of each type can be carried, and only the first >> occurrence is processed. Any others MUST be ignored. >> ```` >> Also applicable to section 5! >> - Section 4.2.2, consider changing the SHOULD to MUST in this section. I >> could not think of a justification for SHOULD here! >> - Section 5.1, >> - please also state what happens if the TLVs are used without the >> exchange of SRPOLICY-CAPABILITY TLV or the corresponding bit is unset. >> Without it, what is the use of adding this TLV? >> - Consider updating the description such as "P-flag: If set to '1' by a >> PCEP speaker, the P flag indicates that the PCEP speaker supports the >> handling of COMPUTATION-PRIORITY TLV for the SR Policy." >> - please add "Unassigned bits MUST be set to '0' on transmission and MUST >> be ignored on receipt." >> - Section 5.2, I am unsure about the interaction between the unsetting of >> P-flag (PCEP speaker does not support the TLV) and the default value (128 >> when the TLV is not present). Isn't it a bit weird? >> - Section 5.3, should the use of this TLV be limited to SR-MPLS? Also can >> ENLP value be converted into a registery maintained at >> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml >> which can be referred by both PCE and BGP? >> - Section 5.4, please add "The unassigned bits in the Flag octet MUST be >> set to zero upon transmission and MUST be ignored upon receipt." Should >> "Invalidation Reasons Flags" get a registry for ease of adding new flags in >> future? In general, can the text in this section be tightened a little bit? >> Examples - be explicit on who is sending and who is receiving for instance. >> Also, consider adding a more detailed example to show the usage of the >> flags better alongside PCEP message exchange. >> - Section 5.5, please add normative reference to >> draft-ietf-pce-binding-label-sid >> - Section 6.5, are you refereing to the registry at >> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, >> in which case it is called "Segment Routing" and not "Segment Routing >> Parameters". Also better to call the new registry being added as >> subregistry. >> - Section 10.2, please make RFC 8253 and RFC 7525 as normative >> references. >> >> ## Nits >> - Expand PCEP and SR in the title >> - Expand PCEP, SRv6 in the abstract >> - Expand MBZ on first use. It is also better to state that the field is >> ignored on receipt >> - Section 4.2.2, add reference to RFC 9256 for Discriminator, as you have >> done for other fields >> - Section 4.2.4, add reference to RFC 9356 for Preference >> - s/there needs to be a separate capability negotiation/a separate >> capability negotiation is useful/ >> - Expand on first use OAM/PM/BFD >> - Section 6, please update the text in subsections where the number of >> assignments in tables do not match the introductory text. >> >> I am also attaching the updated xml that could be a starting point for >> you to work on -15 version. >> >> Thanks! >> Dhruv >> >> >>
- [Pce] Shepherd Review of draft-ietf-pce-segment-r… Dhruv Dhody
- Re: [Pce] Shepherd Review of draft-ietf-pce-segme… Mike Koldychev
- Re: [Pce] Shepherd Review of draft-ietf-pce-segme… Dhruv Dhody
- Re: [Pce] Shepherd Review of draft-ietf-pce-segme… Ketan Talaulikar
- Re: [Pce] Shepherd Review of draft-ietf-pce-segme… Ketan Talaulikar