Hi Pavan,
Thanks for the detailed response.
In line…
= Management Considerations =
The PCE working group produced recommendations to guide the inclusion of
manageability considerations sections in documents that it produces.
Those recommendations made a positive difference to the quality of the
RFCs published via the working group. With the publication of RFC 5706,
the PCE working group published RFC 6123 to capture a historic record of
its recommendations, and delegate the responsiblity for specifying the
need for manageability considerations to RFC 5706. Nevertheless, it is
disappointing that this document breaks with the common practice in the
PCE working group to consider the manageability of protocol extensions.
This document allows a PCE to assign a color to the path that it
supplies to the PCC so that the PCC may determine how/whether to place
traffic on the path. This assumes that policies are configured at the
PCC to give meaning to the different colors. However, there is no
discussion of how that policy is configured. This would appear to be a
deficiency. While the document is OK to say...
The mechanism used at the PCC for appropriately mapping services onto
a TE path that is tagged with a color attribute is outside the scope
of this document.
...discussion of the manageability and diagnostic features (or at least
requirements) is needed in order that an implementation of this document
has any value.
Furthermore, an external management station is unable to ask the PCC
what color-based policies it has in place in order that it may verify
correct operation and synchronise the meaning of the colors with the
PCE.
[VPB] The WG can discuss the proposal to make the "Manageability
Considerations" mandatory for all PCEP protocol documents in a separate thread.
[AF] I agree. That is a separate discussion.
That said, we (the authors) will send a separate email proposing text for the
"Manageability Considerations" section and incorporate it into the document
based on feedback.
[AF] I’d appreciate that, and look forward to seeing the thread.
6123 may give you some guidance.
Nothing as strong as a security considerations section is needed, but it is
helpful to indicate to implementers and deployers what they need to think about
to manage the protocol extension.
= Technical Issues =
RFC 9168 defines how to associate "Flow Specs" with paths supplied by a
PCE. This allows the PCC to understand how to classify traffic and
determine on which path the traffic should be sent. It seems, from a
high level, that the color attribute defined in this document is "just"
another policy attribute that helps the PCC classify traffic. It is not
clear, therefore, why it was decided to specify a new PCEP extension
rather than extend the process defined in RFC 9168.
[VPB] The draft uses a generic PCEP TLV (and has since the document's
inception) to associate an intent or objective (color) with a TE tunnel. Given
that the document has reached this stage, it is safe to assume that there was
consensus in the WG to use this TLV. AFAIK there was no discussion or debate
during the WG process on whether the draft could have used an alternative
encoding mechanism.
[AF] I won’t make any assumptions about WG consensus. It is not for me to call
or claim anything about the consensus. But, it is odd to say that the absence
of discussion is evidence for consensus.
I guess it remains unclear why it was decided to specify a new generic TLV
rather than build on 9168.
Section 1 says that the mechanisms introduced in this document "are not
to be used" when the extensions defined in [I-D.ietf-pce-segment-
routing-policy-cp] are used. But Section 2 only says "SHOULD NOT". This
is inconsistent. Furthermore, there is no explanation of why an
implementation MAY choose to use them given that the next sentence says
that an implementation of [I-D.ietf-pce-segment-routing-policy-cp] must
ignore them.
I am also a little bothered that this specification seems to be trying
to dictate how an implementation of another specification will behave.
[VPB] In version 09 of the document, the "SHOULD NOT" in Section 2 has been
replaced with "MUST NOT". Please note that an implementation of
[I-D.ietf-pce-segment-routing-policy-cp], which is oblivious to this document,
will not be using the Color TLV.
[AF] MUST NOT is better, thanks.
3.1 has
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports
color capability must turn on this bit.
That would probably be "MUST", but you could better say...
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC indicates
that it supports the color capability defined in this document by
setting this bit.
[VPB] This is addressed in version 09 of the document. The suggested change has
been adopted.
[AF] Thanks
= Editorial =
Section 5.4 deprecates an early allocation made in the PCE registry. It
is, of course, regrettable that the stability promised at the time of the
early allocation turned out to not be the case, and that (according to
the implementation section - for which thank you) there was no need for
early allocation to be made.
The section asks the RFC Editor to delete the whole section. I think
this is a poor idea because we will lose the record of why the
deprecation was made and the registry entry (pointing back to this
document as an RFC) will not be of any help. I recommend that the
section is retained.
[VPB] This is addressed in version 09 of the document. The note to the editor
in this section has been removed.
[AF] Thanks
[I-D.ietf-pce-segment-routing-policy-cp] is referenced normatively in
Section 1 (as it says that an implementation of this document needs to
be aware of that document in order to not use the extensions defined in
this document in circumstances described in the other document). So the
reference needs to be upgraded.
[VPB] This is addressed in version 09 of the document. The reference has been
upgraded.
[AF] OK
3.1 and 3.2
Remove the text saying "early allocation by IANA". This should not be
left in the final RFC.
[VPB] This is addressed in version 09 of the document.
[AF] OK
= Nits =
[AF] All OK
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
