Thanks Dhruv for your clarification. Thanks & Regards, Mrinmoy
On Tue, Jan 30, 2024 at 11:26 AM Dhruv Dhody <d...@dhruvdhody.com> wrote: > Hi Mrinmoy > > On Tue, Jan 30, 2024 at 10:43 AM Mrinmoy Das <mrinmoy.i...@gmail.com> > wrote: > >> 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? >> >> >> > Dhruv: Yes! > > > >> 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. >> >> >> > Dhruv: Your understanding is correct but If for some reason PCC has a > different actual and intended path or attributes, say a local policy, it is > free to use the PCRpt encoding that allows it to signal both. > > > >> 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? >> > > Dhruv: yes! > > > >> >> 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? >> >> >> > Dhruv: Yes, another way to map this to the use of ERO/RRO. > That is if RRO (actual-path) is used, the associated BANDWIDTH of > actual-attribute-list is Type 2. And when Bandwidth is part of > intended-attribute-list it is of Type 1. > If the BANDWIDTH is the same, it MAY be encoded only once! > > > > >> 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. >> >> > Dhruv: Yes! Refer to verified erratum - > https://www.rfc-editor.org/errata/eid5492 > > Thanks! > Dhruv > > > >> Thanks & Regards, >> Mrinmoy >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
