Charlie, Thanks for the example. A couple of notes.
I appears that in your proposed terminology for Descriptors and Actions it is not clear where Attribute Values appear. Are they the Settings we’ve been using? To your proposal “For simplicity, I suggest that the Policy Keys enable access to the same policies throughout a Domain.” I would point out that in the Naming section (usually Section 4.4 in many of the drafts) we note that the keys are universal to the tenant and analogous to the G-Key. Thus, any Client signaling on behalf of the same tenant will use the same Policy keys. If we want these keys to span multiple tenants the domain concept may be practical but we need to be clear about the scope (is it a G++ key ;) )? Also, we can’t assume much higher order coordination. As to you point about looking at multiple locations for Assigned vs. Embedded (dynamic) rules, it is a known issue. The problem is lifecycle. Dynamic Rules are typically signaled via special instructions in a mobility protocol or, more likely, using another interface. In our case we planned to place them in the Mobility Context just to ensure they disappear with the Context and the Policy subtree does not contain Rules that can come/go quickly and quickly increases the size of the Policy Set (it will be the size of all policies in the system). If we put it in the Policy tree we now have housekeeping of Rule deletion in the Policy tree. It’s a tradeoff. We noticed that using only the Policy Set (no embedded Rule concept) was tough on the over the wire operations. For example we needed either 2 operations, specific order processing (policies before context) for operations and coordination between people working on static policy and the mobility protocol (which is what ultimately killed the design as humans and call processing operate at two different speeds). The other issue was that a lot of create/delete on a large index was not performing well in the DPN or SDN controller. It’s always tradeoffs. For the DPN it knows it needs more work for the Embedded (Context) Rule. The Agent / Client are responsible for installing the pre configured policy on the DPN so that it no blocking occurs when an Assigned Policy is referenced in a Context. From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Charlie Perkins Sent: Sunday, January 28, 2018 11:04 AM To: dmm@ietf.org Subject: [DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc. Hello folks, Policy seems always to be complicated. I wrote up a scenario that, I think, captures many of the complications and relevant areas of application. I also think the explanations about policy management as used in the scenario mostly represent the intention of the text currently in the FPC draft. If the description about how policy is managed for the handover scenario is appropriate, I would like to use it and carry out a slight reorganization of the descriptions in the draft. Regards, Charlie P. ============================================================================== Example for mobile node movement from DPN-1 to DPN-2. MN has two flows: * = F1: best effort traffic * = F2: voice call When MN attaches to the access network of DPN-1, DPN-1 constructs a Mobility Context for MN. It has the following (say, at network entry): * = MN's IP address (MN_IP) * = Policy X for F1 * = Policy Y for F2 * = other stuff (charging ID, current remaining credit, ...) When MN moves to the access network of DPN-2, DPN-2 should receive the Mobility Context for MN from DPN-1, and make the necessary modifications so that the Mobility Context for MN is parameterized for operation with DPN-2. Suppose that for this example, DPN-1 routes all traffic to/from MN through a common gateway G-11. Also suppose that FPC Client has installed two policies on both DPN-1 and DPN-2 -- one for best effort traffic, one for voice. Then DPN-1 might store in the Mobility Context for MN the following rules: * = R1: If (packet belongs to flow F1), then route through G11 * = R2: If (packet belongs to flow F2), then route through G11 * = R3: Else, drop In simplest terms, at DPN-1 don't support any fancy applications, and route all packets through G11. Observe that the actual rules would certainly be different, but I think this is sufficient for the example. As this description of the scenario proceeds, the need for other policies will be considered. How did rules R1, R2, and R3 get installed on DPN-1? Presumably the FPC Client has a list of policies that are supported in the Domain (i.e., operator's network). One policy (X) could be called "Handling-Best-Effort" with Policy-Key P-12 and the other policy (Y) could be called "Handling-Voice" with Policy-Key P-37. Keys P-12 and P-37 are unique within the namespace available to the FPC-Client for data-plane nodes in its Domain. When MN registers at DPN-1, DPN-1 should already have policies P-12 and P-37 available for insertion into MN's mobility context. Let's say that these two policies are in the set of Assigned Policies at DPN-1 and DPN-2, and that the FPC client configures those policies at the time the data-plane topology is established that contains DPN-1 and DPN-2. The FPC Client might have more policies that are pertinent to all flows on the mobile node, and when a mobile node registers at a DPN, the DPN process determines which of those policies are associated with a particular mobile node, according to the flow information that is provided during registration. For our mobile node, suppose that policy P-51 applies to every flow on the mobile node. There might be some other policies that are applied for traffic to/from every mobile node, regardless of the specific credentials or flows supported on that mobile node. These might be Domain policies, or they might be configured only for a particular Interface Group, or both. Domain policies might pertain to a particular class of mobile nodes, such as visitors from another specific domain. This is a matter for discussion. There might be another category of policies that are DPN-specific. Such policies would apply to every Mobility Context resident on a particular DPN, regardless of the particular mobile node. But another DPN might not have any of the policies of the first DPN, or only some of them. Let's call those DPN policies. Back to the scenario where the MN moves from DPN-1 to DPN-2. Suppose that the mobility management system wants to do a smooth handover, and that this requires transferring MN's Mobility Context from DPN-1 to DPN-2. Suppose that on DPN-1 there are DPN-specific policies P-40 and P-41 that apply to the mobile node, and Domain policies P-50 and P-52. This depends on how the policy rules are stored on DPN-1. Here is one possibility: * = DPN-specific policies are not transferred with the Mobility Context * = Domain policy keys P-50 and P-52 COULD be transferred, or we could specify that DPN-2 determines what Domain policies apply even though we would expect them to be the same policies. * = MN-specific policy key P-51 is transferred * = Flow-specific policy keys P-12 and P-37 are transferred. In this formulation, the Mobility Context transfer has to carry the Key information for the relevant policies, but not the full policy definitions. For that to work, DPN-2 has to be able to locate each Policy definition by using only its Policy key. To insure that will work, we might as well specify that all of the policy keys are based on a Domain-wide indexed set of policy definitions. Each of the policies that are likely to be needed at a DPN would be preconfigured at the DPN, and accessible by the Policy Key. I think this is the intention of the collection of Assigned Policies that is mentioned in the current draft. The Assigned Policies could reside on the DPN, and not part of any particular Mobility Context. The process of preconfiguring the Policies on the the DPN should include copying over all the necessary Rule information (Descriptors and Actions) to the local memory of the DPN, and applying DPN-specific Descriptor Values and Action Values as appropriate at the DPN upon which the policies are being preconfigured. Given such a Domain-wide indexed set of Policies and this method of preconfiguration, DPN-2 is almost able to establish the Mobility Context for mobile node MN as part of the smooth transfer. But there are likely to be some mobile-node specific Attribute Values for some of the Descriptor or Action attributes of policies P-51, P-12, and P-37. Depending on the formulation, even Domain policies P-50 and P-52 (as copied into the local memory of DPN-2) might require that some such Attribute values be updated upon arrival of the mobile node MN (e.g., MN's IP address). Consequently, as part of the transfer process for the Mobility Context from DPN-1 to DPN-2, DPN-1 might have to supply some attribute values so that DPN-2 can properly instantiate the rules of the applicable Policies. DPN-2 might determine that flow F1 goes to gateway G21, and flow F2 goes to voice interface gateway G22. These Action treatments are different than what was appropriate for DPN-1. They are not Domain policies, but they might be Interface-Group policies or DPN-specific policies or even mobile-node-specific policies. In any case, we would like to have it that all of the policy definitions are already available on DPN-2 (say, as installed in the list of Assigned Policies at DPN-2) and accessible using the same Policy Keys transferred from DPN-1 as part of the Mobility Context Transfer. When DPN-2 accesses the applicable policies, it also extracts any Attribute Values from the context-transfer message and uses them to complete the instantiation (or, "embedding"?) of all the Policy rules so that the traffic to/from the mobile node can be properly controlled. In this way, Assigned Policies become Requested Policies (or, "embedded"?), using the terminology of the draft. But I think it might be better to have a different name for this. I have elaborated this handover scenario as a way of understanding the various kinds of policies, and where they reside when they are used. For simplicity, I suggest that the Policy Keys enable access to the same policies throughout a Domain. That way, the formulation of an Indexed Set makes good sense and seems to be reasonably manageable at the Domain level. There is a tradeoff between the number of Policies in the Set, versus the level of generality of the Policy definition. The more general the definition, the more Attribute values have to be filled in whenever the policy definition is used within the Mobility Context (or elsewhere). Since we are designing data-plane Information Models for mobility management, we may find that *all* applicable policies should be represented as part of the Mobility Context for a mobile node, even though many such policies would NOT be mobile-node-specific. Alternatively, each DPN would apply some policies to all traffic, and then after that the DPN would apply policies that depend on the particular mobile node. The second alternative would imply that the DPN has two places to look for applicable policies. But still we could specify that all such policies have definitions in a Domain-wide indexed set and have the same Policy Keys. In the example handover I used above, the flows had Policy Keys P-12 and P-37. Flow F2 has the same Descriptors at both DPN-1 and DPN-2, but the Action for flow F2 was different at DPN-2 than it was at DPN-1. We might instead decide that modifying the Action to have a different Gateway is not natural, and would instead apply a new Policy Key to flow F2 at DPN-2. In my mind, it is easier for the purposes of context transfer to have the same Policy but new Action attribute values. Or, we could conceivably transfer Descriptor Keys instead of Policy Keys, since a flow is able to be described by using Descriptors. If there are several FPC-Clients that have access to the same data-plane, then we will have to be very careful to avoid conflicts. But at least I think we would have to mandate that they all use the same Policy Keys, in order to avoid insanity. Also, for each Policy Key, the referenced policy lives in various "states": * = In the Indexed Set, the Policy Key determines a Policy definition * = In the Assigned Policies on a DPN, the Policy Key allows reference to a partially instantiated policy * = After specialization for a particular mobile node and its flows, the Policy Key refers to a fully instantiated (?"embedded"?) policy. Maybe we could put a similar example in an Appendix. =========================================================================== PS. Did I ever mention that I thought Policy stuff is complicated? ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
