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

From: "Bokaemper, Martin" <[email-masked]>
Date: Mon, 20 Aug 2001 18:58:18 -0400

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.

---

From: "Durham, David" <[email-masked]>
Date: Wed, 22 Aug 2001 11:08:27 -0700

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:[email-masked]]
> Sent: Monday, August 20, 2001 3:58 PM
> To: [email-masked]
> Subject: Incremental state updates from PEP -> PDP in COPS-PR ?
> 
> 
> Hi!
>

---

From: "Bokaemper, Martin" <[email-masked]>
Date: Thu, 23 Aug 2001 18:39:58 -0400

Hi David!

> [...] 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. [...]
>
> Now, if these assumptions prove not to be true in some cases, 
> there are a number of ways to deal with it.

I definitely think that this issue needs to be addressed,
since - as far as I can see - a significant number of 
cases violate that assumption, including the framework-pib
for diffserv.

> 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.

Accounting RPTs can create/update information but they 
can not delete a row.
With this solution I would prefer to see two additional
report-types 'install' and 'delete' corresponding to the
DEC commands 'install' and 'delete'.

> 2. Use multiple Requests with different handles, 
>    reducing the amount of info per Request. [...]

This is the way COPS-RSVP handles 'large active state'.
My understanding of handles is, that they imply independent
object spaces. How could objects be shared between different
handles?
Sharing common objects seems to be one of the main attractions
of PIBs and COPS-PR and is an important part of the diffserv PIB.

One of the solutions you mentioned IMHO needs to get into the 
framework-PIB - or would COPS-PR itself be more appropriate?
Which option would be the best for this case?

ciao,
Martin.
--