Thank you Pavan for considering the suggestions Be well, G/
From: Vishnu Pavan Beeram <vishnupa...@gmail.com> Sent: Tuesday, February 18, 2025 12:02 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> Cc: The IESG <i...@ietf.org>; draft-ietf-pce-pcep-co...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; Andrew Stone (Nokia) <andrew.st...@nokia.com> Subject: Re: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-pcep-color-09: (with COMMENT) 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. Gunter, Hi! Please see inline (prefixed [VPB]) Regards, -Pavan On Wed, Feb 12, 2025 at 9:34 PM Gunter Van de Velde via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Gunter Van de Velde has entered the following ballot position for draft-ietf-pce-pcep-color-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-pcep-color-09 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-pcep-color-09.txt # This draft is a short and nice read. Thank you for the work in this document. I did suggest few editorial edits. # Many thanks to Ron Bonica for the RTGDIR Review. # The OPSDIR review from Adrian Farrel was rather extensive, and i would like to see those discussed further by the authors # In this review you find some non-blocking comments. # Detailed Review # =============== 18 Color is a 32-bit numerical attribute that is used to associate a GV> I assume this is an unsigned integer value, however a numerical could be for example unsigned, signed or floating point. can this be specific? [VPB] The following changes (please see latest version) should address this: Abstract: Color is a 32-bit numerical (unsigned integer) attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g., low latency). Section 3.2: Type has the value 67. Length carries a value of 4. The 'color' field is 4-bytes long, and carries the actual color value (specified as an unsigned integer). A color value of zero is allowed. 20 (e.g., low latency). This document specifies extensions to Path 21 Computation Element Protocol (PCEP) to carry the color attribute. GV> one color attribute, or possible multiple color attributes? [VPB] The following change (please see latest version) should address this: Section 2: Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV appears in the LSP object more than once, only the first occurrence is processed, and any others MUST be ignored. 78 A Traffic Engineering (TE) tunnel or Segment Routing (SR) policy can 79 be associated with an intent or objective (e.g., low latency) by GV> For accuracy, please add references to what exactly is a TE tunnel or a SR policy at first usage? [VPB] Added references to RFC3209 (for TE Tunnel) and RFC9012 (for SR Policy). 78 A Traffic Engineering (TE) tunnel or Segment Routing (SR) policy can 79 be associated with an intent or objective (e.g., low latency) by 80 tagging it with a color. This color attribute is used as a guiding 81 criterion for mapping services onto the TE tunnel ([RFC9012]) or SR 82 policy ([RFC9256]). The term color used in this document is not to 83 be interpreted as the 'thread color' specified in [RFC3063] or the 84 'resource color' (or 'link color') specified in [RFC3630], [RFC5329], 85 [RFC5305] and [RFC7308]. GV> " A Traffic Engineering (TE) tunnel ([RFC9012]) or Segment Routing (SR) policy ([RFC9256]) can be associated with a specific intent or objective (e.g., low latency) by assigning it a color. This color attribute serves as a guiding criterion for mapping services onto the TE tunnel or SR policy. The term color, as used in this document, must not be interpreted as referring to the "thread color" specified in [RFC3063] or the "resource color" (also referred to as "link color") as defined in [RFC3630], [RFC5329], [RFC5305], and [RFC7308]. " [VPB] Updated, as deemed fit. A Traffic Engineering (TE) tunnel ([RFC3209]) or Segment Routing (SR) policy ([RFC9256]) can be associated with an intent or objective (e.g., low latency) by tagging it with a color. This color attribute is used as a guiding criterion for mapping services onto the TE tunnel ([RFC9012]) or SR policy ([RFC9256]). The term color used in this document must not be interpreted as the 'thread color' specified in [RFC3063] or the 'resource color' (also referred to as 'link color') specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308]. 97 This document introduces extensions to PCEP to carry the color 98 attribute tagged with TE paths that are set up using RSVP-TE 99 ([RFC8408]) or Segment Routing (SR) ([RFC8664]) or any other path 100 setup type supported under the stateful PCE model. The only 101 exception where the extensions defined in this document are not used 102 for carrying the color attribute is when an SR path is set up using 103 the extensions defined in [I-D.ietf-pce-segment-routing-policy-cp]. 104 For these SR paths, the associated color is already included as part 105 of the SR policy identifier encoding. GV> " This document defines extensions to the PCEP to carry the color attribute associated with TE paths that are established using RSVP-TE ([RFC8408]), Segment Routing (SR) ([RFC8664]), or any other path setup type supported under the stateful PCE model. The only exception where the extensions defined in this document MUST NOT be used to carry the color attribute is for SR paths established using the extensions defined in [I-D.ietf-pce-segment-routing-policy-cp]. For these SR paths, the associated color is already included as part of the SR policy identifier encoding. " [VPB] Updated, as deemed fit. This document introduces extensions to PCEP to allow a color tag to be assigned to any TE path operated under a stateful PCE model (including those set up using RSVP-TE [RFC8408] or Segment Routing [RFC8664]). The only exception where the extensions defined in this document MUST NOT be used to carry the color attribute is for SR paths established using the extensions defined in [I-D.ietf-pce-segment-routing-policy-cp]. For these SR paths, the associated color is already included as part of the SR policy identifier encoding. 107 The mechanism used at the PCC for appropriately mapping services onto 108 a TE path that is tagged with a color attribute is outside the scope 109 of this document. GV> " The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document. " [VPB] Updated, as deemed fit. The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document, as is any other use of the color tag. 127 In PCRpt, PCUpd, and PCInitiate messages, the LSP object ([RFC8231], 128 [RFC8281]) is a mandatory inclusion and is used to carry information 129 specific to the target LSP. A TLV called the Color TLV (see 130 Section 3.2), which MAY be carried in the LSP object, is introduced 131 in this document to carry the color attribute associated with the 132 LSP. GV> For an accurate understanding, mention that there either can be a single attribute or multiple? if only a single is allowed, then what is the error handling and what should happen if the sender does send multiple color attributes? [VPB] The following change should address this: Section 2: Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV appears in the LSP object more than once, only the first occurrence is processed, and any others MUST be ignored. 154 same Path Protection Association Group, it MUST reject the message 155 carrying the inconsistent color and send a PCErr message with Error- 156 type=19 (Invalid Operation) and error-value=TB2 (Inconsistent color). GV> I suspect that s/TB2/TBD2/ so that the IANA section corresponds [VPB] Fixed in latest version. Kind Regards, Gunter Van de Velde Routing Area Director _______________________________________________ Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org> To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
