Subject: Re: [Ibnemo] [Supa] SUPA charter proposal

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 07 Aug 2015 20:46:22 +0200

Hi Benoit and others.

So would this work prevent the formation of a WG that would do IBNEMO (Intent Based NEtwork MOdeling)
work? I certainly hope not. In the charter you have:

       (iii) the working group will investigate the practically of building policy rules that declaratively
             specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve
             those goals and may create a model accordingly.

IBNEMO intends (no pun intended) to define/standardize a Intent expression language.
The work you describe above can be input to the work IBNEMO wants to do.

Bert

On 07/08/15 18:03, Benoit Claise wrote:
> Dear all,
>
> As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.
>
> Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
> Please let us know. Note: I prefer to keep the edit token from now.
>
> Regards, Benoit (OPS AD)
>
> ==============================================================
>
> SUPA CHARTER PROPOSAL (2015-08-07)
>
> Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need 
> to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical 
> and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way 
> of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid 
> configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in 
> different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid 
> development of standards-based data models that include policy elements.
>
> SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, 
> an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the 
> function does with that input but anticipates that it will ultimately result in network configuration changes
>
> Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and 
> service-specific YANG models of other working groups.
>
> SUPA will be designed to work with device, protocol, network, and service data models.
>
> The SUPA working group will develop a model for expressing policy at different levels of abstraction.Specifically, three model 
> fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the 
> form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of 
> the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that 
> declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and 
> may create a model accordingly.
>
> If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive 
> the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.
>
> Out of scope of this working group is:
>
> -The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.
>
> -Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted 
> in isolation, and often at timescales that require optimization for specific purposes).
>
> -Specific handling of policies (although the application document will provide some examples), and therefore the specification of 
> a policy engine that maps a specific policy instance to actual configuration snippets.
>
> List of work items:
>
> 1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.
>
> 2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.
>
> 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type 
> or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another 
> extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be 
> designed to be generic and extensible.
>
> 4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express 
> policies that are relevant for network operators. The examples may tie into configuration models or network service models 
> developed by other working groups.
>
> The working group will decide how the work items are best mapped into deliverables.
>
> This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, 
> specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models 
> developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA 
> to produce its deliverables.
>
> The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.
>
> Milestones:
>
> TBD
>
>
>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 13:30:08 -0700

Hi Adrian,

I also do not think that there is any overlap between what SUPA has defined
and what NEMO has defined. SUPA provides a common model for
expressing imperative (e.g., event-condition-action, or ECA) and declarative
(e.g., goal-based, or "intent") policies. SUPA proposes that each of these
representations are realized as separate models, but are related through
their "common ancestry" (i.e., they were both derived from the same
superstructure). This means that each can use the other.

In addition, there are distinct differences between SUPA and NEMO:

  1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In
      contrast, NEMO wants to define a new protocol.
  2) SUPA defines intent as declarative logic, and thus implements it
      using either propositional or first order logic (see section 3.2.4.,
      Mathematical Logic Terminology, of draft-strassner-supa-generic-
      policy-info-model). In contrast, NEMO defines implements its
      intent policy using condition-action (imperative) logic.
 3) SUPA is NOT working on a language. In contrast, NEMO is working
     on a language.

regards,
John

On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked]> wrote:

