Re: [Openv6] [Aeon] Next step, IETF 90?

"Jun Bi" <> Mon, 21 July 2014 20:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E71501A049C; Mon, 21 Jul 2014 13:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgIJdoH5CIpo; Mon, 21 Jul 2014 13:49:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2AB611A0070; Mon, 21 Jul 2014 13:49:51 -0700 (PDT)
Received: from junbithinkpadx1 (unknown []) by app2 (Coremail) with SMTP id C8xvpgAnLh7MfM1T21d9AA--.3396S2; Tue, 22 Jul 2014 04:49:23 +0800 (CST)
From: "Jun Bi" <>
To: "'Reinaldo Penno'" <>, "'Charles Eckel \(eckelcu\)'" <>, "'Tina TSOU'" <>, <>, <>
References: <> <00bb01cf95f7$e9ef2b60$bdcd8220$> <> <> <> <> <> <00e701cf9b74$41ddf2d0$c599d870$> <> <005401cf9ce0$f1e9c330$d5bd4990$> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 21 Jul 2014 16:49:11 -0400
Message-ID: <002b01cfa525$3df58fb0$b9e0af10$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CFA503.B6E660B0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHjPp0X66qMpwxRxhDPCTMvUPpQAgCfkzG1AaiI4LsBl+37qAJBl//2ARmaFIQBmEHGHwDoEgHZAf6xC/cAs35+gwC68+r5AXLRMqsCvER+aAG6VGIwAWnVoLMCeji9V5rMEZ5g
Content-Language: zh-cn
X-CM-TRANSID: C8xvpgAnLh7MfM1T21d9AA--.3396S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Zr47Cw15Ary5Zr4ruF1fXrb_yoW8uw4fpr W7tFZxA3ykWryxCr4rZw18Was5WFZ5CrZ3GFy3J3s7uwn8CF18KryIyr15Xa4kGr1xZ34j vrsI9FyUu393A3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUsKb7Iv0xC_Cr1lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8I cIk0rVWrJVCq3wA2ocxC64kIII0Yj41le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67 k08I80eVW5JVWrJwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAq x4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6x8ErcxFaV Av8VWkJr1UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l7480Y4vEI4kI 2Ix0rVAqx4xJMxAIw28IcxkI7VAKI48JMxAIw28IcVCjz48v1sIEY20_Kr1UJr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q 6r43MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x0UUjRA7UUUUU=
X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/
Subject: Re: [Openv6] [Aeon] Next step, IETF 90?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Jul 2014 20:49:57 -0000

Hi, all,


Just spent some time to read all messages in this thread. 


My personal conclusions are:


1 AECON and APNOF are not the same, as pointed by Tina's ppt and messages
from others. Basically, I think AECON is for device's new interfaces on
flows characters for end user application ("The purpose of Application
Enabled Collaborative Network (AECON) is to enable communication between
applications and the network by active information exchange"." This exchange
provides network nodes with visibility of the application flow
characteristics. While ANONF is for the network operator's policies


2 For your question below, I don't think (2) means to specifies what to do
inside a device. By my understanding (might not be very precisely), APNOF
specifies an architecture, with new or excision to existing signaling
protocols to support it. So APONF does deal with interoperability between
network elements, therefore, I believe it fits for IETF's scope.



Jun Bi

PS. part of APNOF's goals might overlaps (in some degree) with Open Daylight
project. But ODP is just an open source organization, not a SDO, so IETF
might be a venue for standardization.



From: [] On Behalf Of
Reinaldo Penno
Sent: Monday, July 21, 2014 2:18 PM
To: Charles Eckel (eckelcu); Tina TSOU;;
Subject: Re: [Openv6] [Aeon] Next step, IETF 90?


I just responded to the other comment but (2) does not seem to be IETF work.
IETF is about on the wire protocol interoperability, what happens inside a
device probably has a good venue in some other SDO.  

On 7/21/14, 2:11 PM, Charles Eckel (eckelcu) wrote:

Perhaps some network devices will allow themselves to be controlled by end
user application applications, but that is not the model proposed by AECON.
Rather, AECON separates:

1.	the communication of the flow characteristics from
2.	the policy decisions and actions made by network devices based on
that communication

AECON is about the first, not the second.