Subject: [Pce] Clarification regarding path <attribute-list> in PCReport and PCUpdate

From: "Shah, Jaishal (Jaishal)" <[email-masked]>
Date: Tue, 2 Jun 2015 07:29:02 +0000

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.

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 02 Jun 2015 09:41:46 +0200

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ó:
> Now, as per RFC 5440, <attribute-list> is part of PCReply and for a 
> PCReply with ERO can have just BW, Metric-list.
>
> 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
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce