Subject: ifIndex rap-frameworkpib-05

From: "Rawlins, Diana" <[email-masked]>
Date: Wed, 08 Aug 2001 12:45:51 +0000

In the July 20, 2001 version of the Framework 
Policy Information Base Section 3.1 Roles 
states in paragraph three that the ifindex 
is opaque to the policy. But then in Section
5, Summary of the Framework PIB under the 
Device Capabilities Group, a PRC is added to 
bind the IfIndex to a RoleCombination. The
RoleCombination attribute identifies some
set of policies and an ifIndex attribute
identifies an unique interface that enforces
the policy set. These two sections are 
incompatible. (Excerpts are inserted below)

I'm repeatedly hearing that both the 
configuration policies and the usage 
feedback policies need to configure and/or
report information on a per "interface" 
basis. There are good reasons that the PDP
DOES need to be aware of the ifIndices and
manage policies accordingly. 

I propose removing the Section 3.1 paragraph
declaring ifindex as being opaque and, in 
addition to the Role Combination and 
Interface Table, adding a PRC that parallels
the MIB-II ifTable but without the counters.
The policy feedback framework can
incorporate the usage related counters into
its PIB.

The following excerpts are from 05 version

" Section 3.1 
Thus, roles provide a way to bind policy to
interfaces without having to explicitly
identify interfaces in a consistent manner
across all network devices.  (The SNMP 
experience with ifIndex has proved this to 
be a difficult task.)  That is, roles provide
a level of indirection to the application of a
set of policies to specific   interfaces.
Furthermore, if the same policy is being applied
to several interfaces, that policy need be 
pushed to the device only once, rather than once
per interface, as long as the interfaces are
configured with the same role combination. 
    
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. "

But later in the same section under the
Interface and Role Combination Table discussion
 
"The Interface and Role Combination Table
describes the association between specific
interfaces with each role combination. It 
answers the questions of which interfaces  
have a specific role combination and what
role combination a specific interface is a 
part of.  The Interface and Role Combination
Table entries each contains a 
<ifIndex, Role Combo> two-tuple to 
accomplish this mapping. "

"FrwkIfCapSetInterfaceEntry ::= SEQUENCE { 
      frwkIfCapSetInterfacePrid     InstanceId, 
      frwkIfCapSetInterfaceIfIndex  InterfaceIndex, 
      frwkIfCapSetInterfaceRoles    RoleCombination 
 }"

-Diana

---

From: MORAND Pierrick FTRD/DMI/CAE <[email-masked]>
Date: Thu, 9 Aug 2001 09:26:58 +0200

A set of additional remarks in addition of those of Diana.
 
If for instance, we consider the following equipment :
[Interface A] : IfIndex = "1" - Role = "A+B", capability="C1"
[Interface B] : IfIndex = "2" - Role = "A+C", capability="C2"
[Interface C] : IfIndex = "3" - Role = "A+C", capability="C2"
[Interface D] : IfIndex = "4" - Role = "A+B+C", capability="C3"
 
My understanding is that the following table will be populated by the PEP
and forwarded to the PDP as following (InstanceId have been omitted):
[frwkIfCapSetTable]
Name = "C1" - PRID = x
Name = "C2" - PRID = y
Name = "C3" - PRID = z
where x,y,z are PRIDs which identify different capability instances and
which are reported by the PEP, within the initial request.
 
[frwkIfCapSetRoleComboTable]
Name = "C1" - Roles = "A+B"
Name = "C2" - Roles = "A+C" 
Name = "C3" - Roles = "A+B+C"
 
[frwkIfCapSetInterfaceTable]
IfIndex = "1" - Role = "A+B"
IfIndex = "2" - Role = "A+C"
IfIndex = "3" - Role = "A+C"
IfIndex = "4" - Role = "A+B+C"
 
QUESTION 1
In the above example, are these tables correctly populated ?
 
QUESTION 2
In the draft frwkIfCapSetTable, frwkIfCapSetRoleComboTable have the
PIB-ACCESS clause set to : "install-notify" ??? Is it normal ??? Shouldn't
they be only "notify" ???
 
QUESTION 3
The frwkIfCapSetInterfaceTable PIB-ACCESS clause is currently set to
"install-notify". Is it to give the possibility for the PDP to modify the
role of a given interface using the InterfaceIndex value or should this PRC
also tagged "notify" ?????
 
If it is intentionally tagged "install-notify" how the system should work in
such a case ?
1-The PDP modify the role
2-It sends an unsolicited decision to the PEP
3-PEP sends a report
4-PEP issues a complete request (with the frwkIfCapSetRoleComboTable
updated, since the PEP is the only entity which is able to know with
interface has been assigned a given capability and a given role combination)
5-the PDP computes a new set of policies
6-the PDP sends its decision
7-the PEP send a report
 
What will happen if the PDP changes the InterfaceIndex value or deletes the
instance ? Can the PDP force the role to be "null" ???
 
QUESTION 4
A rule (IPSec rule for instance) shall now precise a tuple formed by <a role
combination, a fwrkIfCapSetName> to identify the set of interfaces on which
the attached policy will apply. Is that correct ?
 
What will happen if the client-type doesn't need to precise any Capability ?
is that allowed ? There would be no frwkIfCapSetEntry instances and the
frwkIfCapSetRoleComboName would be ...... ? "null" or empty string ?
 
QUESTION 5
It doesn't seem it exits a mechanism for the PEP to send an updated request
(incremental request with remove and install <PRID-EDP> PDU). Shall we
consider that each time a new request needs to be issued, all PIB framework
instances shall be re-issued and the PDP shall delete all previous PIB
framework instances ?
 
Thanks in advance for your comments and answers.

-----Message d'origine-----
De : Rawlins, Diana [mailto:[email-masked]]
Envoyé : mercredi 8 août 2001 14:46
À : [email-masked]'
Objet : ifIndex rap-frameworkpib-05

" Section 3.1 

  

-Diana