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

["Charles Eckel (eckelcu)" <[e-mail]>]

On 7/9/14, 1: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.

That sounds okay.

>
>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?

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

>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