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

youlizhao <youlizhao@huawei.com> Wed, 22 March 2017 02:41 UTC

Return-Path: <youlizhao@huawei.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F44129436 for <supa@ietfa.amsl.com>; Tue, 21 Mar 2017 19:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRRwnnEBIXNm for <supa@ietfa.amsl.com>; Tue, 21 Mar 2017 19:41:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9CE12702E for <supa@ietf.org>; Tue, 21 Mar 2017 19:41:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJI02739; Wed, 22 Mar 2017 02:41:32 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Mar 2017 02:41:30 +0000
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by nkgeml412-hub.china.huawei.com (10.98.56.73) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Mar 2017 10:41:27 +0800
Received: from DGGEMM505-MBS.china.huawei.com ([169.254.2.200]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Wed, 22 Mar 2017 10:41:21 +0800
From: youlizhao <youlizhao@huawei.com>
To: John Strassner <strazpdj@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "Liushucheng (Will Liu)" <liushucheng@huawei.com>, supa <supa@ietf.org>
Thread-Topic: [Supa] question on the SUPA data model.
Thread-Index: AdKILVdZaFCoHpcMQQSu7QtTJX6F4wLHs30AAsE91ND//59DAIAAYxWA//dDK0A=
Date: Wed, 22 Mar 2017 02:41:20 +0000
Message-ID: <7AD05E972D7A0F47B3368775A9FF85FC9AA9DE@DGGEMM505-MBS.china.huawei.com>
References: <C9B5F12337F6F841B35C404CF0554ACB898C4654@SZXEMA509-MBS.china.huawei.com> <CAJwYUrEv8Af=XNTbmRNm7tkKcTYiA3HF3B8BBWSnZL+UuKQX8g@mail.gmail.com> <7AD05E972D7A0F47B3368775A9FF85FC9A4E4E@DGGEMM505-MBS.china.huawei.com> <d0177c8d-e90b-c335-24df-5c058b4458f8@joelhalpern.com> <CAJwYUrF_axPv+8LTrqFuWoA_PbVr2B51GFhYqRe-cCNu0Kc=Ug@mail.gmail.com>
In-Reply-To: <CAJwYUrF_axPv+8LTrqFuWoA_PbVr2B51GFhYqRe-cCNu0Kc=Ug@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.63.184.92]
Content-Type: multipart/alternative; boundary="_000_7AD05E972D7A0F47B3368775A9FF85FC9AA9DEDGGEMM505MBSchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58D1E45C.026F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4e254d82bbe5d126ba4f57ca3110aafd
Archived-At: <https://mailarchive.ietf.org/arch/msg/supa/5nqda9qyj7Mfs4GvzfJjXllg3c0>
Subject: Re: [Supa] question on the SUPA data model.
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 02:41:39 -0000

Hi John and Joel,

I am sorry for being unclear. I hoped to figure out what the Action YANG model looks like, and how to implement it.

John’s email made me realize there were some discussions (e.g., the SNMP blocking example). I will digest the discussions to see if I can design a similar model for my system.

I thought ECA YANG model should similar to some service models such as L2SM/L3SM which have well-defined properties to follow.  It seems that different systems may have different definitions of Event/Condition/Action, and the meta-YANG model is what SUPA wants to define. Am I correct?

Thanks.

Regards,
Leo

From: John Strassner [mailto:strazpdj@gmail.com]
Sent: 2017年3月17日 4:39
To: Joel M. Halpern <jmh@joelhalpern.com>; John Strassner <strazpdj@gmail.com>
Cc: youlizhao <youlizhao@huawei.com>; Liushucheng (Will Liu) <liushucheng@huawei.com>; supa <supa@ietf.org>
Subject: Re: [Supa] question on the SUPA data model.

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 <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> 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/

/youlizhao@huawei.com/<http://youlizhao@huawei.com/> <mailto:youlizhao@huawei.com<mailto:youlizhao@huawei.com>>//

/Tel: +86-1304-942-7487<tel:%2B86-1304-942-7487>/

/www.linkedin.com/in/lizhao-you/<http://www.linkedin.com/in/lizhao-you/>

----------------------------------------------------------------------------------------------//



*From:*John Strassner [mailto:strazpdj@gmail.com<mailto:strazpdj@gmail.com>]
*Sent:* 2017年3月3日3:57
*To:* Liushucheng (Will Liu) <liushucheng@huawei.com<mailto:liushucheng@huawei.com>>; John Strassner
<strazpdj@gmail.com<mailto:strazpdj@gmail.com>>
*Cc:* draft-ietf-supa-generic-policy-data-model@ietf.org<mailto:draft-ietf-supa-generic-policy-data-model@ietf.org>; supa
<supa@ietf.org<mailto:supa@ietf.org>>; youlizhao <youlizhao@huawei.com<mailto:youlizhao@huawei.com>>
*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)
<liushucheng@huawei.com<mailto:liushucheng@huawei.com> <mailto:liushucheng@huawei.com<mailto:liushucheng@huawei.com>>> 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
    Supa@ietf.org<mailto:Supa@ietf.org> <mailto:Supa@ietf.org<mailto:Supa@ietf.org>>
    https://www.ietf.org/mailman/listinfo/supa




--

regards,

John



_______________________________________________
Supa mailing list
Supa@ietf.org<mailto:Supa@ietf.org>
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John