Subject: [Openv6] Comments on draft-karagiannis-aponf-problem-statement-02

From: Tom Taylor <[email-masked]>
Date: Tue, 08 Jul 2014 21:49:11 -0400

The APONF problem statement is definitely shaping up, although I think 
there are still some extraneous elements that were pasted in from the 
draft charter but don't really belong in the draft. I complained about 
the presence of architectural descriptions in earlier versions, but I 
suggest a summary figure showing the high-level architecture would be 
helpful in the description of the different aspects of total problem as 
they relate to different WGs. Here is the figure I have in mind, based 
on my reading of the problem statement:

                     ---------------
                     |  End user   |
                     | application |
                     ---------------
                            |
                            |
                            |
                  AECON-developed interface
                    SFC-developed model
                   ---------------------
                   | Network management |
                   |   application      |
                   ----------------------
                            |
                            |     APONF
                            |   transport
                            |
                            | (SFC-developed
                            |  templates?)
                            |
                   ----------------------
                   | Network management |
                   |      control       |
                   | ... and then a     |
                   | miracle happens :) |
                   |   APONF-developed  |
                   |     mapping?       |
                   ----------------------
                            |
                            |
                   To individual devices

My suggestion is to have this at the end of the introduction and get rid 
of Section 5, which just repeats the same information.

I like the way the draft draws conclusions from the use cases and 
reflects them in the requirements. I will give that section closer 
scrutiny in a later E-mail.

Given that the draft draws attention to GIST as a candidate protocol, it 
would be good to include text explaining why this protocol in particular 
seems to be a good fit to the requirements.

Tom Taylor

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 9 Jul 2014 09:12:10 +0000

Hi Tom,
We actually have a document about the architecture, here is the link: http://www.ietf.org/internet-drafts/draft-zhou-aponf-architecture-02.txt.
Regarding the protocol, GIST may be a candidate. But we are also considering other protocols, e.g., netconf, restconf, and etc. The gap analysis document http://www.ietf.org/internet-drafts/draft-tremblay-aponf-gap-analysis-00.txt
explains why GIST fits to the requirements and will explain other protocols in later versions. 

Best Regards,
Cathy

> -----Original Message-----
> From: Openv6 [mailto:[email-masked]] On Behalf Of Tom Taylor
> Sent: Wednesday, July 09, 2014 9:49 AM
> To: [email-masked]
> Subject: [Openv6] Comments on
> draft-karagiannis-aponf-problem-statement-02
> 
> The APONF problem statement is definitely shaping up, although I think there
> are still some extraneous elements that were pasted in from the draft charter
> but don't really belong in the draft. I complained about the presence of
> architectural descriptions in earlier versions, but I suggest a summary figure
> showing the high-level architecture would be helpful in the description of the
> different aspects of total problem as they relate to different WGs. Here is the
> figure I have in mind, based on my reading of the problem statement:
> 
>                      ---------------
>                      |  End user   |
>                      | application |
>                      ---------------
>                             |
>                             |
>                             |
> My suggestion is to have this at the end of the introduction and get rid of
> Section 5, which just repeats the same information.
> 
> I like the way the draft draws conclusions from the use cases and reflects them
> in the requirements. I will give that section closer scrutiny in a later E-mail.
> 
> Given that the draft draws attention to GIST as a candidate protocol, it would
> be good to include text explaining why this protocol in particular seems to be a
> good fit to the requirements.
> 
> Tom Taylor
> 
> _______________________________________________
> Openv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openv6

---

From: Tom Taylor <[email-masked]>
Date: Wed, 09 Jul 2014 11:38:35 -0400

I did look at the architecture document while I was preparing my note, 
and verified that it dealt with more specific detail than what I 
proposed. That detail is what I was happy to see removed from the 
Problem Statement.

It seems to me that this draft should either reference 
draft-tremblay-aponf-gap-analysis or else the discussion of GIST should 
be dropped from the Problem Statement. A third possibility is to merge 
draft-tremblay-aponf-gap-analysis into this document, but that may be 
taking the Problem Statement too far into solution space.

Tom

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 9 Jul 2014 17:36:54 +0000

Hi Tom,

If I understand the diagram correctly, it would be more accurate to show
AECON for a line from the "end user application" to ³individual devices²,
assuming individual devices are network elements (e.g. routers, switches,
firewalls, etc.). AECON would not be used for end user application to
network management application communication, at least not directly.

Cheers,
Charles

---

