[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

Adrian Farrel <adrian@olddog.co.uk> Tue, 04 June 2024 16:22 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E74E7C1519A9; Tue, 4 Jun 2024 09:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=olddog.co.uk
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DFRfY-Lla5ep; Tue, 4 Jun 2024 09:22:00 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523E1C151983; Tue, 4 Jun 2024 09:21:56 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com []) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 454GLsQF016096; Tue, 4 Jun 2024 17:21:54 +0100
Received: from vs4.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id BD7DC4604B; Tue, 4 Jun 2024 17:21:53 +0100 (BST)
Received: from vs4.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id B9B1E46043; Tue, 4 Jun 2024 17:21:53 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown []) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 4 Jun 2024 17:21:53 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk []) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 454GLrQr000458 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jun 2024 17:21:53 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dd@dhruvdhody.com>, pce@ietf.org
References: <CAP7zK5aVWhr9LLyG5be8AcAJFDdNBwA=6B0QOamTMatjC0kQVw@mail.gmail.com>
In-Reply-To: <CAP7zK5aVWhr9LLyG5be8AcAJFDdNBwA=6B0QOamTMatjC0kQVw@mail.gmail.com>
Date: Tue, 04 Jun 2024 17:21:53 +0100
Organization: Old Dog Consulting
Message-ID: <0bc801dab69b$4fda8cc0$ef8fa640$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BC9_01DAB6A3.B1A0A270"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI72M2AnqxmPckHRZeNf9+Rrx61xbD1hLAA
Content-Language: en-gb
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=5+xptmow/gGN0GqSIYDmL CR+llIiQM9zYF25cwuFySc=; b=Fd1WBS7uD+QDY5b1fwHhaqKmholnYVOmFHVlZ J4584W4uqc+plcRdumy7kxrmGug0miHGwem0mNd75Q3MX1rzjAxTfmAH+dQVs9/n 44LwwRSAhr1ADGevgqbl+ezm3F5T5vL0Nw4Hkonz/7qvc7aS0ubSpD8YKkm5Tglb 1GnQqV+LHaylPz3OQCIlpjldiKrMK/PpLNVDB18we5CbSYds66Og3lq9vBLyOU5z aRxC4uY13o7tq3/VT1rF/lsmJ3B/IFhrPCkipBcHXzUlbXxD3Ykbcd4w4T4fcFJv 0zlJEjsryqgT1TNe1VfUOVf9zh96NY+SOXFUpwB/IOPJpe1+g==
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--36.793-10.0-31-10
X-imss-scan-details: No--36.793-10.0-31-10
X-TMASE-Result: 10--36.792600-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbDjNGpWCIvfTnOKnAp7gl7WGD9O3ui1h2Ovq WwNc5mGj3Rq1qtW57uNJSlKpmmVj3cYy6jZFocNDF+qQpCWTUjlZoriDkmUBVt9RlPzeVuQQybI K5mqhIFviWLLHGLs4scB9A9jEVdOirsq/7BhdGyAsI6WudaF8azM2xdYG8ZUGd3XtjqAaoMJ8Uw gzqe5YiCNTMMm5OwYk7o8iTOSM7uYz5pZcUDYjcOXYI0z4MDj0IfZjRfGTydhQKAQSutQYXNvSB pmBATJqXMIKyRQ5BD/r8FCU49LDBi6J9Tt/SpAqBe3KRVyu+k3pzMH4wLrl0CDGLLbElle9EXyk 4xN68HgWm/gAtjCd7I/h+VzXVDnD6OH0+FhIoVUEOhHzDsL05m+twLxyosqhNWO9z3c712Sfli2 2ZurwePmNDPvp636/L8pxXHoFnbINzYFS+u/Sm5rIHuCZpMzlGEGBUNvh8GCZ8Jb+wsOjUCdoWc 2nE0EKHGevNb8vUutPAGbwgOqXoMRK6++0DZtA9k5nZzZVBSDYUDvAr2Y/11LQAygrwsvXNInY8 6dvmV4eWvY0xhi7griaLbcqaCznif7LH6WZvauVOwZbcOalS+Museq8CJLLcfnL37UR/jrIcj2m +H71b5+91wAaX/nPS4+CXI3odzVsF8RbNQk8V/rNPkGWAHDfOA3W7N7dBgnHxx/zORRzWsygAl+ yObROpsX84hgxtpqRtLk5L8LNDCxLHUodmiaUQQ5+hY6u+47UoMiU4Mi75SchfAaDKwjQ7/+9sw uISRXT7QbuKj/gda1DnvO5cSZcx7fBXoDaFyF9dWbpg7kae30tCKdnhB58r10pknZXGJqy5/tFZ u9S3M+9+OQ9U/5f33fj+sMArfMaMUyeC0staEkVAPr0TXS8
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-MailFrom: adrian@olddog.co.uk
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: 'pce-chairs' <pce-chairs@ietf.org>, draft-ietf-pce-pcep-color@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [Pce] Re: WGLC for draft-ietf-pce-pcep-color-04
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/TlZatUYlynikhwioOgogzdYW4KA>
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>



I support publication of this document, but I think there are some

issues that need to be resolved first. See below.







Because of the (obvious) risk of confusion of what is meant by "color",

