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

JF Tremblay <jean-francois.tremblay@viagenie.ca> Thu, 10 July 2014 18:26 UTC

Return-Path: <jean-francois.tremblay@viagenie.ca>
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 96A681A0296 for <openv6@ietfa.amsl.com>; Thu, 10 Jul 2014 11:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 p6hAAqaJIXUL for <openv6@ietfa.amsl.com>; Thu, 10 Jul 2014 11:26:39 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 39FA51A0AB2 for <openv6@ietf.org>; Thu, 10 Jul 2014 11:26:39 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 54E5640396; Thu, 10 Jul 2014 14:26:38 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B94189CD-563B-432D-8372-F62FFC4B363F"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: JF Tremblay <jean-francois.tremblay@viagenie.ca>
In-Reply-To: <53BD9FE3.9020006@gmail.com>
Date: Thu, 10 Jul 2014 14:26:38 -0400
Message-Id: <02D9436B-2755-4D83-84DD-A4A668D55758@viagenie.ca>
References: <53BC9F97.20704@gmail.com> <CFE2CADB.2D654%eckelcu@cisco.com> <53BD9FE3.9020006@gmail.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/-9dWWAtTu4zywP2xs7ja38yTsr4
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 18:26:41 -0000

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