Re: [Apn] [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 5A2BE3A0F3A; 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 zRTZQbpKFLWV; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C89033A0F38; Mon, 21 Sep 2020 07:03:24 -0700 (PDT)
Received: by with SMTP id u3so7195889pjr.3; 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=ltRpKXezhaR/GCS58wnhmM3EznfLHmjZdvt0Y80bhFkzdnUe4S3CaFgWyC0iNGdlds 1+rHuyY/um8nsQTO+8t4bCole7RpdTJaya6lJzHNw82P7V2LlpqTb9WNovfdeM/Wb8Q+ abqf4UlCvLuZah3E2SbY1pNNryqRnYd83y99ucvDyY1zpLsbovhw1/TF+gHuY5wOb5fx Qq3ysjq8BDDT2GJpiG60PvV5On5kLru39jteOWpTP4hjxzOOFej46P71nBdoR+YMiCQD Tzs/kmNhBCBCxUVgMDYcP3nPwYoRgYdi4aT+USqZeZAAPS8L/CvCS1W/0k+6S5DVeFY3 Y46w==
X-Gm-Message-State: AOAM531Gvd2c4AnK5cVqwimV2BbQxAvCstOSLHMnR8RF93bQxkN3u+24 thakunL0xWKV1+wiUl76/QBYgOh2CXi1jA==
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: [Apn] [arch-d] Questions for APN: Q#3 and Q#4
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: Mon, 21 Sep 2020 14:03:26 -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.