I tried to unpick the references. The important text is in the



   This color attribute is used as a guiding criterion for mapping

   services onto the TE tunnel or policy ([RFC9012]).  The term color

   used in this document is not to be interpreted as the 'thread color'

   specified in [RFC3063] or the 'resource color' (or 'link color')

   specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308].


   Color is part of the tuple that identifies a Segment Routing (SR)

   policy ([RFC9256]) and is included in the Path Computation Element

   Protocol (PCEP) extensions defined for carrying the SR policy

   identifiers ([I-D.ietf-pce-segment-routing-policy-cp]).  The color

   encoding specified in SR policy identifier cannot be reused for other

   types of path setup.


The first paragraph is clear. And I had a quick re-read of 9012 to

establish the meaning. The key text there is, "The color value is user

defined and configured locally." 9012 does not mention "policy" in the

sense you use it here.


The second paragraph is less clear to me. It seems to limit the scope of

"color" to SR, but given the first paragraph, I'm hoping that is not the

intent. Additionally, I think that the final sentence is probably 

outside the scope of this document. Perhaps what you are trying to do

would be better as...


   This color attribute is used as a guiding criterion for mapping

   services onto the TE tunnel [RFC9012] or Segment Routing (SR) policy

   [RFC9256].  The term color used in this document is not to be

   interpreted as the 'thread color' specified in [RFC3063] or the

   'resource color' (or 'link color') specified in [RFC3630], [RFC5329],

   [RFC5305] and [RFC7308].


   In an SR network, color is part to the tuple that identifies an SR

   policy and is included in the Path Computation Element Protocol 

   (PCEP) extensions defined for carrying the SR policy identifiers





The final paragraph of the Introduction is interestingly forward-

looking. While the SR composite candidate paths use case has a 

pointer to an I-D that normatively relies on this draft, the second 

use case (reference a set of path constraints and optimization

criteria) is unexplained and unsubstantiated by a reference. I suggest

to drop it rather than provide a shopping list of potential use cases

that might or might not have any meaning.




Why does this document reference RFC 7525 and not RFC 9325 (see idnits)?




Section 2 discusses "service prefixes" and "service route" but provides

no explanation or reference. I think these terms a loaded and need to be



And, for example, you have:

   BGP Color Extended Community is commonly used to perform service

   mapping, although this specification does not mandate its usage.

But 9012 doesn't mention a "service" or "mapping" at all. 




There is a mismatch in Section 3. You have:


   The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to carry

   the color capability, which allows PCC (Path Computation Client) and

   PCE (Path Computation Element) to determine how incompatibility

   should be handled, should only one of them support color.  An older

   implementation that does not recognize the new color TLV would ignore

   it upon receipt.  This can sometimes result in undesirable behavior.

   For example, if PCE passes color to a PCC that does not understand

   colors, the LSP may not be used as intended.  


But, you immediately counter this with:


   A PCE that has color capability MUST NOT send color TLV to a PCC that

   does not have color capability.  A PCE that does not have color

   capability can ignore color marking reported by PCC.


So, if the second paragraph is true, then the problem pointed out in

the first paragraph never arises.




Section 3 has:


   The color TLV

   is ignored if it shows up in the LSP Object of a message where the

   PCEP Path Setup Type [RFC8408] is Segment Routing or SRv6.


This seems to contradict the text in the Introduction that says:


   Color is part of the tuple that identifies a Segment Routing (SR)

   policy ([RFC9256]) and is included in the Path Computation Element

   Protocol (PCEP) extensions defined for carrying the SR policy

   identifiers ([I-D.ietf-pce-segment-routing-policy-cp]).


If the sole purpose of this document is to assign colors to RSVP-TE

LSPs, then fix the title, abstract, and introduction. If SR is supposed

to be in scope, then explain how this is done.




In section 3:


   If a PCC is unable to honor a color value passed in an LSP Update

   request, the PCC must keep the LSP in DOWN state, and include an LSP

   Error Code value of "Unsupported Color" (9 - Early allocation by

   IANA) in LSP State Report message.


I think s/Error Code/Error-Type/




In section 3:


   When LSPs that belong to the same TE tunnel are within the same Path

   Protection Association Group [RFC8745], the color is attached only to

   the primary LSP.  If PCC receives color TLV for a secondary LSP, it

   SHOULD respond with an error code of 4 (Unacceptable Parameters).


Why would an implementation vary that behaviour? What is the 

accompanying "MAY"?


Can I point out that:

1. You need to say what message is sent and what the resulting

   configuration in the PCC is (no secondary LSP, secondary LSP is down,

   secondary LSP is fine but uncolored).

2. s/error code/Error-Type/

3. Error-Type 4 is called "Not supported object" not "Unacceptable


4. You also need to state the Error-value to use. 

5. I think "Not supported object" is the wrong Error-Type because the

   object *is* supported: it is just not allowed in this place.  So you

   would use (the somewhat over-used) 10 "Reception of an invalid

   object" with a new Error-value that you need to define (compare with

   Error-value 26).



Section 4 is called "TLV Format". Why does it include:


   Section 7.1.1 of RFC8231 [RFC8231] defines STATEFUL-PCE-CAPABILITY

   flags.  The following flag is used to indicate if the speaker

   supports color capability:


      C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports

      color capability must turn on this bit.




Thanks for including Section 7. I guess that some actual code would have

spotted a few of the issues I raised.




I guess we're not bothering with Manageability Considerations (RFC5706,

RFC6123) anymore? There would probably not be a lot to say in this



From: Dhruv Dhody <dd@dhruvdhody.com> 
Sent: 04 June 2024 04:50
To: pce@ietf.org
Cc: pce-chairs <pce-chairs@ietf.org>; draft-ietf-pce-pcep-color@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-color-04


Hi WG,

This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-color-04.


Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome.

The WG LC will end on Tuesday 18 June 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Dhruv & Julien