Hi Jaishal
For what is worth, there was some discussion about this in the past, and
some thoughts are reflected in
https://tools.ietf.org/html/draft-many-pce-pcep-bcp-01#section-4.1.5
In short, IMHO, "attribute-list" goes beyond RFC5440, should take into
account other RFC extensions and it would be great if attributes could
be unified across requests and replies (both in stateless and stateful
aspects) either being used as constraints or as path attributes
In particular, in that draft the idea is to unify "attributes" and add
RRO as another attribute.
the RBNF would be:
<path> ::= <ERO> [<attributes>]
in PCReq
<request> ::= <expansion> |
<p2p_computation> |
<p2mp_computation>
<expansion> ::= <RP><PATH-KEY>
<p2p_computation> ::= <RP><ENDPOINTS>
[<LSP>]
[<attributes>]
in PCRep
<response> ::= <RP> [<monitoring>] [<LSP>]
(<success> | <failure>) [<monitoring-metrics>]
-- Note: should clarify P2MP attributes. P2MP response
-- also includes endpoint-path-pair-list. TBD
<success> ::= <path-list>
<failure> ::= <NO-PATH> [<attributes>]
PCRpt
<solicited-report> ::= <SRP> <LSP> <path>
<unsolicited-report> ::= <LSP> <path>
PCUpd
<update-request> ::= <SRP>
<LSP>
<path>
You may want to check the draft for details,
Just 2 cents, hope it helps a bit. Still, it is not 100% clear how all
extensions can be integrated and unified in a comprehensive and in a
non-ambiguous way.
Ramon
El 02/06/2015 a las 9:29, Shah, Jaishal (Jaishal) escribió:
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce