Re: [Supa] Information models and Data models

My brief thoughts on SUPA arch is as follows: 

1. Position of the policy engine
Network can be modeled with multiple layers. Policies can be applied to all the layers to achieve requirements from various type of actors.
a) device-level: policy can only be accessed and enforced on one device. The policy controls the dynamic behaviours, e.g. QoS, decapsulation, encapsulation, and forwarding. 
b) network-level: policy can be configured to communicate with multiple network elements. The policy controls the adjustment of technique related network solutions, e.g. L3VPN, L2VPN.
c) service-level: policies are abstracted to be technique independent, and provided for the higher level users. The customer facing policy is provided to reduce the operation on service level agreement, generic VPN service, unified tunnel services.

2. policy engine framework
This is a brief policy engine framework.

higher level event
  ^          + policy operations
  |          |
  |          |
+-+----------v-------+
|                    <------+
|    Policy Engine   |  concrete policy DM
|                    |
+-^------------------+
  |
  |
  + lower level event

The policy engine is configured with concrete policy DMs, so that it can deal with assigned policies. The concrete policy DM can generate data-store and northbound interface for the policy engine.
One or more standard protocols should be selected (e.g., NETCONF, RESTCONF) for policy operations to communicate with the Policy Engine. 
The policy engine runs with monitoring the lower level events from the southbound.
Higher level events may be generated by the policy engine, so that policy engine or applications sitting on a higher level can consume.

3. policy data model
The policy data model describes in detail about the protocol operations and data-store content. It serves as an "API contract" honored by the policy engine, and is essential to the model driven policy API. The well defined policy model structure facilities both flexibility and extensibility.
a) generic policy model: defines a generic policy header and the policy body structure. The generic policy header contains information on, e.g. name, identifier, life cycle, which can be shared by all the specific policy models. The generic policy body could be a ordered list of policy rules. But the details on how the policy rule like is extended by the specific policy model, e.g. ECA policy model.
b) specific policy model: inherits from the generic policy model with specific extensions on the policy rule. For example the ECA policy model extends the policy rule with Event-Condition-Action definition.
c) concrete policy model: is rendered based on the specific model by SDOs, vendors or operators. It represents concrete technique and vendor implementation. For example, a concrete Event, like time event, packet-in.

4. information modeling
How the information model can help data model generation? What should be defined in IM, what in DM?
a) The DM document should be more on how to represent informaitons in YANG, while the IM document can have more words introducing what an item is and why we need an item.
b) The IM helps other DM creation rather than YANG both in and outside IETF.

Best,
Tianran

--------------------------------------------------------------------------------------------------
发件人: Andy Bierman [andy@yumaworks.com]
发送时间: 2016年3月5日 2:01
收件人: Jason Coleman (colemaj)
抄送: King, Daniel; Bert Wijnen (IETF); Joel M. Halpern; John Strassner; Zhoutianran; Nevil Brownlee; SUPA list
主题: Re: [Supa] Information models and Data models - WG adopion?

On Fri, Mar 4, 2016 at 9:29 AM, Jason Coleman (colemaj) <colemaj@cisco.com> wrote:

Sending again w/ the correct email address this time:

>I would like to be part of working on an architecture document as well.

I would like to participate as well, since Bert is willing to take the lead.

It is quite possible I do not understand the development plan implied by the charter.

I was hoping we would end up with the following standards:

  1) one standard way to express a SUPA policy
  2) one standard "SUPA engine" definition that is capable of understanding and enforcing specific policies
      2a) device-level SUPA can only access policy and enforce policy on itself
      2b) controller-level SUPA can be configured to communicate with multiple network elements
   3) one or more standard protocols should be selected (e.g., NETCONF, RESTCONF) for
       communication between (2b) and network elements, to support policy enforcement

IMO, SDOs, vendors or even operators should be able to write SUPA policies.

Andy

