Subject: Re: [Supa] supa charter 2015-05-29

From: "Jun Bi" <[email-masked]>
Date: Thu, 11 Jun 2015 22:38:53 +0800

Hi Keith,

Thanks for the comments.

We are working on implementation of policy information model into YANG
model. Besides YANG.

As AD Benoit said, other type of implementation should also be considered.

So I think your participation as an developer would be very important to the
SUPA work. 

For the intent policy, as in wiki Q & A question 8:

Q8: What is the connection with the intent-based policy? John mentioned that
intent = declarative. You should expand on that.

    Intent is a declarative formalism that defines WHAT an entity (e.g., an
application or operator) requires from a network, but not HOW the network
should implement that request. Intent MAY have associated constraints that
restrict the behavior of the intent. Intent is the opposite of imperative,
or prescriptive, policy rules. It has the following characteristics and
behavior:

        Intent is invariant with respect to implementation

        Intent is invariant with respect to the management entity that is
translating intent to a form that a device can understand

        Intent is portable across implementation choices and changes

        Intent is NOT altered by a failed device

        Intent defines its own context, so that it can understand across
different management entities

Characteristics of non-intent (declarative) policies:

    Contain technology-specific references (e.g., a particular device, or a
port number, or a protocol id, or an IP address)

    Defines or references commands and/or settings

    Changes when different

        ports, protocols, or other technology-specific choices are made

        network providers or equipment manufacturers are made

        technology-specific mechanisms fail

    Does NOT contain context, so it must be EMBEDDED in a configuration file
at a particular point where its context is defined

    Example of an intent-based policy: When anyone from Marketing accesses
the Internet, perform IDP and balance traffic from this group

    Example of a non-intent-based policy: Match: 5-tuple-A, Action: forward
on port 12, use IDP system B, use load-balancer 3

I wonder if these make sense to you? 

Looking forward to your further comments.

Best Regards,

Jun Bi

发件人: Supa [mailto:[email-masked]] 代表 alagalah

发送时间: 2015年6月3日 21:48

收件人: Andy Bierman; Juergen Schoenwaelder; Bert Wijnen (IETF);
[email-masked] <mailto:[email-masked]> 

主题: Re: [Supa] supa charter 2015-05-29

On 6/2/15, 12:10 PM, "Andy Bierman" <[email-masked]
<mailto:[email-masked]> > wrote:

>On Tue, Jun 2, 2015 at 4:21 AM, Juergen Schoenwaelder 

><[email-masked]
<mailto:[email-masked]> > wrote:

>> On Tue, Jun 02, 2015 at 12:57:57PM +0200, Bert Wijnen (IETF) wrote:

>>> Juergen wrote:

>>>    I am sometimes getting lost at these questions. What the charter 

>>>tries

>>>    to say (and I apologize if this is still not clear enough) is that

>>>    SUPA intends to work on policies that control how things get 

>>>configured

>>>    on network elements, it is not aiming to replace or reformulate how

>>>    packet filters work etc.

>>> Maybe my misunderstanding. But I think you want to say that the 

>>>policies  control how some  of the things get configure on network 

>>>elements, no? Or is the intend that  these policies  control all of 

>>>the configuration?

>> Policies certainly won't control everything. How can the charter text 

>>be  improved to avoid this confusion? The above was just an email 

>>explanation  and hence it is not that important.

>Let's say I had a simple policy for configuration.

>Perhaps I want to the user to choose between speed and robustness, 

>i.e., edits are done as fast as possible vs. edits done as robustly as 

>possible.

>Is this a valid intent-based policy?  I know how to change the NETCONF 

>parameters to implement either for speed or for robustness.  I don't 

>understand how high-level policy gets translated into a low-level 

>implementation of the policy in an automated fashion.

>I am hoping SUPA can support this sort of usage instead of just the 

>narrow scope of the hard-wired items.  I should be able to write a 

>structured document (policy mapping?) that tells a SUPA system how to 

>glue the policy to the implementation.

I think this is a great call out. There needs to be an acknowledgement of
the different consumers of an Intent System. For instance, if we take a
DevOps viewpoint, what a Developer wants to express in Intent, and what an
Operator needs to express/modulate in Intent needs to accommodated
differently. In OpenDaylight GroupBasedPolicy, we look at this as Expressed
Intent, and Operational Constraints.

_______________________________________________

Supa mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/supa