WG,
As per RFC8231, a PCRpt message can carry a list of <state-report> entries,
where:
<state-report> ::= [<SRP>]
<LSP>
<path>
where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
When the report carries both "actual attributes" and "intended attributes",
there needs to be a way to unambiguously distinguish between the attributes
in each list. With BANDWIDTH, the distinction is provided by the ObjectType
(1 vs 2). The METRIC object, however, does not have that distinction
provided via ObjectType. When intended metric objects and actual metric
objects are contiguous (other objects between these are optional), there
doesn't seem to be a clear way to do the demarcation.
Section 6.1 of RFC8231 seems to hint at the use of the C flag for this.
**
When included as part of the actual-attribute-list,
Object-Type 2 [RFC5440
<https://datatracker.ietf.org/doc/html/rfc5440>] SHOULD be used for
the BANDWIDTH object, and
the C flag SHOULD be set in the METRIC object [RFC5440
<https://datatracker.ietf.org/doc/html/rfc5440>].
**
But this section does not preclude the use of the C flag in the METRIC
object listed in the "intended-attribute-list" block of the PCRpt message.
An implementation may use the C flag in the intended-metric carried in the
PCRpt as a means to request the PCE to send the "computed metric" in the
PCUpd message. If it is mandated that the C flag should not be set in the
METRIC object when listed as part of the "intended-attribute-list", then
the PCC loses the ability to request the PCE to send the "computed metric".
Looking through packet traces from various interoperability reports, I do
see that there is no consistent interpretation of this flag. Any thoughts
on what should be the best practice for this?
Regards,
-Pavan
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
