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
