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

["Durham, David" <david.durham@intel.com>]

Hi Martin,

This issue has been raised a number of times. The general perception has
been that the request state information for the PEP->PDP is relatively small
compared to the configuration decision information from the PDP->PEP and
changes less frequently. So basically, the operations were optimized for the
latter (although the PIB ultimately decides whether the Request messages
express incremental changes or replacements). It is also more difficult to
for implementations to support incremental state updates in general, so the
benefit of adding incremental support to Requests did not seem to outweigh
the cost/complexity of doing so. 

Now, if these assumptions prove not to be true in some cases, there are a
number of ways to deal with it. 
1. Use Reports to convey the most dynamic information: Ie. Accounting
information, ifindex up and down, etc. Reports do convey incremental updates
in all PIBs.
2. Use multiple Requests with different handles, reducing the amount of info
per Request.
3. Define Notify PIBs that explicitly handle delta changes (add,delete) via
an additional attribute (eg. rowstatus)

-Dave

> -----Original Message-----
> From: Bokaemper, Martin [mailto:MBokaemper@unispherenetworks.com]
> Sent: Monday, August 20, 2001 3:58 PM
> To: rap@ops.ietf.org
> Subject: Incremental state updates from PEP -> PDP in COPS-PR ?
> 
> 
> 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.  
> 
>