Hi Lyle, I see the analysis you brought, thanks for that. My proposal #2 is not my preference as it was only an attempt to extend and match what Satoru had in mind without losing the value in current descriptors/actions. Maybe it did not help ;-)
I just see that an action value belongs to an actions type. Clearly there are types which don't require a value, e.g. drop. Here value is void and re-usability is ensured, IMO. But moving the value entirely out of action / descriptor I just saw shortcomings. So, you brought examples and arguments against proposal #1 and proposal #2. But I could not conclude if there are any preferences or alternative? Do we leave it as it is now? marco From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com] Sent: Montag, 20. November 2017 15:15 To: Marco Liebsch; dmm@ietf.org Subject: RE: FPC: Move Descriptor-/Action-Value into Rule Marco, Thank you for the write up of both proposals. Forgive the length of the response but I wanted to provide concrete examples based upon the existing data types. Summary, see below for examples and details: - Satoru's Proposal (Proposal 1) - the use of only ID/Type could be replaced by making the Type a U-Key (similar to a registry or identity in YANG). In any arrangement though only the Type could be use. The downside for Proposal 1 is reusability. - Marco's Proposal (Proposal 2) - To make sense the setting MUST not be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to enforce a Rule. Does such an example exist? >>>>>>>>>> My Opinion <<<<<<<<<<<<< I would not pursue Proposal 1 due to the loss of reusability which is a key benefit of entities under the Policy Model. I would not pursue Proposal 2 if we cannot find clear examples that the settings can be placed in other settings locations. I cannot think of an example at this time but I am just one person and hope the team can provide such examples. Lyle >>>>>>>>>> Detail <<<<<<<<<<< Let's take a step back. Consider the IPFilterRule (RFC 6733) to block inbound port 22 traffic (even from itself) "deny in ip from any to assigned 22" Recall that from 6733, "The keyword "assigned" is the address or set of addresses assigned to the terminal." If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making up a new type here) and provide a value of descriptor "in ip from any to assigned 22" you will note the only Setting to deal with here is 'assigned'. In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor example as Descriptor-Definition Descriptor-Id = 222222 Descriptor-Type = IPFilterRule Action-Definition Action-Id = 111111 Action-Type = deny (or drop) Rule-Definition Rule-Id = 21231 Descriptor-Match-Type = AND Descriptor-Reference Descriptor-Id-Reference = 222222 Descriptor-Value = in ip from any to assigned 22 Action-Reference Action-Id-Reference = 111111 We see the tradeoffs clearly in this example, when the value is directly determined by the type as in the deny Action-Type, the Action Reference is quite small. In the case of the Descriptor we see the value is still incomplete and the setting 'assigned' is applied. For Marco's proposal, we will call it Proposal 2: Descriptor-Definition Descriptor-Id = 222222 Descriptor-Type = IPFilterRule Descriptor-Value = in ip from any to assigned 22 Action-Definition Action-Id = 111111 Action-Type = deny (or drop) Rule-Definition Rule-Id = 21231 Descriptor-Match-Type = AND Descriptor-Reference Descriptor-Id-Reference = 222222 Descriptor-Value-Settings = [ assign = ... ] Action-Reference Action-Id-Reference = 111111 For Proposal 1, the use of only ID/Type could be replaced by making the Type a U-Key (similar to a registry or identity in YANG). In any arrangement though only the Type could be used. The result would be the elimination of the Descriptor-Definition and Action-Defintion. The downside for Proposal 1 is reusability. If I wanted to reuse the value "in ip from any to assigned 22" with a different list of Descriptors then it must be redefined in the model. This is due to the fact that 'Descriptor-Id-Reference' points to an entry in the Descriptors-Definitions List. If I made a local key then reuse is possible but now I need a local key for each Descriptor and compound key of Rule-Id / Descriptor-Id <L-Key> in the entry. This also becomes problematic when the Descriptors are smaller than the Identifiers that reference them. For Proposal 2, the idea is to permit settings (variable substitution) to occur within the Rule components. In the I-D we have settings in the following locations: * Interface-Settings in the DPN - Settings that are important for an interface but not required to be known during DPN Selection. * Interface-Settings in the DPN-Type - Settings that are crucial to DPN interface suitability during DPN selection. * Interface-Settings in the DPN-Peer-Group - Settings that MUST be used when the specified DPN-Peer-Group is being communicated to. This is used for inter-operator or cross-border communications. * Policy-Settings in Configurable-Policy - Settings that apply to a Configurable-Policy on a DPN. Recall that Configurable-Policy affects MULTIPLE Mobility-Contexts (Mobility Sessions). * Within a Mobility Context we have * DPN-Settings-Complementary in the DPN-References - Settings applicable to the Embedded-Rule and/or Assigned-Policy-Reference of the DPN. In this case these values are important to the assigned DPN but are not the same value if another DPN was assigned to support the same rules. * Context-Settings-Complementary - Assigned at the Mobility-Context level and impacts one or more DPNs. In our example the value of 'assigned' would be the Delegated-IP-Prefix and placed under the Context-Settings-Complementary. For Proposal 2 to make sense the setting MUST not be in any of the existing Settings locations. Therefore it is a value that MUST NOT be tied to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to enforce a Rule. My question is what example could we come up with that meets this criteria that is not met by adding another Descriptor or Action? I cannot think of one but if we can Proposal 2 makes sense but not necessarily for both Actions and Descriptors. From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch Sent: Thursday, November 16, 2017 9:42 AM To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule Another proposal: To not disrupt descriptors and actions by removing attributes that belong together (ID-Type-Value), what about keeping the current format and apply a new attribute 'x-value-settings' to Descriptor-Reference and Action-Reference respectively? This should follow define once- use many paradigm. Ending up in this: +-[Policy] | +-[Policy-Definition] <Set> | | +-[Policy-Id] <G-Key> (M) | | +-[Rule-Reference] Set (M) | | +-[Precedence] <L-Key> (M) | | +-[Rule-Id-Reference] (M) | +-[Rule-Definition] <Set> | | +-[Rule-Id] <L-Key> (M) | | +-[Descriptor-Match-Type] (M) | | +-[Descriptor-Reference] <Set> | | | +-[Descriptor-Id-Reference] | | | +-[Direction] (O) | | | +-[Descriptor-Value-Settings] (O) | | +-[Action-Reference] <Set> | | +-[Action-Id-Reference] | | +-[Action-Order] | | +-[Action-Value-Settings] (O) | +-[Descriptor-Definition] <Set> | | +-[Descriptor -Id] <L-Key> (M) | | +-[Descriptor-Type] | | +-[Descriptor-Value] | +-[Action-Definition] <Set> | +-[Action-Id] <L-Key> (M) | +-[Action-Type] | +-[Action-Value] marco From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch Sent: Donnerstag, 16. November 2017 16:33 To: dmm@ietf.org<mailto:dmm@ietf.org> Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule Proposal from Satoru: Move Action-Value to [Rule-Definition]->[Action-Reference]. Same for Descriptor-Value, which may go to [Rule-Definition]->[Action-Definition]. Reason: To make sure "Define once, use many" throughout the models. What to change: Current Policy substructure looks as follows: +-[Policy] | +-[Policy-Definition] <Set> | | +-[Policy-Id] <G-Key> (M) | | +-[Rule-Reference] Set (M) | | +-[Precedence] <L-Key> (M) | | +-[Rule-Id-Reference] (M) | +-[Rule-Definition] <Set> | | +-[Rule-Id] <L-Key> (M) | | +-[Descriptor-Match-Type] (M) | | +-[Descriptor-Reference] <Set> | | | +-[Descriptor-Id-Reference] | | | +-[Direction] (O) | | +-[Action-Reference] <Set> | | +-[Action-Id-Reference] | | +-[Action-Order] | +-[Descriptor-Definition] <Set> | | +-[Descriptor -Id] <L-Key> (M) | | +-[Descriptor-Type] | | +-[Descriptor-Value] | +-[Action-Definition] <Set> | +-[Action-Id] <L-Key> (M) | +-[Action-Type] | +-[Action-Value] Proposed updated Policy substructure: +-[Policy] | +-[Policy-Definition] <Set> | | +-[Policy-Id] <G-Key> (M) | | +-[Rule-Reference] Set (M) | | +-[Precedence] <L-Key> (M) | | +-[Rule-Id-Reference] (M) | +-[Rule-Definition] <Set> | | +-[Rule-Id] <L-Key> (M) | | +-[Descriptor-Match-Type] (M) | | +-[Descriptor-Reference] <Set> | | | +-[Descriptor-Id-Reference] | | | +-[Direction] (O) | | | +-[Descriptor-Value] | | | | | +-[Action-Reference] <Set> | | +-[Action-Id-Reference] | | +-[Action-Order] | | +-[Action-Value] | | | +-[Descriptor-Definition] <Set> | | +-[Descriptor -Id] <L-Key> (M) | | +-[Descriptor-Type] | +-[Action-Definition] <Set> | +-[Action-Id] <L-Key> (M) | +-[Action-Type] ________________________________ 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
