Thanks Ramon for your reply. So if I understand it correctly, attributes is a broadly used term. In PCReq it is the set of constraints to be satisfied in order to bring up the lsp path and in PCReport it is the attributes of the path itself.
Then in case of specific active stateful PCC-PCE interaction, for lsps which are synced to PCE at connection setup, PCE will only have the PCReport sent from the PCC. Later on it may delegate the lsp and allow it to be updated by PCE. How is PCE suppose to know the original set of constraints needed for the lsp while updating the lsp? PCReport only has the current state of the lsp path (bw, metric etc), whereas setup of the lsp path could have different constraints used to bring up that path. I don't believe draft-ietf-stateful-pce clarifies that. Hope I can get some clarification on this. Regards, Jaishal From: Shah, Jaishal (Jaishal) Sent: Tuesday, June 02, 2015 12:29 AM To: '[email protected]' Subject: Clarification regarding path <attribute-list> in PCReport and PCUpdate Hi All, As per draft-ietf-stateful-pce-11 A PCC sending PCRpt to PCE should have following format <state-report> ::= [<SRP>] <LSP> <path> Where: <path>::= <ERO><attribute-list>[<RRO>] <attribute-list> is as per RFC 5440. <attribute-list>::=[<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>] Now, as per RFC 5440, <attribute-list> is part of PCReply and for a PCReply with ERO can have just BW, Metric-list. LSPA and IRO are to be included in PCReply as per 5440 in case of unsuccessful So, does the understanding that PCReport attribute list can have only these objects hold true ? Also I believe these objects would follow the rules for PCReply. Eg P-bit, Bound-bit, Compute-bit etc hold no significance in these objects in PCReport Same will be the case for PCUpdate I believe. It would be great some clarification is shared on this.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