>
>As for the information model versus data model discussion, I think that an information model is required to allow for different data models to follow a common structure.
>It is possible to create a data model first, but that data model may not fit in well with other data models.  This is why the information model exists to allow for things that may extend that data model or are in place for other data models.
>
>At this time the focus is on Event, Condition, Action, but there will be further management structures to define.
>The information model supports a general structure and then provides details on ECA.  That general structure is important for future data models as well.
>Those may be YANG or other people may chose to use the information model to create a data model in a different way.
>
>The architecture document would define the role of the information model clearly, which I think that part of the ID that John, Joel, and I worked on attempts to do as well, and then can show how the data models will be supported by the information model and what else the WG Charter has defined and possibly where we go next.
>
>Jason
>
>
>
>On 3/4/16, 7:34 AM, "Supa on behalf of King, Daniel" <supa-bounces@ietf.org on behalf of d.king@lancaster.ac.uk> wrote:
>
>>Hi Bert,
>>
>>Thank for taking the initiative. We can make sure there is time on the agenda for the I-D.
>>
>>BR, Dan.
>>
>>-----Original Message-----
>>From: Bert Wijnen (IETF) [mailto:bwietf@bwijnen.net]
>>Sent: 04 March 2016 10:11
>>To: King, Daniel <d.king@lancaster.ac.uk>; Joel M. Halpern <jmh@joelhalpern.com>; Andy Bierman <andy@yumaworks.com>; John Strassner <John.sc.Strassner@huawei.com>; Zhoutianran <zhoutianran@huawei.com>
>>Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>; SUPA list <supa@ietf.org>
>>Subject: Re: [Supa] Information models and Data models - WG adopion?
>>
>>On 03/03/16 17:41, King, Daniel wrote:
>>> Hi  All.
>>>
>>> We have a placeholder in the SUPA Charter for:
>>>
>>> 1) An explanation of the scope of the policy-based management framework and how it relates to existing work of the IETF.
>>>
>>> A proposal for this document has not been forthcoming thus far. It would seem that a "Policy-based Management Framework" discussing architecture, applicability and relationships ("system overview") would be reasonable content for a framework document mentioned in the Charter?
>>>
>>> Furthermore, Andy, Tianran and Bert all seem willing to support development (via direct contributions) for the framework/architecture document?
>>Dan, I am willing to take initiative on this.
>>
>>I saw in one of Johns postings:
>>    Well, we don't have an architecture document currently in our charter
>>    (though I would support amending the charter to include this). In the
>>    (now expired) proposition draft (which we are now working on to reissue),
>>    there was an exemplary architecture.
>>
>>John, do you have the piece of text in an XML file (I-D source file) and if so, can you send that to me. I assume you are OK with us using that as a starting point?
>>
>>Dan/Nevil, if we submit an in initial I-D timely, do you think we can spend some time on it in our IETF95 session?
>>
>>Thanks,
>>Bert
>>
>>
>>
>>> BR, Dan.
>>>
>>> -----Original Message-----
>>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen
>>> (IETF)
>>> Sent: 03 March 2016 16:13
>>> To: Joel M. Halpern <jmh@joelhalpern.com>; Andy Bierman
>>> <andy@yumaworks.com>; John Strassner <John.sc.Strassner@huawei.com>
>>> Cc: Zhoutianran <zhoutianran@huawei.com>; Nevil Brownlee
>>> <n.brownlee@auckland.ac.nz>; SUPA list <supa@ietf.org>
>>> Subject: Re: [Supa] Information models and Data models - WG adopion?
>>>
>>> Inline
>>>
>>> On 03/03/16 16:48, Joel M. Halpern wrote:
>>>> Two separate but related quesitons.
>>>>
>>>> 1) Can you help use find the places where the model / text is too
>>>> implementation specific?  There are a few places where in describing
>>>> enumerations the model calls for integers.  In the mapping to YANG, I have already started replacing those with Enumerations.  Are there other kinds of over-specificity?
>>>>
>>>> 2) The charter allows for a range of implementations of the SUPA
>>>> system.  Folks may recall I asked in the room at the last meeting
>>>> whether our chartered allowd both communication between a control
>>>> system and a device, and communication between a policy repository and a policy engine.  I was told by the AD that the chartered allowed both.  This does make it rather interesting to define the "architecture".
>>> Mmmm... both concurrently, or did he mean that we as a WG can make a choice what we prefer and standardize that?
>>> If we do both concurrently or a longside each other, can we then still guarantee interoperability (which I think is one of our main objctives, no)?
>>>> 2') I do think that there are a few places in the model, particularly
>>>> with regard to policy execution status, where the model makes some assumptions about the structure of policy delivery.  For the most part, those should be removed.  Assistance in finding
>>>> them is appreciated.  I suspect that some of them are necessary, and those should be explicitly described.   (And we should make
>>>> sure the working group agrees with the assumptions.)
>>>>
>>>> 3) (minor) The charter permits the information model.  I presume we could amend the charter to permit an architecture document.
>>>>
>>> I would say an "Architecture" or "System Overview" document would be a good thing.
>>>
>>> Bert
>>>> Yours,
>>>> Joel
>>>>
>>>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
>>>>> Very good and practical question raised by Andy!
>>>>>
>>>>> Bert
>>>>>
>>>>> On 03/03/16 06:06, Andy Bierman wrote:
>>>>>>
>>>>>> On Wed, Mar 2, 2016 at 7:21 PM, John Strassner
>>>>>> <John.sc.Strassner@huawei.com
>>>>>> <mailto:John.sc.Strassner@huawei.com>>
>>>>>> wrote:
>>>>>>
>>>>>>      We should work on an information model for several reasons, even if
>>>>>>      there is only target data model (i.e., YANG):
>>>>>>
>>>>>>        1) An information model can define how data are related to each
>>>>>>           other independent of implementation. This is much harder to do
>>>>>>           in YANG. Hence, the information model may make these inherent
>>>>>>           relationships easier to visualize and define.
>>>>>>        2) An information model separates the logical design from the
>>>>>>           physical design of the system, enabling a deeper understanding
>>>>>>           of both independent of implementation. This can be used to
>>>>>>           produce more powerful implementations.
>>>>>>        3) If an information model is worked on in another organization,
>>>>>>           there is no guarantee that its output will be useful to the
>>>>>>           IETF. I am active in the TM Forum, which you cited; they are
>>>>>>           in general not worried about implementing YANG models, much
>>>>>>           less producing optimal YANG models.
>>>>>>        4) This enables other SDOs and fora, which do not use YANG, to
>>>>>>           more easily understand our output.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It seems to me that your draft has many details related to the
>>>>>> abstraction of policy logic, but also many aspects that look like
>>>>>> implementation details.
>>>>>> Perhaps it can be simplified if the implementation details were removed.
>>>>>>
>>>>>> I am more interested in the SUPA Architecture document first.
>>>>>> I don't see how we can agree on an info-model in the absence of a
>>>>>> system architecture.
>>>>>>
>>>>>> Does SUPA run anywhere? What does it even mean to implement SUPA?
>>>>>> Will people be able to build interoperable SUPA engines from the RFCs?
>>>>>> Is there a difference between a SUPA engine running at the device
>>>>>> level or the controller level?  What data is available for policy
>>>>>> enforcement analysis?
>>>>>> Is this configurable through YANG modules implemented by a SUPA engine?
>>>>>> How are policies defined and managed within the SUPA implementation?
>>>>>> How is device config altered to implement policy?
>>>>>> How are device operational state and statistics used to verify
>>>>>> policy implementation?
>>>>>>
>>>>>> A precise description of policy logic might be a good thing to have.
>>>>>> I am not objecting to an info model doc.  A system architecture and
>>>>>> a workable solution will require a lot more than that.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>      John
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>      -----Original Message-----
>>>>>>      From: Supa [mailto:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of Zhoutianran
>>>>>>      Sent: Tuesday, March 01, 2016 7:29 PM
>>>>>>      To: Nevil Brownlee
>>>>>>      Cc: SUPA list
>>>>>>      Subject: Re: [Supa] Information models and Data models - WG adopion?
>>>>>>
>>>>>>      Hi Nevil,
>>>>>>
>>>>>>      I am not arguing information model is useless, but it can be
>>>>>> worked out in other organizations if necessary, e.g. TMF.
>>>>>>      If in SUPA we can worked on YANG data models directly, why we
>>>>>> firstly work on an information model and then translate it to
>>>>>>      YANG data model?
>>>>>>      It just not makes sense to me.
>>>>>>
>>>>>>      Tianran
>>>>>>
>>>>>>      > -----Original Message-----
>>>>>>      > From: Supa [mailto:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of Nevil Brownlee
>>>>>>      > Sent: Wednesday, March 02, 2016 6:56 AM
>>>>>>      > To: Zhoutianran
>>>>>>      > Cc: SUPA list
>>>>>>      > Subject: Re: [Supa] Information models and Data models - WG
>>>>>> adopion?
>>>>>>      >
>>>>>>      >
>>>>>>      > Hi Tianran:
>>>>>>      >
>>>>>>      > In my experiences, having a well-defined information model
>>>>>> is a good starting
>>>>>>      > point.  It allows different implementations, each of which
>>>>>> can develop it's
>>>>>>      > own data model - in other words, the information model is a
>>>>>> good unifying
>>>>>>      > influence - which is why publishing such a document is the
>>>>>> second of our
>>>>>>      > chart items.  I hope that getting a good data model will
>>>>>> help us with the
>>>>>>      > first chart item ("scope of the policy-based management
>>>>>> framework").
>>>>>>      >
>>>>>>      > draft-strassner-supa-generic-policy-info-model is the only SUPA
>>>>>>      > information model that's had any work done on it since IETF
>>>>>> 95, therefore
>>>>>>      > I've proposed it for WG adoption.
>>>>>>      >
>>>>>>      > As for the third charter item - "set of YANG data models",
>>>>>> there are two
>>>>>>      > of these on the SUPA documents page.  It would help at this
>>>>>> stage if their
>>>>>>      > authors could comment on this list about the status of these
>>>>>> drafts.  In
>>>>>>      > particular, jave they been working on a new version?
>>>>>>      >
>>>>>>      > Overall, we really need more discussion on the list of
>>>>>> what's happening
>>>>>>      > with the SUPA work!
>>>>>>      >
>>>>>>      > Cheers, Nevil
>>>>>>      >
>>>>>>      >
>>>>>>      > On 1/03/16 6:13 pm, Zhoutianran wrote:
>>>>>>      > > If this is a poll for WG adoption, I would say not support.
>>>>>>      > >
>>>>>>      > > If we want to finally generate YANG data models here, why
>>>>>> do we spend
>>>>>>      > time working on this information model?
>>>>>>      > >
>>>>>>      > > Why not focus on the ECA YANG data model directly as
>>>>>> standard track?
>>>>>>      > >
>>>>>>      > >
>>>>>>      > > Tianran
>>>>>>      > >
>>>>>>      > >> -----Original Message-----
>>>>>>      > >> From: Supa [mailto:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of IETF
>>>>>>      > >> Secretariat
>>>>>>      > >> Sent: Monday, February 29, 2016 6:35 AM
>>>>>>      > >> To:
>>>>>> draft-strassner-supa-generic-policy-info-model@ietf.org
>>>>>> <mailto:draft-strassner-supa-generic-policy-info-model@ietf.org>;
>>>>>>      > >> supa-chairs@ietf.org <mailto:supa-chairs@ietf.org>;
>>>>>> supa@ietf.org <mailto:supa@ietf.org>
>>>>>>      > >> Subject: [Supa] The SUPA WG has placed
>>>>>>      > >> draft-strassner-supa-generic-policy-info-model in state
>>>>>> "Call For
>>>>>>      > >> Adoption By WG Issued"
>>>>>>      > >>
>>>>>>      > >>
>>>>>>      > >> The SUPA WG has placed
>>>>>> draft-strassner-supa-generic-policy-info-model
>>>>>>      > >> in state Call For Adoption By WG Issued (entered by Nevil
>>>>>> Brownlee)
>>>>>>      > >>
>>>>>>      > >> The document is available at
>>>>>>      > >>
>>>>>>      >
>>>>>> https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-
>>>>>>      > >> i
>>>>>>      > >> nfo-model/
>>>>>>      > >>
>>>>>>      > >>
>>>>>>      > >> Comment:
>>>>>>      > >> This is the first of our charter documents, the other
>>>>>> charter items
>>>>>>      > >> build on this
>>>>>>      > >>
>>>>>>      > >> _______________________________________________
>>>>>>      > >> Supa mailing list
>>>>>>      > >> Supa@ietf.org <mailto:Supa@ietf.org>
>>>>>>      > >> https://www.ietf.org/mailman/listinfo/supa
>>>>>>      >
>>>>>>      >
>>>>>>      > --
>>>>>>      >
>>>>>> ---------------------------------------------------------------------
>>>>>>      >   Nevil Brownlee                          Computer Science
>>>>>> Department
>>>>>>      >   Phone: +64 9 373 7599 x88941             The University of
>>>>>> Auckland
>>>>>>      >   FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New
>>>>>> Zealand
>>>>>>      >
>>>>>>      > _______________________________________________
>>>>>>      > Supa mailing list
>>>>>>      > Supa@ietf.org <mailto:Supa@ietf.org>
>>>>>>      > https://www.ietf.org/mailman/listinfo/supa
>>>>>>
>>>>>>      _______________________________________________
>>>>>>      Supa mailing list
>>>>>>      Supa@ietf.org <mailto:Supa@ietf.org>
>>>>>>      https://www.ietf.org/mailman/listinfo/supa
>>>>>>
>>>>>>      _______________________________________________
>>>>>>      Supa mailing list
>>>>>>      Supa@ietf.org <mailto:Supa@ietf.org>
>>>>>>      https://www.ietf.org/mailman/listinfo/supa
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Supa mailing list
>>>>>> Supa@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/supa
>>>>> _______________________________________________
>>>>> Supa mailing list
>>>>> Supa@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/supa
>>>>>
>>>> _______________________________________________
>>>> Supa mailing list
>>>> Supa@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/supa
>>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>>>
>>
>>_______________________________________________
>>Supa mailing list
>>Supa@ietf.org
>>https://www.ietf.org/mailman/listinfo/supa