Re: [Apn] APN BoF, thoughts on what to standardize and what to not standardize

"Pengshuping (Peng Shuping)" <> Fri, 30 July 2021 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEEF03A1200 for <>; Fri, 30 Jul 2021 14:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zeDvkkguQZGY for <>; Fri, 30 Jul 2021 14:38:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FA693A1201 for <>; Fri, 30 Jul 2021 14:38:12 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Gc0nY05kPz6L9jt for <>; Sat, 31 Jul 2021 05:26:09 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 30 Jul 2021 23:38:08 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 31 Jul 2021 05:38:06 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Sat, 31 Jul 2021 05:38:06 +0800
From: "Pengshuping (Peng Shuping)" <>
To: "Charles Eckel (eckelcu)" <>, "" <>
Thread-Topic: APN BoF, thoughts on what to standardize and what to not standardize
Thread-Index: AQHXhYkT8AaHbzTOskK37OUJvZRw8atcCKug
Date: Fri, 30 Jul 2021 21:38:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Apn] APN BoF, thoughts on what to standardize and what to not standardize
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 21:38:17 -0000

Hi Charles, 

Many thanks for sharing your thoughts! You have clearly got the key points of the APN work, which made me extremely happy and cheered me up that I was actually being understood. 

I fully agree with you, and you are very welcomed to work together on these items. 

Besides the items we may also want to consider the control and management plane protocol extensions. 

Thank you and Cheers! 

Best Regards, 

> -----Original Message-----
> From: Apn [] On Behalf Of Charles Eckel
> (eckelcu)
> Sent: Saturday, July 31, 2021 5:23 AM
> To:
> Subject: [Apn] APN BoF, thoughts on what to standardize and what to not
> standardize
> Thanks to the chairs and presenters for an informative BoF.
> We ran out of time before I was able to share my thoughts on the first two
> questions posed by the chairs, what to include and what to exclude from
> potential standardization related to APN. My thoughts are as follows:
> 1) Standardization of the APN attribute
> I have seen the need for a well defined attribute such as this many times, not
> only in IETF, but also in MEF and the Linux Foundation. I believe the
> standardization of this would be useful, though I am not sure IETF is the best
> place to do it.
> 2) Determination of APN attribute to assign (non-standard) - exclude This
> determination could be based on the 5-tuple or any other mechanism
> available to the operator, and since APN is meant to be used within the
> administrative domain of a single operator, there is no need to standardize.
> 3) Standardization of mechanism to encode, decode, and transport APN
> attribute within one or more existing encapsulation mechanism.
> Several people mentioned this. Rather than invent yet another encapsulation
> mechanism, show how the APN attribute could be used within the context of
> existing encapsulation mechanisms.
> 4) Determination to what to do with the APN attribute (non-standard) -
> exclude This is an operator specific determination. No need to standardize.
> Cheers,
> Charles
> --
> Apn mailing list