Hi,
I support publication of this document, but I think there are some
issues that need to be resolved first. See below.
Cheers,
Adrian
===
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
Introduction...
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
([I-D.ietf-pce-segment-routing-policy-cp]).
---
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
explained.
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
Parameter".
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
document.
From: Dhruv Dhody <d...@dhruvdhody.com>
Sent: 04 June 2024 04:50
To: pce@ietf.org
Cc: pce-chairs <pce-cha...@ietf.org>; draft-ietf-pce-pcep-co...@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.
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/
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.
Thanks,
Dhruv & Julien
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
