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
?
In the draft frwkIfCapSetTable, frwkIfCapSetRoleComboTable have the PIB-ACCESS clause
set to : "install-notify" ??? Is it normal ??? Shouldn't they be only
"notify" ???
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.
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