[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions on framework-pib07
I have some questions about the management of Role-Combinations as described
in §2.2 of the document "draft-ietf-rap-frameworkpib-07.txt".
>>>> At any later time, the PDP can update the Role-Combinations assigned
>>>> to a specific interface, identified by IfIndex, or for an aggregate,
>>>> identified by IfCapSetName, via an unsolicited decision to the PEP
>>>> on any open request handle. The PDP does this by sending updated
>>>> PRIs for the frwkIfRoleComboTable.
=> I suppose this update is done by the PDP for a given Client-Type, but I
think it would be good to give this precision in the text. Moreover, the
fact that the PDP can proceed using "any open request handle" leads me to
ask/think :
1) this means to me that the update impacts all instances of PIB, as "any
one" can be chosen. Thus all instances of PIB have the same role combos
defined for the interfaces (for a given CT). Is that right ? Isn't it
possible to have different role combos for an interface in different
instances of PIB attached to different Handle on a given Client-Type ? To
rely on an simple example :
Suppose I have two instances of PIB which I activate at different times,
let's say, one for the days of work, one for the week-end. I could decide to
give the role "comptability" during the days of work and "none" during the
week end to a given interface which I don't want to be used "with
"comptability" configuration during the week end.
2) should(n't) the PDP use the active handle to proceed ? is it
implementation specific ?
3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the PDP
when updating the Role-Combinations ??
Following in §2.2 :
>>>> When the Interface Role Combination associations are updated by the
>>>> PDP, the PEP SHOULD send updated ĉfull stateĈ requests for all open
>>>> contexts (request handles).
=> this sentence reenforces the idea I exposed above in 1)...
Therefore, the PEP will modify the required role combinations in all the
instances of PIB attached to the different existing contexts (handles).
Isn't it a bit contradictory with the settlement in §2.4 " [COPS-PR]
supports multiple, disjoint, independent instances of the PIB to represent
multiple instances of configured policy.". I see the same kind of
contradiction with the PEP changing the attribute frwkPibIncarnationActive
when necessary (§2.4), the contradiction coming on the word "independent"...
Let's look rapidly at the way to proceed :
a) when the PEP receives a Role Combination update from the PDP, it passes
this update on all the contexts (request handles) for the considered
Client-type. Then it sends a success report.
b) sending updated full state request is only SHOULD, therefore, if we admit
the Roles-Combinations of the interfaces in the different PIB instances are
the same, I see two possible inconsistencies :
* the update has been done on the PEP's side, but if no full-state
request is sent afterwards, the PDP doesn't have the updated
Role-combinations in its own instances (cf. §2.2 "the PDP must have the
previous request state that it maintained for that request handle").
* if for only some contexts, the PEP has sent updated full-state
request, then on the PDP's side, some context are updated, others are not,
leading to have two different sets of Role-combinations at the same time on
different contexts... which is contradictory to the hypothesis stated in b)
above...
Please correct me if I'm wrong... If not, this means that the document
contains two possible inconsistencies, which could be avoided, for instance
by simply having the PDP update the different contexts on its side once it
has received the success report from the PEP...
Finally, some typos :
* page 23 : fwrPibIncarnationFullState : "It does not have any meaning when
sent from the PDP to the PEP" (instead of PDP in the text)
* page 23 : fwrPibIncarnationFullState : "see section 2.3 for details..."
(instead of section 3.3 in the text)
Thanks for your replies.
Yoann Noisette