Hello Team, Happy New Year! Hope you all are doing fine.
I would like to clarify my understanding of Bandwidth object Type usage and ordering in the PcRpt message. 1. *Ordering:* As per RFC8231 below the Bandwidth object can come under <actual-attribute-list> as well as <intended-attribute-list>. https://datatracker.ietf.org/doc/html/rfc8231#page-25 *6.1 <https://datatracker.ietf.org/doc/html/rfc8231#section-6.1>. The PCRpt Message* The format of the PCRpt message is as follows: <PCRpt Message> ::= <Common Header> <state-report-list> Where: <state-report-list> ::= <state-report>[<state-report-list>] <state-report> ::= [<SRP>] <LSP> <path> Where: <path>::= <intended-path> [<actual-attribute-list><actual-path>] <intended-attribute-list> <actual-attribute-list>::=[<BANDWIDTH>] [<metric-list>] RFC 5440: Section 6.5 specifies <intended-attribute-list> as follows: <attribute-list>::= [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>] So, in response of a PcReply message from PCE, PCC can send Bandwidth in both actual and intended attribute list in following order: *<actual-attribute-list start>* Bandwidth <------- (i) Metric *<actual-attribute-list end>* *<intended-attribute-list start>* LSPA Bandwidth <------(ii) Metric IRO *<intended-attribute-list end>* Is my understanding correct? 2. *Applicability of above ordering in PcRpt in response of PCInit:* Does this same ordering apply to PcRpt for PcInit as well? E.g. Bandwidth object that comes from PcInit will go in <intended-attribute-list> and actual bandwidth of the path will go in <actual-attribute-list>? My understanding is, in case of a positive scenario, both bandwidth will have the same value and PCC can omit reporting bandwidth in the intended list. In case of a negative scenario like PCC couldn't able to setup LSP with specified bandwidth, then it will send PcError. 3. *Bandwidth object Type usage:* Bandwidth object in <actual-attribute-list> should be of Type-2 as per spec below: https://datatracker.ietf.org/doc/html/rfc8231#page-27 Note that the intended-attribute-list is optional and thus may be omitted. In this case, the PCE MAY use the values in the actual-attribute-list as the requested parameters for the path. The actual-attribute-list consists of the actual computed and signaled values of the BANDWIDTH and METRIC objects defined in [RFC5440 <https://datatracker.ietf.org/doc/html/rfc5440>]. 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>]. So, the Bandwidth object under <actual-attribute-list> will always have Type 2. Is that right? So, in any scenario, if PCC reports the state of a LSP(solicited or unsolicited PCRpt), it will always use a Type-2 Bandwidth object to report actual bandwidth of a LSP. Right? Only in case of re-optimization request or when LSP's actual and intended Bandwidth can differ, in those cases Bandwidth of both types may be used. Is this correct understanding? 4. *PcRpt message structure: optional object notation:* https://datatracker.ietf.org/doc/html/rfc8231#page-27 Note that the intended-attribute-list is optional and thus may be omitted. In this case, the PCE MAY use the values in the actual-attribute-list as the requested parameters for the path. above spec lines specifies that reporting of <intended-attribute-list> is optional. But the PcRpt message structure notation is showing it mandatory as follows: *6.1 <https://datatracker.ietf.org/doc/html/rfc8231#section-6.1>. The PCRpt Message* The format of the PCRpt message is as follows: <PCRpt Message> ::= <Common Header> <state-report-list> Where: <state-report-list> ::= <state-report>[<state-report-list>] <state-report> ::= [<SRP>] <LSP> <path> Where: <path>::= <intended-path> [<actual-attribute-list><actual-path>] <intended-attribute-list> <actual-attribute-list>::=[<BANDWIDTH>] [<metric-list>] Shouldn't it be like as follows: Where: <path>::= <intended-path> <actual-attribute-list><actual-path> [<intended-attribute-list>] Please clarify. Thanks & Regards, Mrinmoy
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
