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 protected]> wrote: > 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 protected]> > wrote: > >> 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 >> >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
