Incremental state updates from PEP -> PDP in COPS-PR ?

["Bokaemper, Martin" <MBokaemper@unispherenetworks.com>]

Hi!

The subject line has the short version of the issue, here
is the long one.

Problem background:
The PDP can create/update/delete named objects individually, 
for example send a single object instance or delete one.
In other words it can change decision state incrementally.

Problem:
- The PEP does not seem to have the possibility of 
  incremental updates to the request state:
    - a REQ in COPS-PR has to include all relevant 
      information for the PDP.
    - a second REQ cannot delete specific named objects a 
      previous REQ communicated to the PDP.
  => When changes occur, the whole request state has to
     be retransmitted in the REQ.
- This is not scalable if the PEP's state is large and 
  'active' (changes frequently).
  That however seems to be the case in many applications
  envisioned for COPS-PR - including it's core diffserv 
  application and the associated framework-pib:
  - frwkIfCapSetRoleComboTable
    If someone implements [from draft-ietf-rap-frameworkpib-05]
    > We point out that, in the event that the administrator 
    > needs to have unique policy for each interface, this can 
    > be achieved by configuring each interface with a unique role.
    this table will have one entry per interface.
  - frwkIfCapSetInterfaceEntry
    This table contains one entry per interface anyway.
  I assume every table with 'per-interface' information to
  be potentially 'large & active': Todays access routers
  support >10k interfaces and interface information 
  may change as users connect or disconnect.

To me this looks like a very serious issue as it already 
limits the base diffserv application - and also seems 
to be relevant for draft-jacquenet-ip-te-pib-00.txt 
and draft-ietf-rap-access-bind-00.txt.

I see several potential changes to solve the issue but
I'd like to make sure it is a real problem first - if this 
can already be done in a way that I just don't see, 
please let me know.

Regards,
Martin.

[ From RFC 2748: The COPS Protocol ]
[sect 3.2]
   This essentially means that the PEP SHOULD NOT issue more
   than one REQ (for a given handle) before it receives a corresponding
   DEC with the solicited message flag set. The PDP MUST always issue
   decisions for requests on a particular handle in the order they
   arrive and all requests MUST have a corresponding decision.

[ From RFC 3084: COPS-PR ]
[sect. 6]
   Any relevant changes to the PEP's
   internal state can be communicated to the PDP by the PEP sending an
   updated REQ message.  The PEP is free to send such updated REQ
   messages at any time after a CAT message to communicate changes in
   its local state.
[sect. 6] 
   The PEP MUST acknowledge a DEC message and specify what action was
   taken by sending a RPT message with a "Success" or "Failure" Report-
   Type object with the Solicited Message Flag set in the COPS message
   header.