Re: [arch-d] Questions for APN: Q#3 and Q#4 Mon, 21 September 2020 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8516C3A0F38 for <>; Mon, 21 Sep 2020 07:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnxpnXaOov8v for <>; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D24E93A0F39 for <>; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
Received: by with SMTP id a9so7543681pjg.1 for <>; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=S7+GUzU9GS0+S7b1m9FZoRobt4u6SxY9SEuMm6Wx0zA=; b=BZ/SCFu0uiF4xOHmzfjD2TfGjyX8Q4mmK3uiV/B0MmR3uy3ieNCrh48slYFIu6aZWT BtFUdV81vSiiWblsIwQ3iYDju4Sf4OJ5zoKmUtxxIDN7b6R314nxXU6ijzPplegyLhX0 VMaKga/kWfSpX50Nhej94mPqYMqSMRl76kGNmj3RmMNhAOcTzlzjnIKz9xWakR24ZpRt IpFu/+FMC9yyEUKPaHnP/pxkM6FvgMMtrTT46KEGJIw2JZjYNzQQN3YqIOP6CA67P+YF efkS85JQ7QCRmJxRVBfJyY4ODyGblWO9gn6JbtIW4p6khzXlzDW70s7v26PifDRKyVET zvmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=S7+GUzU9GS0+S7b1m9FZoRobt4u6SxY9SEuMm6Wx0zA=; b=o/Opl2AYE5pY46oStQ5lVREhBIhMyCzUK9MwJFlgxww2nsvKet7c35/Vwq/sc4tQt8 Aewbm1r9yMf8fPvFlnqi6ihqNg2t4KePx+OnsUlR3/iqKdrGIx7pLP9/kAbM56gObOK2 UQW8bf6cddzJZOI3Vz2p3DibLfpzk/NgWjgYGXUGwbz1n7tCGcf7mKmx1eTx6d7jQEaM rL5iVXtHqIvM05rrbW8cFmCALGxMAUyudrwt1i7+EJsE6zcX2CogHJ06JjKriVgVCGPp 3b97h8W1XjSJp9YnHLEKKeDpjk4YxCybgfMTV3WWohmEEGPQrCGAa+Qg5uZ1wjUW0d3t 5vAA==
X-Gm-Message-State: AOAM5308n0pqRcin+o11UWihh0BMBSN6k0oidzpMO5XUkOJK+/ir0odl pMs3wWouZpjRwIIRV3P/89A=
X-Google-Smtp-Source: ABdhPJzQfgkzBeUhJHICo5FiWf8bP2D1VlaufYtVjuZXSdBrV1ibND6eAQozUD31m1ndQJN1XU6vpA==
X-Received: by 2002:a17:90a:a60e:: with SMTP id c14mr21277pjq.31.1600697004127; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id i2sm12365583pfq.89.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Sep 2020 07:03:23 -0700 (PDT)
Sender: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1F8E30E-60F2-4688-9730-5398FD6EA993"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 21 Sep 2020 07:03:21 -0700
In-Reply-To: <>
Cc: "" <>, "" <>, "" <>
To: "Pengshuping (Peng Shuping)" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [arch-d] Questions for APN: Q#3 and Q#4
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Sep 2020 14:03:27 -0000

Hi Shuping,

> APN doesn’t really introduce any change in any routing protocol. The goal is to be able to better classify packets and assign them to policies. How these policies are defined and operated are outside the scope of APN and rely on existing routing policy technology.

Then perhaps RTG is not appropriate.  Perhaps INT would be more to the point.

> Extension headers have been there for a while so I don’t believe that utilizing existing IPv6 extension headers could be considered as a “major change in the data plane”.

I await specifics. I infer that you want at least an order of magnitude increase in the scale of forwarding plane statistics. To my mind, that alone qualifies.

> Basically, in APN, the application data packets contains some bits in the header that will be used by the operator ingress devices in order to steer the packet into a pre-defined and installed policy (e.g. a traffic engineered path or a source routed path). The current state of routing protocols allow the provisioning, computation and installation of these policies without any additional change.

If the point is not additional control, then your needs seem to be focused on scale.  What granularity of detail are you anticipating and what is the resulting scale? I infer that DSCP is an inadequate mechanism, so what classification mechanism are you suggestiing? Or is are we trying to do full per-flow tracking? If so, what managerial mechanisms are you suggesting for offloading this? Current day telemetry is nowhere near this.

> Is there a discussion anywhere of the costs of this approach and a cost/benefit analysis? Have you considered the scalability of a solution?  What about the added complexity to the architecture? My apologies if I’ve missed something obvious.

I’ll renew these questions as you haven’t addressed them.


p.s. I agree with Christian.