> Hi Bert,
>
> I don't think you are reading the proposed charter for SUPA right if you
> think
> it precludes the formation of a working group for IBNEMO. Rather, the text
> that
> Benoit has published says that SUPA is not the working group that works on
> IBNEMO.
>
> But maybe you are saying that the intent-based part of the SUAP charter
> could be
> lifted out and placed in an IBNEMO work effort. That might be reasonable.
>
> However, there is a separation between the use of existing data modeling
> and
> protocols (such as YANG with NETCONF) and the development of a new and
> specialised modeling language and communication protocol. I believe that
> this
> charter text opens up the investigation of the practicalities of
> intent-based
> policy modeling in order to determine whether such things could be modeled
> in
> existing languages or whether new work is needed a priori.
>
> If, for example, it was possible to encode intent-based policy in YANG,
> that
> would not preclude IBNEMO inventing something different/better/worse.
>
> Now there it seems sensible that SUPA should bundle all of the thought
> around
> policy models in one place as a starting point. If it is later desirable to
> split off the intent-based part (say after the initial investigation and
> information models) that doesn't seem like a bad thing.
>
> Alternatively, if there is a strong pull to move all of the intent-based
> work
> out from day one, I will not be complaining.
>
> Cheers,
> Adrian
>
> > -----Original Message-----
> > From: Supa [mailto:[email-masked]] On Behalf Of Bert Wijnen
> (IETF)
> > Sent: 07 August 2015 19:46
> > To: Benoit Claise; [email-masked]
> > Cc: Eggert, Lars; [email-masked]
> > Subject: Re: [Supa] SUPA charter proposal
> >
> > Hi Benoit and others.
> >
> > So would this work prevent the formation of a WG that would do IBNEMO
> (Intent
> > Based NEtwork MOdeling)
> >        (iii) the working group will investigate the practically of
> building
> policy rules
> > that declaratively
> >              specify what goals to achieve (this is often called
> "intent-based" policy) but
> > not how to achieve
> > IBNEMO intends (no pun intended) to define/standardize a Intent
> expression
> > language.
> > > As promised in my last email ("SUPA: Situation Summary and Next
> Steps"),
> here
> > is a proposed charter.
> > > Hopefully, this new version will clarify the situation, and will be
> acceptable to
> > everybody.
> > > Policy is an important configurable component in the delivery of
> services
> and
> > the operation of networks. Operators want and need
> > > to be able to determine the policies that apply to their different
> customers
> and
> > to the equipment that comprises their physical
> > > and virtual networks. As policy spans such a wide range of services and
> device
> > types, it will be helpful if there is a common way
> > > of expressing and describing policies that is uniform and consistent
> in all
> > environments. Such an approach will help to avoid
> > > configuration errors that arise from confusion between different
> systems,
> will
> > enable easy understanding of policies that apply in
> > > different environments, will make the implementation of policy-based
> systems
> > quicker and cheaper, and will facilitate the rapid
> > > SUPA (Simplified Use of Policy Abstractions) defines a model to
> interface
> with a
> > network management function (within a controller,
> > > an orchestrator, a network element) that takes high-level, possibly
> network-
> > wide policies as input. SUPA will not define what the
> > > function does with that input but anticipates that it will ultimately
> result
> in
> > network configuration changes
> > >
> > > Practically, SUPA will define generic YANG data models to encode
> policy,
> which
> > can point to device-, technology-, and
> > > SUPA will be designed to work with device, protocol, network, and
> service
> data
> > models.
> > >
> > > The SUPA working group will develop a model for expressing policy at
> different
> > levels of abstraction.Specifically, three model
> > > fragments are envisioned: (i) a generic model that defines concepts and
> > vocabulary needed by policy management independent of the
> > > form and content of the policy, (ii) a more specific model that
> refines the
> > generic model to specify how to build policy rules of
> > > the event-condition-action paradigm, and (iii) the working group will
> investigate
> > the practically of building policy rules that
> > > declaratively specify what goals to achieve (this is often called
> "intent-based"
> > policy) but not how to achieve those goals and
> > > If the working group finds it necessary to work on an information model
> before
> > the data model, to help provide guidance and derive
> > > the data models, it might do so. The working group will decide later
> whether
> > the information model needs to be published as an RFC.
> > >
> > > -The specification of a new policy language. The YANG data models are
> to be
> > used with protocols such as NETCONF/RESTCONF.
> > >
> > > -Design of protocol-specific policies and specific design for embedded
> policies in
> > network elements (which are usually interpreted
> > > in isolation, and often at timescales that require optimization for
> specific
> > purposes).
> > >
> > > -Specific handling of policies (although the application document will
> provide
> > some examples), and therefore the specification of
> > > a policy engine that maps a specific policy instance to actual
> configuration
> > snippets.
> > >
> > > List of work items:
> > >
> > > 1) A document that explains the scope of the policy-based management
> > framework and how it relates to existing work of the IETF.
> > >
> > > 2) If the working group considers it necessary, an information model
> composed
> > of policy concepts and vocabulary.
> > >
> > > 3) A set of YANG data models consisting of a base policy model for
> representing
> > policy management concepts independent of the type
> > > or structure of a policy, plus an extension for defining policy rules
> according to
> > the event-condition-action paradigm. Another
> > > extension for defining policy rules according to a declarative, or
> intent-based,
> > paradigm, may be produced. These models will be
> > > 4) An applicability document providing a few examples that demonstrate
> how
> > the generic policy models can be used to express
> > > policies that are relevant for network operators. The examples may tie
> into
> > configuration models or network service models
> > > This working group will be a success when the SUPA policy constructs
> are re-
> > used in future IETF specifications (and, ideally,
> > > specifications from other SDOs), in a manner that will save
> development time
> > and avoid inconsistencies between data models
> > > developed by different working groups. In the meantime, SUPA should not
> > impede work in other working groups while waiting for SUPA
> > > The working group will communicate with other SDOs (MEF, TMF, ETSI)
> that are
> > working on related issues.
> > >
> > > Milestones:
> > >
> > > TBD
> > >
> > >
> > >
> > >

