Subject: [CDNi] New version of the footprint/capabilities semantics draft (now draft-ietf-cdni-footprint-capabilities-semantics-00)

From: Jan Seedorf <[email-masked]>
Date: Thu, 18 Jul 2013 15:01:10 +0000

Dear all,

The new version of the semantics draft captures the decisions of the design team we made in Orlando which capture quite clear what we regard as a footprint and as capabilities at this stage (and what not), including a concrete list of mandatory types of footprints and capabilities that solution protocols must support. Further, it addresses several comments received on this list from Scott (thanks), and probably most importantly it has an updated section of still open issues.

Especially since this is a WG document now, we would appreciate comments on the open issues (see Section 7 of the draft). We will try to make progress on these outstanding issues with the design team in Berlin. I will set up a doodle for a side meeting during the IETF-87 week exactly for that (i.e. discussing the open issues). Personally, I regard none of the open issues as major nor controversial, but I may be wrong.

 - Jan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 17, 2013 8:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

	Title           : CDNI Request Routing: Footprint and Capabilities Semantics
	Author(s)       : Jan Seedorf
                          Jon Peterson
                          Stefano Previdi
                          Ray van Brandenburg
                          Kevin J. Ma
	Filename        : draft-ietf-cdni-footprint-capabilities-semantics-00.txt
	Pages           : 18
	Date            : 2013-07-15

Abstract:
   This document tries to capture the semantics of the "Footprint and
   Capabilities Advertisement" part of the CDNI Request Routing
   interface, i.e. the desired meaning and what "Footprint and
   Capabilities Advertisement" is expected to offer within CDNI.  The
   discussion in this document has the goal to facilitate the choosing
   of one or more suitable protocols for "Footprint and Capabilities
   Advertisement" within CDNI Request Routing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Scott Wainner <[email-masked]>
Date: Thu, 18 Jul 2013 15:22:11 -0400

Jan,

     The draft seems to cover a lot of background / motivations for why 
we would settle on a set of mandatory footprint and capability 
semantics.  I suspect we will need to get down to some concise 
recommendations for defining the semantics.

Footprint
---------

    I think we need to define two classes of footprint for each IP 
protocol capability with one or more types:

     a. Geo-Physical
         - ISO Country Codes (mandatory)
         - Others? (optional)

     b. Topological
         - ASN (mandatory)
         - IP Prefix (mandatory)

My experience with commercial CDN's is they are reluctant to indicate 
WHERE their caches are located (topologically or physically); hence, our 
definition of footprint is likely relegated to where the CDN purportedly 
provides service (able and willing to serve).

Most global CDN's will avoid narrowing the scope of their coverage; 
their goal is to attract any traffic.  We might assume the default case 
is that all CDN's provide global coverage unless specified otherwise.  
So we need an FCI interface that the dCDN initializes with the uCDN that 
indicates a default global footprint exists (at a minimum).

     Example:
         IPv4
             Topological_Footprint:
                 IPv4=NULL or 0.0.0.0/0 (mandatory type)
             GeographicalFootprint:
                 CC=* (mandatory type)
         IPv6
             Topological_Footprint:
                 IPv6=NULL or ::/0 (mandatory type)
             Geographical_Footprint:
                 CC=* (mandatory type)

We might argue that a global CDN COULD advertise a global footprint 
while advertising an exception (i.e. everywhere except this CC or 
everywhere except this ASN).  I suspect that CDN's would NOT want to 
filter their default coverage; they would service requests from their 
next-best CDN location.  I don't see a lot of value in advertising 
exceptions; its too complicated and mess for a uCDN to analyze and evaluate.

If the dCDN includes a narrowly defined footprint coverage, I suggest 
the dCDN is asserting that it ONLY wants to provide coverage for that 
footprint (the global default is taken off the table).  There are very 
real reasons why a topologically bound CDN might want to do this; they 
don't have peering links to serve other ISP's customers.  Therefore, an 
advertisement from a dCDN means exactly what it intends.  The CDN only 
provides coverage for this footprint:

         IPv4
             Topological_Footprint:
                 IPv4=0.0.0.0/0
                 ASN=y
             GeographicalFootprint:
                 CC= MX, US, CA

I would propose that the footprint representation be a BOOLEAN AND 
function of all footprint representations.  In the example above, the 
dCDN only provides coverage in the geographical region of Mexico, United 
States, and Canada and only for those locations covered by ASN=y and 
only for IPv4 prefixes.

It is not mandatory for the dCDN to advertise multiple types within a 
class.  For example, a dCDN might only offer one type (the mandatory 
default) within a class:

         IPv4
             Topological_Footprint:
                 IPv4=0.0.0.0/0
             GeographicalFootprint:
                 CC= *

The proposed footprint attributes (e.g. ISO CC, ASN, PREFIX) seem like 
well defined semantics that are meaningful and useful.

Capabilities
------------

     There is no point advertising a footprint of a dCDN that doesn't 
have the capabilities of servicing the type of requests required of the 
uCDN.  Therefore, I propose we use the "capabilities with footprint" 
restrictions.  Either the CDN offers HTTP Redirection or it doesn't.  
The CDN footprint coverage is irrelevant if it is not capable of 
servicing the request.  In fact, many CDN will offer global coverage; 
therefore, capabilities becomes more relevant.  The document proposes 
the following capabilities:

     Delivery Protocol: HTTP, RTMP
     Acquisition Protocol: undefined
     Redirection Mode: DNS or HTTP
     CDNI Logging
     CDNI Metadata

Again, I think we will need to define a BOOLEAN capability set where all 
criteria are met with the AND function:

     Capability (Delivery=HTTP & Acquisition=HTTP & Redirection=HTTP, ...)
         Footprint (as defined above)
             ...

     Capability (Delivery=HTTP & Acquisition=HTTP & Redirection=DNS, ...)
         Footprint (as defined above)
             ...

Scott

On 7/18/13 11:01 AM, Jan Seedorf wrote:
> .