Hi Mrinmoy On Tue, Jan 30, 2024 at 10:43 AM Mrinmoy Das <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
