Subject: [Supa] Draft -01 of the value proposition draft was submitted

From: John Strassner <[email-masked]>
Date: Wed, 10 Jun 2015 00:36:32 -0700

I just successfully submitted this. Hopefully this makes it easier for the
IESG to read.

It's 12:35am, so that all for me. Thanks to Juergen, Benoit, Dan, and
especially Max for getting this out quickly.

-- 
regards,
John

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2015 11:53:58 +0000

Hi John,

Thanks for the good work. This version is much better IMO, but now the sections 1.3 and 5 seem redundant. We discussed I thought about doing one OR the other.

Regards,

Dan

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Wednesday, June 10, 2015 10:37 AM
To: [email-masked]
Cc: Benoit Claise; Romascanu, Dan (Dan); Maxim Klyus; Juergen Schoenwaelder; Tina Tsou
Subject: [Supa] Draft -01 of the value proposition draft was submitted

I just successfully submitted this. Hopefully this makes it easier for the IESG to read.

It's 12:35am, so that all for me. Thanks to Juergen, Benoit, Dan, and especially Max for getting this out quickly.

--
regards,
John

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Jun 2015 22:52:22 +0200

Thanks to all for working hard on this version.
The document improved, and I believe it's good start for the IESG/IAB review

In case you want to consider a new version (don't rush before Thursday)...

I see this clarification now:

        There are many types of policies. SUPA differentiates between
        "management policies" and "embedded policies". Management
        policies are used to control the configuration of network
        elements. Management policies can be interpreted externally to
        network elements, and the interpretation typically results in
        configuration changes of collections of network elements. In
        contrast, "embedded policies" are policies that are embedded
        in the configuration of network elements, and are usually
        interpreted on network elements in isolation. Since embedded
        policies are interpreted in the network device, they are
        typically composed in a very specific fashion to run at
        near-realtime timescales.

    ...

        SUPA is working on defining policies that
        can be interpreted external to network elements. Hence, SUPA
        policies can be used to define the behavior of and
        interaction between embedded policies.

This is redundant with section 2.2

- I don't understand this first sentence in:

    SUPA can also be used to derive a (more abstract) information
    model from a (more specific) data model. This extracts data
    that is part of a particular technology and/or application
    and makes it reusable, so that it can be applied to multiple
    technologies and/or domains.

-

    It is envisioned that SUPA will use work produced by I2RS. This
    in particular applies to the topology work done in the I2RS
    working group, since topology information is often necessary for
    the interpretation of SUPA policies.

SUPA will not use the topology produced by I2RS
An network manager/controller/orchestrator will take as input the 
SUPA-based policies, integrate the topology, and decide which network 
elements to configure.

- 4.1.9 
<https://tools.ietf.org/html/draft-klyus-supa-proposition-01#section-4.1.9>. 
Previous IETF Policy Models

Please mention the previous RFCs

Regards, Benoit

---

From: John Strassner <[email-masked]>
Date: Wed, 10 Jun 2015 22:39:43 +0000

Hi Benoit,

please see inline.

regards,
John

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, June 10, 2015 1:52 PM
To: John Strassner; [email-masked]
Cc: Romascanu, Dan (Dan); Maxim Klyus; Juergen Schoenwaelder; Tina TSOU
Subject: Re: [Supa] Draft -01 of the value proposition draft was submitted

...

<jcs>
The above two paragraphs (from sections 1.2 and 1.3, respectively) were intended
to enable the reader to understand the value proposition by ONLY reading section 1.
This was motivated by you correctly pointing out that things were too complex and
not concise enough. In contrast, section 2.2 further expands on these thoughts.
</jcs>

<jcs>

Sorry, my bad :-(

Translated, this means that SUPA can work with existing WGs even before they are

finished. These existing WGs develop solutions to solve problems in their separate

domains. If these take the form of (more specific) data models, then SUPA can

generalize those results into a (less specific) information model). Hence, SUPA

does NOT IMPEDE the progress of other WGs, and produces a more generally

applicable model.

I could add this to the WIKI Q&A if you think it would be helpful.

</jcs>

-

SUPA will not use the topology produced by I2RS
An network manager/controller/orchestrator will take as input the SUPA-based policies, integrate the topology, and decide which network elements to configure.
<jcs>
I don't understand why SUPA couldn't use the topology information produced by I2RS?
</jcs>

- 4.1.9<https://tools.ietf.org/html/draft-klyus-supa-proposition-01#section-4.1.9>. Previous IETF Policy Models

<jcs>
Sorry, my bad, I was rushing. They are, of course, RFC3060 and RFC3460, as noted in the wiki.
Will update in the next version.
</jcs>

Regards, Benoit

--
regards,
John

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Jun 2015 01:15:20 +0200

On 11/06/2015 00:39, John Strassner wrote:
>
> Hi Benoit,
>
> please see inline.
>
> regards,
>
> John
>
> *From:*Supa [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* Wednesday, June 10, 2015 1:52 PM
> *To:* John Strassner; [email-masked]
> *Cc:* Romascanu, Dan (Dan); Maxim Klyus; Juergen Schoenwaelder; Tina TSOU
> *Subject:* Re: [Supa] Draft -01 of the value proposition draft was 
> submitted
>
OK
> does NOT IMPEDE the progress of other WGs, and produces a more generally
If I understand correctly (read it three times), you want to learn from 
the existing WGs domain-specific policy (YANG) data models to build the 
SUPA IM that will in the in end be translated in a SUPA YANG models. 
Splitting hairs if you ask me :-)
On the hand, if you would simply state "SUPA will learn from existing 
WGs policy work to make sure its data models are applicable. However, 
SUPA will not delay work in any existing WGs", that would be go to the 
point, and be reasonable.
> I don't understand why SUPA couldn't use the topology information 
SUPA could use any resources it needs for its policies.
The way you have written this, you seem to want to standardize an 
orchestrator.

Regards, Benoit

---

From: John Strassner <[email-masked]>
Date: Wed, 10 Jun 2015 23:29:41 +0000

Hi Benoit,

thanks for your clarification.
Please see inline, look for <jcs2>..</jcs2>

regards,
John

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, June 10, 2015 4:15 PM
To: John Strassner; John Strassner; [email-masked]
Cc: Romascanu, Dan (Dan); Maxim Klyus; Juergen Schoenwaelder; Tina TSOU
Subject: Re: [Supa] Draft -01 of the value proposition draft was submitted

please see inline.

regards,
John

To: John Strassner; [email-masked]<mailto:[email-masked]>

...

<jcs>

<jcs>

Sorry, my bad :-(

applicable model.
If I understand correctly (read it three times), you want to learn from the existing WGs domain-specific policy (YANG) data models to build the SUPA IM that will in the in end be translated in a SUPA YANG models. Splitting hairs if you ask me :-)
On the hand, if you would simply state "SUPA will learn from existing WGs policy work to make sure its data models are applicable. However, SUPA will not delay work in any existing WGs", that would be go to the point, and be reasonable.
<jcs2>
Understood, and thanks!
</jcs2>

</jcs>

-

SUPA will not use the topology produced by I2RS
An network manager/controller/orchestrator will take as input the SUPA-based policies, integrate the topology, and decide which network elements to configure.
<jcs>
I don't understand why SUPA couldn't use the topology information produced by I2RS?
SUPA could use any resources it needs for its policies.
The way you have written this, you seem to want to standardize an orchestrator.
<jcs2>
Sorry, I'm confused. I probably need more coffee :-)

The paragraph quoted above (from 4.1.1) states that SUPA will use work produced by I2RS.
What I didn't understand was why you said that SUPA will not use the topology produced
by I2RS.

That being said, you are absolutely correct, SUPA could use any resources that it needs
for constructing policies; whether those resources come from I2RS or another WG is
of course immaterial. So, for the next revision, would it be clearer if we:
   1) stated that up front (perhaps in 1.3, value of the SUPA Approach), and/or

   2) remove the second sentence " This in particular applies to the

   topology work done in the I2RS working grou"?

I am **guessing** that your reference to the orchestrator is due to the third sentence.
Clearly, standardizing the orchestrator is beyond the scope of SUPA. Would it help to
simply remove this sentence? Or is my guess wrong? :-)
</jcs2>

Regards, Benoit

</jcs>