Subject: [Supa] Update to Gap Analysis 5a

From: John Strassner <[email-masked]>
Date: Sat, 21 Mar 2015 14:18:09 -0700

I was asked to update slides 6 and 7 according to my comments. They are
attached. Change log:

Slide 6
1.  ODL GBP pre-dates GBP in OpenStack, so I moved it forward one slide to
slide 6 and deleted it from OpenStack

2. Updated GBP description to be more accurate

3. Updated NIC description to be more accurate (e.g., first bullet, which
set that the models were "often closely relating to the actual
configuration of devices") is incorrect. Intent should NEVER use the actual
configuration of a device.

Slide 7
Rewrote all 3 bullets under the Congress section to correct them as
described in my original email.

Inserted New Slide 8 on TM Forum Gaps
If desired, I can also update the draft later.

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Sun, 22 Mar 2015 03:01:52 +0000

Thanks John and Jun … this is a very informative resource.

Two things I would question:

- On slide #4, in the SFC section: “overlap could be avoided by not providing models targeting service chains specifically” … I don’t think SUPA should adopt this constraint … service chains and paths will be important components of service delivery (including the case of a “chain” with only a single service) and must, therefore, be manageable via policy … IMHO.

- I believe that the ONOS Intent Framework should be included in the gap analysis (slide #5 onward).

Avanti,
BobN

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Saturday, March 21, 2015 5:18 PM
To: Jun Bi; John Strassner; [email-masked]
Subject: [Supa] Update to Gap Analysis 5a

I was asked to update slides 6 and 7 according to my comments. They are attached. Change log:

Slide 6
1.  ODL GBP pre-dates GBP in OpenStack, so I moved it forward one slide to slide 6 and deleted it from OpenStack

3. Updated NIC description to be more accurate (e.g., first bullet, which set that the models were "often closely relating to the actual configuration of devices") is incorrect. Intent should NEVER use the actual configuration of a device.

Slide 7
Rewrote all 3 bullets under the Congress section to correct them as described in my original email.

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sat, 21 Mar 2015 21:58:05 -0700

Hi Bob,

that is a good observation. Furthermore, it does not appear to me that SFC
is using policies to control the SFC. SUPA would there be different in at
least two ways (using both ECA and/or intent-based policies):

   1) **static** configuration of the services to be chained together (the
norm today)
   2) **dynamic** configuration, based on changing context, of the SFC

I am particularly interested in the second. So, I modified slide 4 (line 9,
second sub-bullet of SFC)

Regarding ONOS, I added this in slide 6

regards,
John

On Sat, Mar 21, 2015 at 8:01 PM, Natale, Bob <[email-masked]> wrote:

> - On slide #4, in the SFC section: “overlap could be avoided by not
> providing models targeting service chains specifically” … I don’t think
> SUPA should adopt this constraint … service chains and paths will be
> important components of service delivery (including the case of a “chain”
> with only a single service) and must, therefore, be manageable via policy …
> IMHO.
>
>
>
> *From:* Supa [mailto:[email-masked]] *On Behalf Of *John Strassner
> *Sent:* Saturday, March 21, 2015 5:18 PM
> *To:* Jun Bi; John Strassner; [email-masked]
> *Subject:* [Supa] Update to Gap Analysis 5a
>
>
>

-- 
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 22 Mar 2015 10:43:22 -0400

John:

You might want to read the current I2RS charter and adjust your Gap Analysis.  After my chat with Tina on Friday, I think we have a good idea of where SUPA, I2RS, and intent based networking works.  

I2RS charter covers: 

1)      Protocol independent RIB  (1 Info model approved, 1 Data Model pending)

2)      Protocol independent topology (generic, L1, L2, L3, Service topology) pending

3)      Filter-Based RIBs.  (drafts pending) 

4)      Specific protocol to do I2RS Work (presentation in Netconf) 

I’m working on slide for SUPA for I2RS, and I will send them before 6pm.  Here’s a diagram: 

Applications 

     |

     |Intent-based languages (E.g. Nemo, ODL NIC project) 

Services 

    |   

I2RS (RIB, FB-RIB, Protocol independent topologies – L1, L2, L3, Service Topologies)  

   | I2rs interface (restconf/netconf+) 

   | 

Devices 

Sue 

Slide 6

Slide 7

-- 

regards,

John

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 22 Mar 2015 10:47:26 -0400

John:

Please pardon my sleepiness for I left out a few words.  See the appended note below with my editions below. 

Sue  

From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Sunday, March 22, 2015 10:43 AM
To: 'John Strassner'; 'Jun Bi'; [email-masked]
Subject: Re: [Supa] Update to Gap Analysis 5a

John:

You might want to read the current I2RS charter and adjust your Gap Analysis.  After my chat with Tina on Friday, I think we have a good idea of where SUPA, I2RS, and intent based networking works each fits.   

I2RS charter covers: 

Applications 

     |

Services (Supa )

    |   

   | 

Devices 

Sue 

Slide 6

Slide 7

-- 

regards,

John

---

From: John Strassner <[email-masked]>
Date: Sun, 22 Mar 2015 09:39:39 -0700

Hi Sue,

Jun did the I2RS gap analysis.

However, I don't understand the diagram you included. I don't see anywhere
in the I2RS charter where you are working on intent-based languages, and
furthermore, this seems a bit out of place with low-level RIB work. Please
explain.

regards,
John

On Sun, Mar 22, 2015 at 7:43 AM, Susan Hares <[email-masked]> wrote:

> John:
>
>
>
> You might want to read the current I2RS charter and adjust your Gap
> Analysis.  After my chat with Tina on Friday, I think we have a good idea
> of where SUPA, I2RS, and intent based networking works.
>
>
>
> I2RS charter covers:
>
>
>

-- 
regards,
John