From: Tom Taylor <[email-masked]>
Date: Wed, 09 Jul 2014 16:02:43 -0400

OK, I see I read too much into the APONF problem statement. Part of the 
problem is that I assumed at the back of my mind that the upper-most box 
in the figure was a management application, whereas AECON for sure 
assumes it is an user application. Since the APONF problem statement is 
talking about service development, I would modify the figure to show two 
top boxes:

End User Application, joined to devices with AECON input.

Service Development Application, joined to Network Management 
Application as already shown, but without AECON mediation.

I'm not quite happy with this because it isn't clear exactly how SFC 
fits in with AECON. draft-conet-aeon-problem-statement-01 says:
      "Flow characteristics communicated via AEON could be
       used as input into an SFC classifier and it could be transported
       as SFC metadata."
Does that mean SFC templates would go directly to devices?

Tom Taylor

>> on my reading of the problem statement:
...

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 9 Jul 2014 20:46:04 +0000

>Application as already shown, but without AECON mediation.

That sounds okay.

>Does that mean SFC templates would go directly to devices?

Perhaps, but I don’t have a clear picture of what an SFC template is. The
SFC classifier is as defined in
http://tools.ietf.org/html/draft-merged-sfc-architecture-00. I do not see
any mention of an SFC template.

Cheers,
Charles

---

From: JF Tremblay <[email-masked]>
Date: Thu, 10 Jul 2014 14:26:38 -0400

Hello Tom. 
I just catched up with this thread and something still isn’t clear in my mind. 

The model you suggested below seem to use 4 layers. User app, network management app, control and devices. What exactly would be the difference between the first two levels? What are the advantages of separating them in two distinct functions? 

Beside the fact a “user app” may originate traffic while a “management app” probably doesn’t, the functions performed by both seem to be similar. The management app could have an aggregation function over the simple user app, but I don’t see any other use. Access, authentication, authorization, management of the models are probablement functions better performed by the network control level, unless we want to move these up.  

Thanks for your thoughts on this.

/JF

On Jul 9, 2014, at 4:02 PM, Tom Taylor <[email-masked]> wrote:

> OK, I see I read too much into the APONF problem statement. Part of the problem is that I assumed at the back of my mind that the upper-most box in the figure was a management application, whereas AECON for sure assumes it is an user application. Since the APONF problem statement is talking about service development, I would modify the figure to show two top boxes:
> 
> Service Development Application, joined to Network Management Application as already shown, but without AECON mediation.
> 
> I'm not quite happy with this because it isn't clear exactly how SFC fits in with AECON. draft-conet-aeon-problem-statement-01 says:

---

From: Tom Taylor <[email-masked]>
Date: Thu, 10 Jul 2014 15:10:56 -0400

All I was trying to do with the diagram was to summarize what the draft 
was saying. Since then my exchanges with Charles have caused me to read 
the relevant documents from AECON and SFC, and I would certainly draw 
the diagram differently as a result.

But regarding the four levels, here is what the draft says (Section 1):

    In this context, *network management applications* can be used to
    provide the required configuration and application programming
    interfaces to such *service developers*. Subsequently, a network
    management application can use the application based demands and
    possibly update its associated network configuration and/or network
    topology model. Examples of network management applications that can
    modify the network configuration and/or network topology models are
    for example, Distributed Data Center Application and IPv6
    transitions, need to change the network infrastructure configuration.

    For each network service instance a network service graph needs to be
    generated and maintained.

    The up to date network service graph needs to (1) be communicated to
    e.g., the *network management and controlling systems*, (2) map the
    network configuration and network topology models into specific
    *device level* configuration models.

I've put asterisks around the terms that I interpreted as separate 
functional entities. If I have misinterpreted, I think it makes my point 
that a high-level architectural diagram is needed.

Tom

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 05:28:26 +0000

Hi Tom,

Thank you very much for your comments!

Regarding GIST, please note that NSIS is mentioned as candidate, based on the comments of IESG and IAB on APONF improvements. These comments were provided after rejecting the first APONF BOF request.

We will take your comments in considerations and the discussions that we will have in Toronto when updating the 02 version of the problem statement draft.

Best regards,
Georgios

________________________________________
Van: Openv6 [[email-masked]] namens Tom Taylor [[email-masked]]
Verzonden: woensdag 9 juli 2014 17:38
Aan: Zhouqian (Cathy); [email-masked]
Onderwerp: Re: [Openv6] Comments on     draft-karagiannis-aponf-problem-statement-02

Tom