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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 09 July 2014 20:46 UTC

Return-Path: <eckelcu@cisco.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 D88E71A0007 for <openv6@ietfa.amsl.com>; Wed, 9 Jul 2014 13:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wUImRvQhFLrn for <openv6@ietfa.amsl.com>; Wed, 9 Jul 2014 13:46:06 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267F21A0011 for <openv6@ietf.org>; Wed, 9 Jul 2014 13:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5374; q=dns/txt; s=iport; t=1404938794; x=1406148394; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=muG1G8AtIGK8vWlu6BJkYJZUFtnXI0G94N8Am3d8AkQ=; b=is31DyXvU0t5/G82jWh7uQrgrfwDjxg7UtbfH3KuaKfyTFGyKILchhQt o11HN2LjOI45amFr3zoGKwBnt97CoACo38nD5diM+eZ7LWajD/IaHKHy8 9Bf+kTVbvkCTEpacvWvE+Lr6Ly0CbvX6hyvuALq26dcO3q0HHeekZUYkD c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAC2pvVOtJV2c/2dsb2JhbABZgw5SWoJvvCwIhm5TARl3FnWEAwEBAQQBAQExOhsCAQgSBgQoAgIfBgsXDgIEARKILgMRDZIbnB8GknYNhwMXgSaLcoIPIoJxgVIFmHaCAIFIjDCGFINDbIFE
X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="338675643"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2014 20:46:33 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s69Kk54q014778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 20:46:05 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 15:46:04 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>, "openv6@ietf.org" <openv6@ietf.org>
Thread-Topic: [Openv6] Comments on draft-karagiannis-aponf-problem-statement-02
Thread-Index: AQHPm7bNMp7QAxpjI0id74Y63JT15w==
Date: Wed, 9 Jul 2014 20:46:04 +0000
Message-ID: <CFE2F691.2D67E%eckelcu@cisco.com>
References: <53BC9F97.20704@gmail.com> <CFE2CADB.2D654%eckelcu@cisco.com> <53BD9FE3.9020006@gmail.com>
In-Reply-To: <53BD9FE3.9020006@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.93.114]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <4C2BE8466897914D8FFFC7984FEC3B7D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/JzdaZ0rb5oiEi9PwoFO_tEn3AlE
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: Wed, 09 Jul 2014 20:46:08 -0000

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

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