Subject: [Supa] review of draft-klyus-supa-proposition-02

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 08 Jul 2015 17:18:58 +0800

Hi all,
I just got a chance to read the new version of proposition, and it seems to
me the there are three main changes (@ authors, correct me if I was wrong
^_^) :
1. two more paragraphs were added into problem statement which explained
policy management
2. a whole new figure with process information(IMHO, a little complicated)
replaced the old ones which are more easy to understand.
3. Some additions and deletions in gap analysis part

For the 2nd change, I have some concerns. In the previous version, I can
easily tell which part belongs to SUPA and where it's located. But now maybe
we need more words to explain where in the network/ system will SUPA be
located. Moreover, using the same square blocks to indicate IETF , SUPA GPIM
and other stuff will be confusing to new readers, as they belong to
different dimension s. The authors may think about to simplify this figure
and use different shape of blocks. One new figure telling the exact location
of SUPA may also be needed.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Jul 2015 21:24:22 +0200

> of SUPA may also be needed.

I have been suggesting that SUPA is defining a function and should not
mandate where the function is implemented. A figure showing one
possible way how the function can be implemented and applied may be
more suitable for the applicability document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jon Saperia <[email-masked]>
Date: Wed, 8 Jul 2015 15:31:04 -0400

Perhaps then the words around it should be refined.  There is a need to have an ‘architecture’ section or document.  The idea is to say where interfaces are and what the behavior of the interfaces is to be.  How the functions are implemented inside the components of the architecture is up to the people writing the code.

On the phone call yesterday John described the conditions where the two proposed paths would be used.  Putting that in might help.

/jon
> On Jul 8, 2015, at 3:24 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> 
> _______________________________________________
> Supa mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>

---

From: John Strassner <[email-masked]>
Date: Wed, 8 Jul 2015 23:03:04 +0000

Hi Dacheng,

please see inline.

regards,
John

John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

From: Supa [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Wednesday, July 08, 2015 2:19 AM
To: [email-masked]
Subject: [Supa] review of draft-klyus-supa-proposition-02

Hi all,
I just got a chance to read the new version of proposition, and it seems to me the there are three main changes (@ authors, correct me if I was wrong ^_^) :
<jcs> That's correct </jcs>

1. two more paragraphs were added into problem statement which explained policy management
<jcs> Not quite. Basically, the second and third paragraphs in the Problem Statement (1.1) were moved from the Proposed Solution (1.2) section and slightly changed to conform to presenting this as a problem, not as a solution. This was in response to several people on the list that thought that a one sentence problem statement was much too short. </jcs>

2. a whole new figure with process information(IMHO, a little complicated) replaced the old ones which are more easy to understand.
<jcs> The new figure was primarily in response to the discussions on the previous figure. For example, Juergen said:
> It is full of 'noise' that is not needed. Why is there
> a 'Service Management' box? What is the 'Service
> Management Data Model'? What exactly are the 'Network
> Manager / Controller'? More important, where is the
> policy interpreter function that SUPA is about (given
> the charter text)? I was trying to produce a
> _functional_ drawing.

Juergen was right - we **used** to talk about PBSM (that was the title of the IETF92 presentation from Fukushima-san and myself, in fact) but that was eliminated from the charter. Finally, it defines two exemplary interfaces of how SUPA is used, since most of our discussion has been about that. I wouldn't call this a "process" figure. See more below.
</jcs>

For the 2nd change, I have some concerns. In the previous version, I can easily tell which part belongs to SUPA and where it's located.
<jcs> I disagree. In -01, where exactly is SUPA? Does it include the "Service Management Data Model"? Is it part of Service Management (which, by the way, is not defined in the I-D)? </jcs>

But now maybe we need more words to explain where in the network/ system will SUPA be located.
<jcs> I disagree. I thought we had consensus with Juergen's suggestion that we **not** explicitly define **where** the translation function is located. </jcs>

Moreover, using the same square blocks to indicate IETF , SUPA GPIM and other stuff will be confusing to new readers, as they belong to different dimension s.
<jcs> I don't think that the shape of the box is relevant. If it is, then we need 8 different shapes </jcs>

The authors may think about to simplify this figure and use different shape of blocks. One new figure telling the exact location of SUPA may also be needed.
<jcs> See above </jcs>

---

From: John Strassner <[email-masked]>
Date: Wed, 8 Jul 2015 23:21:44 +0000

I'm happy to rewrite this, and would appreciate concrete suggestions. Jon's suggestion is a good one. However, please note the following extracts from -02:

Lines 328-9 (last paragraph of page 6):
" In one of possibly several alternate approaches (shown with
   asterisks in Figure 1),..."

Lines 384-390 (last paragraph of Page 7)
" Figure 1 is meant to be exemplary..."

I don't see how this figure "mandates where the function is implemented". Text before and after clearly say that this is an **example**. Nowhere does it say **where** the function is located (other than generically saying that it is part of the "Local SUPA Execution Environment", but note that this does not say if it is in an SDN Controller, or an EMS, or anywhere else).

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Supa [mailto:[email-masked]] On Behalf Of Jon Saperia
Sent: Wednesday, July 08, 2015 12:31 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Dacheng Zhang
Subject: Re: [Supa] review of draft-klyus-supa-proposition-02

/jon
On Jul 8, 2015, at 3:24 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

/js

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