Re: [Supa] question on the SUPA data model.

[John Strassner <[e-mail]>]

Hi Leo,

I agree with Joel's comments on Actions. It depends on whether
you are talking **model** or **implementation**.

Assuming you are talking model, you could do this in a number
of ways:

   1) follow a similar course to that outlined in the SNMP blocking
       example, part 1 (section X.1.3), and use a generic
       SUPAPolicyAction. This is good for generic solutions, but
       is NOT YANG. So, this object would be passed to software
       that knew how to translate it to YANG and Netconf.
   2) follow a similar course to that outlined in the SNMP blocking
       example, part 2 (section X.1.4), by creating a subclass of
       SUPAPolicyAction, called (for example)
       SUPAPolicyActionNetConf, and populate its three
       exemplar attributes in a manner similar to that shown

If you are talking what the YANG would look like, or something
else, please let us know, and we're happy to help.

best regards,
John

On Thu, Mar 16, 2017 at 7:44 AM, Joel M. Halpern <[e-mail]>
wrote:

> I am not sure what youa re asking.
> In building an actual policy system, there need to be subclasses of
> "Action".  For example, One might have a subclass which is "invoke YANG
> RPC".  It has attributes for the YANG Verb, the XPATh target and the
> parameters.
> I presume one could have a subclass for "invoke OVSDB configuration".
>
> One might want more specific subclasses to enable better modeling and
> analysis.  So while one might be using YANG for sending policies from a
> higher level system to a lower level one, one could also have a more
> specific class for "configure child policy".  Not sure if it is needed, but
> it is certainly possible.
>
> Yours,
> Joel
>
> On 3/16/17 8:36 AM, youlizhao wrote:
>
>> Hi John,
>>
>>
>>
>> Thanks a lot for your detailed guidance.
>>
>> One remaining question is that, if I want to define an Action, do we
>> follow the similar approach? It seems that it is difficult to define
>> Actions based on a uniform format. Does it mean that we need the Augment
>> clause as defined in the YANG language?
>>
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Leo
>>
>> ------------------------------------------------------------
>> ----------------------------------//
>>
>> /Lizhao (Leo) You, PhD/
>>
>> /Senior Research Engineer/
>>
>> /Huawei Technologies Co.,Ltd/
>>
>> /[e-mail]/ <mailto:[e-mail]>//
>>
>> /Tel: [phone]/
>>
>> /www.linkedin.com/in/lizhao-you/
>>
>> ------------------------------------------------------------
>> ----------------------------------//
>>
>>
>>
>> *From:*John Strassner [mailto:[e-mail]]
>> *Sent:* 2017年3月3日3:57
>> *To:* Liushucheng (Will Liu) <[e-mail]>; John Strassner
>> <[e-mail]>
>> *Cc:* [e-mail]; supa
>> <[e-mail]>; youlizhao <[e-mail]>
>> *Subject:* Re: [Supa] question on the SUPA data model.
>>
>>
>>
>> Hi Will,
>>
>>
>>
>> The answer to your question depends on how you plan to use these five
>> attributes. My **guess** is that you want to use them as variables in
>> condition or action clauses. If this is correct, then there are several
>> ways to model your five attributes; the two simplest are
>>
>>    1) as SUPAEncodedClauses, where the expression involving the
>>        attribute is encoded into an attribute value
>>    2) as SUPAPolicyTerms (e.g., using a combination of
>>        SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue)
>>
>>
>> #1 is the simplest approach; #2 is useful **if** the terms in the
>> SUPAPolicyClause are common objects whose attributes are manipulated.
>> In effect, it makes each of the {variable, operator, value} terms in the
>> canonical form of a SUPAPolicyClause reusable.
>>
>> There is another important difference between the two approaches. A
>> SUPAEncodedClause represents a **complete** SUPAPolicyClause. In
>> contrast, SUPAPolicyTerms are used to define SUPAPolicyVariables,
>> SUPAPolicyOperators, and SUPAPolicyValues as **reusable objects**;
>> this means that you "attach", or "wrap", them to a subclass of
>> SUPAPolicyClause. Put another way, the first method allows you to build
>> a complete SUPAPolicyClause in one object, while the second method
>> allows you to define a SUPAPolicyClause in terms of reusable objects.
>> The second method is preferable when you have to dynamically substitute
>> elements of a SUPAPolicyClause (e.g., variables).
>>
>> The following shows how to build a simple example using both approaches.
>>
>> Let's assume you want to be able to write:
>>
>>    IF source_port == 67
>>
>>
>> Method #1: Using SUPAEncodedClause
>>
>> Defining a SUPAEncodedClause is straightforward, as you are **not**
>> (typically) using any of the SUPAPolicyComponentDecorator subclasses,
>> since the SUPAEncodedClause is, itself, a complete SUPAPolicyClause. You
>> have a single object to represent the entire SUPAPolicyClause, which is
>> an instance of the SUPAEncodedClause class. Its attributes are:
>>
>>    supaEncodedClauseContent:      "IF source_port == 67"
>>    supaEncodedClauseEncoding:    9         // string_instance_id
>>    supaEncodedClauseLanguage:   2         // text
>>    supaEncodedClauseResponse:  TRUE  // this is meant to be set at
>>                                                                    //
>> runtime after evaluation of the
>>
>>                                                                    //
>> clause by the PolicyEngine
>>
>> Now, if you want to say:
>>
>>    IF source_port = 67 OR source_port = 68
>>
>> Then simply modify the text of supaEncodedClauseContent.
>>
>>
>> Method #2: Using SUPAPolicyTerms
>>
>> In this method, the first task is to build three objects:
>>
>>    SUPAPolicyVariable, with its attribute supaPolVarName set to
>>       "source_port" (a string)
>>    SUPAPolicyOperator, with its attribute supaPolOpType set to 6 (which
>>       signifies "equal to")
>>    SUPAPolicyValue, with its attributes supaPolValContent and
>>      supaPolValEncoding set to 67 and 3 (3 means "integer"), respectively
>>
>> These all subclass from SUPAPolicyComponentDecorator, which means that
>> they can decorate a SUPAPolicyClause. Now, the second task is to choose
>> a subclass of SUPAPolicyClause to attach these three objects to. Let's
>> assume that you choose SUPABooleanClauseAtomic. The attribute values of
>> SUPABoolean clause are:
>>
>>    supaBoolClauseIsNegated is set to FALSE
>>    supaBoolClauseBindValue is set to 1
>>    supaBoolClauseIsCNF is set to TRUE
>>
>> Note that in -02 of the IM document, the latter two attributes were
>> defined only in the SUPABooleanClauseComposite class. This has been
>> changed in the upcoming -03 IM document (to be published soon), and all
>> three of the above attributes are moved to SUPABooleanClause, so that
>> they are available to both of its subclasses.
>>
>> Now, if you want to say:
>>
>>    IF source_port = 67 OR source_port = 68
>>
>> Then simply repeat the above procedure to create another set of
>> SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue objects,
>> form another SUPABooleanClauseAtomic object (whose
>> supaBoolClauseBindValue is now set to 2, but whose other attributes
>>
>> remain the same*), and now create a new
>>
>> SUPABooleanClauseComposite object to bind them together.
>>
>>
>>
>> * Note that A OR B is in conjunctive normal form, because it can be
>>
>> seen as the conjunction of the two single-literal clauses. Note also that
>>
>> both A OR B and A AND B can also be seen as being in DNF.
>>
>>
>>
>>
>>
>> best regards,
>>
>> John and Joel
>>
>>
>>
>> On Thu, Feb 16, 2017 at 12:20 AM, Liushucheng (Will)
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Hi all,
>>
>>
>>
>>     I received a question to SUPA data model from a developer. I’m
>>     forwarding it here so that the discussion here will help other
>>     developer to better understand how to use supa data model.
>>
>>
>>
>>     --start—
>>
>>     Dear SUPA YANG model authors,
>>
>>
>>
>>     Thanks for drafting the SUPA Generic Policy YANG data model
>>     (draft-ietf-supa-generic-policy-data-model-02), and it explains the
>>     concept well. However, I met some difficulties when applying the
>>     data model to real systems. In particular, I tried to define an ECA
>>     YANG model, and used the ECA YANG model to develop a real working
>>     system.
>>
>>
>>
>>     In my system, there are some concrete elements such as <source_ip,
>>     source_port>, <dest_ip, dest_port>, port_bandwidth, and ECA policies
>>     are defined on these elements. I wondered how to deal with these
>>     elements/policies in the Generic YANG model
>>     (draft-ietf-supa-generic-policy-data-model-02)? (e.g., enrich some
>>     container?)
>>
>>
>>
>>     I would greatly appreciate it if you kindly give me some advice.
>>     Many thanks!
>>
>>
>>
>>     Regards,
>>
>>     Leo
>>
>>     --end--
>>
>>
>>
>>     Regards,
>>
>>     Will (Shucheng LIU)
>>
>>
>>
>>
>>     _______________________________________________
>>     Supa mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/supa
>>
>>
>>
>>
>> --
>>
>> regards,
>>
>> John
>>
>>
>>
>> _______________________________________________
>> Supa mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/supa
>>
>>


-- 
regards,
John