-- 
regards,
John

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 09 Aug 2015 22:42:26 +0200

Hi Adrian, inline

On 09/08/15 17:23, Adrian Farrel wrote:
> Hi Bert,
>
> I don't think you are reading the proposed charter for SUPA right if you think
> it precludes the formation of a working group for IBNEMO. Rather, the text that
OK, that was certainly not so clear to me. Thanks for clarifying this. I am still abit worried about
the text:

                (iii) the working group will investigate the practically of
         building policy rules that declaratively specify what goals to achieve
         (this is often called "intent-based" policy) but not how to achieve
         those goals and may create a model accordingly.

So what does that last piece of the sentence "and may create a model accordingly" mean then?
> But maybe you are saying that the intent-based part of the SUAP charter could be
I think that makes sense to me too. But maybe we need more discussion on this.
In fact, Intent Based Network Modeling has already quite some traction (including code) in
Open Daylight projects. So they are quite active already in that space.
Standardizing a language to express intent seems something that a WG in IETF could very well
work on, actually pretty soon.  AS we discussued in our barbof in Prague.
> However, there is a separation between the use of existing data modeling and
> specialised modeling language and communication protocol. I believe that this
> charter text opens up the investigation of the practicalities of intent-based
> policy modeling in order to determine whether such things could be modeled in
In fact, in IBNEMO we realize that we need to use (or define maybe) some YANG data models
that would allow us to translate "intent expressions" into actual network-wide, conroller-wide
or device-specific data models. We would use any existing data models if at laa possibl.
But we do need some data models in order to prove that our expression language can work and
be implemented in interoperable code.
>
> If, for example, it was possible to encode intent-based policy in YANG, that
RIght, but my personal preference would be to try and see if we can use existing YANG data models
> Now there it seems sensible that SUPA should bundle all of the thought around
Could be I guess
> Alternatively, if there is a strong pull to move all of the intent-based work
And I think some of that work has already started, although still at an indiviadual-draft level.

Bert
>> From: Supa [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
>>         (iii) the working group will investigate the practically of building
> policy rules
>> that declaratively
>>> As promised in my last email ("SUPA: Situation Summary and Next Steps"),
> here
>> is a proposed charter.
>>> Policy is an important configurable component in the delivery of services
> and
>>> to be able to determine the policies that apply to their different customers
> and
>>> of expressing and describing policies that is uniform and consistent in all
>>> configuration errors that arise from confusion between different systems,
> will
>>> different environments, will make the implementation of policy-based systems
>>> SUPA (Simplified Use of Policy Abstractions) defines a model to interface
> with a
>>> an orchestrator, a network element) that takes high-level, possibly network-
>>> function does with that input but anticipates that it will ultimately result
> in
>>> Practically, SUPA will define generic YANG data models to encode policy,
> which
>>> SUPA will be designed to work with device, protocol, network, and service
> data
>> models.
>>> form and content of the policy, (ii) a more specific model that refines the
>>> the data models, it might do so. The working group will decide later whether
>>> -The specification of a new policy language. The YANG data models are to be
>>> 4) An applicability document providing a few examples that demonstrate how
>>> policies that are relevant for network operators. The examples may tie into
>>> This working group will be a success when the SUPA policy constructs are re-
>>> specifications from other SDOs), in a manner that will save development time

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 09 Aug 2015 23:23:50 +0200

John, Inline,

> superstructure). This means that each can use the other.
OK, that sounds good to me.

>       contrast, NEMO wants to define a new protocol.
I do not know what makes you say so.
I think we have left it open sofar as to whether we want/need a new protocol or not.
Preferably we can use Netconf/Restconf. But I think that is all still open to discussion.
>       intent policy using condition-action (imperative) logic.
Again I do not understand why you think so.
I have not seen any ECA stuff in IBNEMO yet.
But then, maybe you can point me to it if you have.
>  3) SUPA is NOT working on a language. In contrast, NEMO is working
Yep, we would like to work on an "intent expression language" in IBNEMO.

Bert
>
> regards,
> John
>
> On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Bert,
>
>     > From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bert Wijnen (IETF)
>     > To: Benoit Claise; [email-masked] <mailto:[email-masked]>
>     > Cc: Eggert, Lars; [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 14:59:21 -0700

Bert,

please see inline.

In addition, there are distinct differences between SUPA and NEMO:

>>  1) SUPA defines NETCONF or RESTCONF as its protocol. Period.
>>  In contrast, NEMO wants to define a new protocol.

