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

[Tom Taylor <[e-mail]>]

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

On 10/07/2014 2:26 PM, JF Tremblay wrote:
> 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 <[e-mail]> 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:
>>
>> 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 09/07/2014 1:36 PM, Charles Eckel (eckelcu) wrote:
>>> 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
>>>
>>> On 7/8/14, 6:49 PM, "Tom Taylor" <[e-mail]> wrote:
>>>
>>>> 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
>>>>
>> ...
>>
>> _______________________________________________
>> Openv6 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/openv6
>
>