Subject: [alto] Some thoughts of introducing filtering of FCI informaiton

From: Shawn Lin <[email-masked]>
Date: Mon, 11 Dec 2017 22:18:42 +0800

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