[alto] Discussion about Extended ALTO Endpoint Address

Jensen Zhang <jingxuan.n.zhang@gmail.com> Wed, 13 December 2017 01:23 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D021C126CBF; Tue, 12 Dec 2017 17:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 z-mfTgeskOim; Tue, 12 Dec 2017 17:23:09 -0800 (PST)
Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B723C120727; Tue, 12 Dec 2017 17:23:03 -0800 (PST)
Received: by mail-oi0-x241.google.com with SMTP id 184so553816oii.2; Tue, 12 Dec 2017 17:23:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=HSRoqGv6WLHGGIL6kjl1rq3hIRKyN7JTkr60QQuVLKE=; b=uuWAaBH7onhtAlwwuzpweyrlXySMW913DObkFRGbiAaVRAtoeK3njqeVrxBZfidvoG qyd0VbvM3gHlzAwtPDe/MvfiowaNKe4TqVCNJQ2G52flD/l2P/or/cYw5CzLWLFk/1UM COEWpbQJKjsfrNF92y4VuouacEWaq/yrbEoJtQ4pZpfr4fDyadmiaVenF+v0cUmHI0o5 DKvY9TZqxNqqZo6MzY8IVkRDKwnIU1tG10Z7YyBFQYwW1yPLEzgL+FFbSdefzkD92FWF oX8HcQc/MeJU5mpW+nWlixIIT5z4qT0DVokfN/mIahdeh2kXyczXF4acR5tJCuepm3dW VGLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=HSRoqGv6WLHGGIL6kjl1rq3hIRKyN7JTkr60QQuVLKE=; b=C9bcDyyuJ9rK2gdOQUmnVEF9MQhSWbdg2ZU3JtqeN1hc/CdBD3CyCui494LrREs901 jecf1Qhri8NCwtdLGrFQEVred5V+FrR+NH41xYvtB+8GfqL/Ri1thzXcUOUlURTBXeov mUCPiEWzG4oKnWSpvyMkyeAu1x3+dGZCeZAWKToZhzyZ7i0iWLS+X/lqsTSlsiUoVSQt FccGp17HTS+T01e/lPaPPUikuCaTnMfeZQ5XUkgc9kpqmyL035rt238G1p97mwbpjsa4 qim44A0opPtF98QsLUgKXmnLMWzRFRui4uyYWLOY0vYg/mXZ3HEvJmkNEbj8auo0+Ce3 UAiA==
X-Gm-Message-State: AKGB3mI4vJ7z1bffxwdkW5vp3n1CNIJMYaq9ToxYWBnKh5HxyEQpBUaU LygLJZfkzKbe8D+KYV6rnvPNR2E5+DOvEsrgW24=
X-Google-Smtp-Source: ACJfBov4eslqlQG9cAlmj5jUsT5lFH65YFEFYw/NsuSE6Hxqj11FfxXpCX80NgBgrBu47zRGJTfX2Tf22UgGP+dFJoI=
X-Received: by 10.202.178.196 with SMTP id b187mr642392oif.264.1513128182763; Tue, 12 Dec 2017 17:23:02 -0800 (PST)
MIME-Version: 1.0
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Wed, 13 Dec 2017 01:22:52 +0000
Message-ID: <CAAbpuyqVmzdwh75h0n=8fm68A-UJ_GBfFn4ZGkNAYYVnSRPr2Q@mail.gmail.com>
To: draft-randriamasy-alto-cellular-adresses@ietf.org, draft-gao-alto-fcs@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cdff2d5554f05602e9b96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/H3uH0Wsw6ImBq0j7iv9JR62U_f0>
Subject: [alto] Discussion about Extended ALTO Endpoint Address
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 01:23:12 -0000

Hi all,

Because several recent drafts (cellular addresses and fcs) meet the same
requirement of registering new ALTO address types, I think it's time to
propose it as a general problem and have a good discussion.

If you take a quick look at the section 5.2.2 of the latest fcs revision
[1], you will find we are requiring a new registry called "ALTO Address
Type Conflict". The key insight is that some address types cannot appear in
the associated source and destination addresses. For example, the following
filter is invalid:

{
  "srcs": [ "ipv4:192.168.1.100" ],
  "dsts": [ "ipv6:::1" ] // Just take an example. The loopback address
should never appear in the ALTO resource.
}

In the legacy ALTO, we can just declare different address types conflict
with each other. But when we register a new address type A, it may be
allowed to appear with some existing address types. So we need to indicate
which existing address types conflict with the new address type A, and
which ones do not.

"ALTO Address Type Conflict Registry" [2] is a solution proposed by us. But
there is a potential issue: it is not scalable. Because the future
registered address type will have to declare more and more conflicts as the
growth of the address type registry.

And since it is a general problem, do you think it is a good idea to start
a new draft focusing on this problem? I think both cellular addresses draft
and the endpoint address extension part of FCS will benefit from it.

[1] https://tools.ietf.org/html/draft-gao-alto-fcs-04#section-5.2.2
[2] https://tools.ietf.org/html/draft-gao-alto-fcs-04#section-9.2

Thanks,
Jensen