[alto] Some thoughts of introducing filtering of FCI informaiton

Shawn Lin <x.shawn.lin@gmail.com> Mon, 11 December 2017 14:18 UTC

Return-Path: <x.shawn.lin@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 16258126CD8; Mon, 11 Dec 2017 06:18:49 -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 iqYr0nz7A23h; Mon, 11 Dec 2017 06:18:46 -0800 (PST)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 23C02126DEE; Mon, 11 Dec 2017 06:18:45 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id s66so17759708wrc.9; Mon, 11 Dec 2017 06:18:45 -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=MWpZSUOxVMqAEP24QfIuSR7OL1vxjXfkQqn0A1GxG78=; b=GzjeGSiYsGB8JjUZn5TX9r9sIDUU3pz43baQX0yC1POZWjCJq7tXVzLBhK8Jbd2LZ0 U6oxbw50dRCGYO9ka6LsJ5/VUnVuHEKfZpTPtSVPm1HkerWd17qCwIPiXlhWdjCZoXpG c2XVNGU6Jm00kOY5r15J8M+Wjha+Gds6s1p0iScziFE8JsJASrRHOfKbL0OEvEMiNZkm GHSKVIFW/1bVd19IPmat8mRsXTF0eQlQk/QXAN5KSn2z3IGaLrzZKGmbBrleGvRhp/cF Hb3UGC5M9AP21ACjE6bqE3n+arS/XtCKS2ueD+LMjZLoww5pIh3OXH3NgNpk5gmqGfgS PlPQ==
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=MWpZSUOxVMqAEP24QfIuSR7OL1vxjXfkQqn0A1GxG78=; b=lNlWayr+BoxRFdYiGfmIcJDsaIkezTBb1jVmS0gGX2uRdes1a7urghCmoDcxEOOJXb egCJ+7XjarSSLbm3MZdtV936XjOWjtn7y7he+FJk82uEE2+xonFIfdv2KIaeFRdoG9ee 3VF/HAxvVbdHkAlbCFAij/iYWqFWTdhdBPghVhG82CC5Jb0TUlYJ7boSxvE6+t90vWcP yk9a3fdPAl1l9QUfay7diK/08Q986w+cI7AUHuumtPl146t3ucnNQTXqzG5HARnMY8di NAPFcE/oMRdsmyGsLwUXl4hxT2IubE8vl0afUfwvPDgMhw9NJgTLni44J+bQDYJNIEMX 9HTA==
X-Gm-Message-State: AKGB3mIZAaCdAEsJpUIyo2Dx1JpmU+lyDcBOtX/X6a9XZeKhjVAggLO4 rjQBfhMTmxZ/VJXBcCZ2qoGqgBX4akCYzVuv51gbGw==
X-Google-Smtp-Source: ACJfBosV3CiZepMnMMCaqGLjglKVSty/ATpjg+SgVRN8ZoFd0OHzPNObBo2/Y/UNO3fLn9av8ABdoSVMFAn/euGy5Vk=
X-Received: by 10.223.156.202 with SMTP id h10mr591528wre.174.1513001923426; Mon, 11 Dec 2017 06:18:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.172.195 with HTTP; Mon, 11 Dec 2017 06:18:42 -0800 (PST)
From: Shawn Lin <x.shawn.lin@gmail.com>
Date: Mon, 11 Dec 2017 22:18:42 +0800
Message-ID: <CA+oaSDrFPVX_156x_nGJ39O79w2+Ley82xKCx9gvuCvccebEWA@mail.gmail.com>
To: draft-ietf-alto-cdni-request-routing-alto.authors@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="f4030439614430bc0c05601136a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/8Jjd-Jqk5EMwzVfXwFWFSzQ7Djw>
Subject: [alto] Some thoughts of introducing filtering of FCI informaiton
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: Mon, 11 Dec 2017 14:18:49 -0000

Dear authors of draft-ietf-alto-cdni-request-routing-alto-00 and ALTOers,

I have some thoughts about introducing filtering of FCI information and
integrating FCI with ALTO unified properties map. Any comments are welcomed
and highly appreciated!

One FCI capability consists of "capability-type", "capability-value" and
"footprints" [RFC 8008]. And the type of "capability-value" depends on the
value of the "capability-type". So only filtering based on
"capability-value" is not proper. "capability-type" and "capability-value"
determine one dCDN's capability together, and the "footprints" determines
the coverage area of one dCDN. There are four situations that we could
potentially filter on.

1. filter on "capability-type";
2. filter on "capability-type" and "capability-value";
3. filter on "footprints";
4. filter on "capability-type" and "capability-value" and "footprints".

For situation 1 and situation 2, we could learn from the ALTO Map-Filtering
Service. We may need one new concept which is FCICapability. It consists of
"capability-type" and "capability-value". The "capability-type" is required
while "capability-value" is optional.
Here is an example.

This is the full fci map.
{
  "meta": {},
  "fcimap": {
    "capabilities": [
      {
        "capability-type": "FCI.AcquisitionProtocol",
        "capability-value": {
          "acquisition-protocols": [
            "http1.1"
          ]
        }
      },
      {
        "capability-type": "FCI.AcquisitionProtocol",
        "capability-value": {
          "acquisition-protocols": [
            "https1.1"
          ]
        },
        "footprints": [
          {
            "footprint-type": "asn",
            "footprint-value": [
              "AS0",
              "AS65535"
            ]
          }
        ]
      }
    ]
  }
}

The one request body example of filtering fci map is like below:
{
  "capabilities": [
    {
      "capability-type": "FCI.AcquisitionProtocol",
      "capability-value": {
        "acquisition-protocols": [
          "http1.1"
        ]
      }
    }
  ]
}

The response may be like below:
{
  "meta": {},
  "fcimap": {
    {
      "capability-type": "FCI.AcquisitionProtocol",
      "capability-value": {
        "acquisition-protocols": [
          "http1.1"
        ]
      }
    }
  }
}

For situation 3, the goal of filtering on "footprints" is to get the
capabilities of a given sets of footprints respectively. And this goal can
be expressed by ALTO unified properties map quite well. Currently, there
are four major ways (ipv4cidr, ipv6cidr, asn(Autonomous System Number), and
countrycode) to describe a footprint. And the Unified Properties map has
already had IPV4 Domain and IPV6 Domain so ipv4cidr or ipv6cidr footprints
can be easily mapped into the entities. And for asn and countrycode
footprints, we can register two new domains in Unified Properties Map
namely ASN and COUNTRYCODE. With these prefixes, we can translate the asn
and countrycode into entities easily. Next, we need to register a new
PropertyName such as FCICapability and the corresponding JSONValue would be
like {"capability-type": {}, "capability-value": {}}.

For situation 4, it may be too fine grain. Not sure whether we have some
use cases for this situation.

Look forward to hearing from you.

Bests,
Shawn Lin