> Preferably we can use Netconf/Restconf. But I think that is all still

<jcs>
What makes me say so is a combination of
  1) listening to previous NEMO presentations in other fora
  2) various sentences in the IBNEMO Bar BoF presentation
      (e.g., "Question: scripts over http workable, Not sure
       RESTCONF rpc + pub.sub level needed",
  3) Statements such as "Synergistic means that sum of Intent Based
      NEMO protocol + NETCONF + RESTCONF + I2RS +PCE is more
      than any of the parts alone" and "creating protocol with minimal
      operations for to express intent from the application to the network".
      both from draft-hares-ibnemo-overview-01
  4) a mail from Sue on 7/17 to the NEMO and SUPA lists, that said
      "IBNemo’s 15 specific commands are better than NETCONF
        or RESTCONF commands"
I can give you many more examples...
</jcs>

>> 2) SUPA defines intent as declarative logic, and thus implements
>> it using either propositional or first order logic (see section 3.2.4.,

> But then, maybe you can point me to it if you have.

<jcs>
I said "condition-action", NOT ECA.
Please look at draft-xia-sdnrg-nemo-language-02, which says:
"All the policies follow the same pattern "when <condition>, to
execute <action>, with <constraint>", and can be applied to any entity."
</jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]>
wrote:

>>     > From: Supa [mailto:[email-masked] <mailto:
>> [email-masked]>] On Behalf Of Bert Wijnen (IETF)
>>     > So would this work prevent the formation of a WG that would do
>> IBNEMO (Intent
>>     > Based NEtwork MOdeling)
>>     > > in isolation, and often at timescales that require optimization
>> for specific
>>     > purposes).
>>     > >
>>     > > The working group will decide how the work items are best mapped
>> into
>>     > deliverables.
>>     > >
>>     > > The working group will communicate with other SDOs (MEF, TMF,
>> ETSI) that are

-- 
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Aug 2015 18:16:49 -0400

John: 

To respond to the following part of your discussion with Bert: 

<jcs>

1)      listening to previous NEMO presentations in other forum 

<sue> 

I’m glad you’ve listen to Nemo presentations at other forums

</sue> 

<sue> 

It is this statement that Bert is alluding to.  We are open to using a transport mechanism from http, or RESTCONF with various forms to carry the Nemo commands.  

</sue> 

