Subject: [Pce] Question on differentiating between "intended metrics" and "actual metrics" in a PCRpt message

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 21 Feb 2022 08:41:36 -0600

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

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 21 Feb 2022 21:50:47 +0530

Hi Pavan,

An important factor to distinguish between the actual and intended
attribute list is the presence of RRO (i.e. <actual-path>) and the order of
objects in the PCRpt message.

If the RRO is present, any attributes encoded before it, are to be
considered as part of <actual-attribute-list> and those after it, as part
of <intended-attribute-list>.

If the RRO is absent, all attributes are part of <intended-attribute-list>.

Am I missing something?

Thanks!
Dhruv

On Mon, Feb 21, 2022 at 8:11 PM Vishnu Pavan Beeram <[email-masked]>
wrote:

> WG,
>
>
> As per RFC8231, a PCRpt message can carry a list of <state-report>
> entries, where:
>
> 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.
>
>
>    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>].
>
>
> **
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 21 Feb 2022 11:14:50 -0600

Dhruv, Hi!

Thanks for the quick clarification!

The mandate that I was missing is that the PCC MUST not include the
<actual-attributes-list> in the PCRpt if it does not include the RRO. I
thought the SR-RRO was optional (even if the LSP is UP/ACTIVE), but it
doesn't seem to be the case.

Regards,
-Pavan

On Mon, Feb 21, 2022 at 10:21 AM Dhruv Dhody <[email-masked]> wrote:

> attribute list is the presence of RRO (i.e. <actual-path>) and the order
> of objects in the PCRpt message.
>
>> 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".
>>
>>