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

Tom Taylor <tom.taylor.stds@gmail.com> Thu, 10 July 2014 19:11 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F353E1B2986 for <openv6@ietfa.amsl.com>; Thu, 10 Jul 2014 12:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 958djCFsfp3D for <openv6@ietfa.amsl.com>; Thu, 10 Jul 2014 12:10:59 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5061B297E for <openv6@ietf.org>; Thu, 10 Jul 2014 12:10:59 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id y20so21055ier.27 for <openv6@ietf.org>; Thu, 10 Jul 2014 12:10:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sl9jB7WtdZOG+Kr+kRGZL0ao+tZkbhke7ms8gWfa9HE=; b=dAcb35I2OC6dl5zpuuTQRjsQ658Lz3pEu1HfeehTE/cI8zQM7seYtT1+nebJFAy7kt ZS9UB9kAdFhTSyBfZQJ0kpS/m1V12ow4qk3gpRRWGnHoNa62vamwRiAAkqr1WKyiBXtk DM6LQEzizmfagDDuZR7+Vp2hhC3BDjSR8NChiMxGrUTY1zGM6RFOk2OdiFKttOaiaexW illtEz8ulfekRr/hOw341WHBFfeKby8fkln6+r0JWn9+rnkebpx/yh2DsyXtyln0ns9B YZJbK7uJMbD764qvGLi27m6LX8vOx1e8ffJ6kB6+z/2KsagyRAIDwrW6+dQwJwjj9Kh2 BUoA==
X-Received: by 10.50.43.202 with SMTP id y10mr24057942igl.10.1405019458980; Thu, 10 Jul 2014 12:10:58 -0700 (PDT)
Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id nl8sm1103385igb.4.2014.07.10.12.10.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 12:10:58 -0700 (PDT)
Message-ID: <53BEE540.5060902@gmail.com>
Date: Thu, 10 Jul 2014 15:10:56 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: JF Tremblay <jean-francois.tremblay@viagenie.ca>
References: <53BC9F97.20704@gmail.com> <CFE2CADB.2D654%eckelcu@cisco.com> <53BD9FE3.9020006@gmail.com> <02D9436B-2755-4D83-84DD-A4A668D55758@viagenie.ca>
In-Reply-To: <02D9436B-2755-4D83-84DD-A4A668D55758@viagenie.ca>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/1DLCH8gL9lS7ngd_BLEFxovU8O0
Cc: "openv6@ietf.org" <openv6@ietf.org>
Subject: Re: [Openv6] Comments on draft-karagiannis-aponf-problem-statement-02
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jul 2014 19:11:05 -0000

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 <tom.taylor.stds@gmail.com> 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" <tom.taylor.stds@gmail.com> 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
>> Openv6@ietf.org
>> https://www.ietf.org/mailman/listinfo/openv6
>
>