<sue>: The key point here is the Nemo commands (connection, plus language commands enable the user to ask for connection with easy human language for the end-user. 

</sue> 

        or RESTCONF commands"

<sue> The reason these 15 commands are better is that these commands are targeted the end-user for network-wide commands.  The Netconf/restconf commands are focused at the device level.  

</sue> 

</jcs>

 

From: Ibnemo [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, August 09, 2015 5:59 PM
To: Bert Wijnen (IETF)
Cc: Adrian Farrel; Eggert, Lars; [email-masked]; [email-masked]
Subject: Re: [Ibnemo] [Supa] SUPA charter proposal

Bert,

please see inline.

> I think we have left it open sofar as to whether we want/need a new

> protocol or not.
> Preferably we can use Netconf/Restconf. But I think that is all still

> open to discussion.

<jcs>

        or RESTCONF commands"

</jcs>

<jcs>

</jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]> wrote:

John, Inline,

Hi Adrian,

Bert

regards,
John

    Hi Bert,

    Cheers,
    Adrian

    policy rules
    here
    acceptable to
    and
    and
    device
    will
    with a
    in
    which
    data
    different
    investigate
    "intent-based"
    before
    policies in
    provide
    composed
    representing
    according to
    intent-based,

-- 
regards,
John

-- 

regards,

John

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 17:05:00 +0200

+1 to what Adrian wrote.

Regards, B.
> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 17:05:07 +0200

Bert, all,

In-line.
> OK, that was certainly not so clear to me. 
See in the charter " Out of scope of this working group is: The 
specification of a new policy language"
> Thanks for clarifying this. I am still abit worried about
> the text:
>
"will investigate" and "may create a model accordingly" are carefully 
written to stress the experimental aspect of the intent-based. See my 
previous email "SUPA: Situation Summary and Next Steps"
> work on, actually pretty soon.  AS we discussued in our barbof in Prague.
I shared my views on IB-NEMO during the barbof...

Regards, Benoit

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 12 Aug 2015 20:38:06 +0000

+1 from me on this point from Adrian's message below* in particular: "SUPA should bundle all of the thought around policy models in one place as a starting point".

Fragmentation of PBNM solutions has resulted from the lack of standardization in the face of significant need ... the need is only growing as the requirements intended to be satisfied by the emerging technologies supporting network services virtualization (among many other drivers) raise the urgency of governed automation ... this is an opportunity for the IETF to restart in this challenging area (PBNM) and SUPA is a promising locus for the starting point (IMHO).

[* - Taken a little out of context, it's true ... but only a little. :)]

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, August 12, 2015 11:05 AM
To: [email-masked]; 'Bert Wijnen (IETF)' <[email-masked]>; [email-masked]
Cc: 'Eggert, Lars' <[email-masked]>; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

+1 to what Adrian wrote.

Regards, B.
> Hi Bert,
>
> I don't think you are reading the proposed charter for SUPA right if 
> you think it precludes the formation of a working group for IBNEMO. 
> Rather, the text that Benoit has published says that SUPA is not the 
> working group that works on IBNEMO.
>
> But maybe you are saying that the intent-based part of the SUAP 
> charter could be lifted out and placed in an IBNEMO work effort. That might be reasonable.
>
> However, there is a separation between the use of existing data 
> modeling and protocols (such as YANG with NETCONF) and the development 
> of a new and specialised modeling language and communication protocol. 
> I believe that this charter text opens up the investigation of the 
> practicalities of intent-based policy modeling in order to determine 
> whether such things could be modeled in existing languages or whether new work is needed a priori.
>
> If, for example, it was possible to encode intent-based policy in 
> YANG, that would not preclude IBNEMO inventing something different/better/worse.
>
> around policy models in one place as a starting point. If it is later 
> desirable to split off the intent-based part (say after the initial 
> investigation and information models) that doesn't seem like a bad thing.
>
> Alternatively, if there is a strong pull to move all of the 
> intent-based work out from day one, I will not be complaining.
>
> Cheers,
> Adrian
>
>> (Intent Based NEtwork MOdeling) work? I certainly hope not. In the 
>> charter you have:
>>
>> expression language.

---

From: John Strassner <[email-masked]>
Date: Wed, 12 Aug 2015 21:35:40 +0000

Let's agree to disagree. REST defines FOUR commands and a particular architectural approach; I see NEMO redefining both aspects of this.

From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, August 10, 2015 3:17 PM
To: 'John Strassner'; 'Bert Wijnen (IETF)'
Cc: 'Adrian Farrel'; 'Eggert, Lars'; [email-masked]; [email-masked]
Subject: Re: [Supa] [Ibnemo] SUPA charter proposal

John:

<jcs>

Bert,

please see inline.

<jcs>

<jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
John, Inline,

Bert

regards,
John

On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi Bert,

    Cheers,
    Adrian

    > From: Supa [mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Bert Wijnen (IETF)
    > To: Benoit Claise; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    > Cc: Eggert, Lars; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    policy rules
    here
    acceptable to
    and
    and
    device
    will
    with a
    in
    which
    data
    different
    investigate
    "intent-based"
    before
    policies in
    provide
    composed
    representing
    according to
    intent-based,
    > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

    _______________________________________________
    Supa mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Aug 2015 14:02:30 -0700

On Wed, Aug 12, 2015 at 1:38 PM, Natale, Bob <[email-masked]> wrote:

> +1 from me on this point from Adrian's message below* in particular: "SUPA
> should bundle all of the thought around policy models in one place as a
> starting point".
>
> Fragmentation of PBNM solutions has resulted from the lack of
> standardization in the face of significant need ... the need is only
> growing as the requirements intended to be satisfied by the emerging
> technologies supporting network services virtualization (among many other
> drivers) raise the urgency of governed automation ... this is an
> opportunity for the IETF to restart in this challenging area (PBNM) and
> SUPA is a promising locus for the starting point (IMHO).
>
IMO, the significant component here is network-level NM.
This is new territory for the IETF.  As we dig into "framework issues"
there are some common components that keep coming up:

   - topology database (query by attribute)
   - AAA (identity and authorization, logging)
   - inventory/capabilities

The need for cross-WG and cross-area coordination has never been greater.

Whether it's I2RS or PBNM or anything at the network level,
there are common problems dealing with NEs that must
be solved.  Let's make sure the foundation gets built before
the roof.

Avanti,
> BobN

Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Aug 2015 16:23:22 +0100

Hi Bert,

Cheers,
Adrian

policy rules
here
acceptable to
and
and
device
will
with a
in
which
data
different
investigate
"intent-based"
before
policies in
provide
composed
representing
according to
intent-based,