Subject: Re: [CDNi] New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-04

From: Scott Wainner <[email-masked]>
Date: Mon, 29 Apr 2013 11:49:39 -0400

| 1. Introduction and scope

| o The uCDN has received footprint and/or capability advertisements 
from a set of dCDNs.  Footprint advertisement and capability 
advertisement need not use the same underlying protocol.

I think we want to use the same protocol in order to avoid having 
another layer of referencing between a footprint associated with a 
capability.  I think we concluded that capability would be fairly static 
(e.g. HTTP) and the footprint is more likely to change. They are 
intrinsically coupled even if they are coupled implicitly.

| 2. CDNI FCI in existing CDNI Documents

| In the following section, the existing descriptions of the CDNI FCI 
interface in existing documents will be examined.  After this, the 
apparent common understanding of what this interface is intended to 
offer and accomplished will be carved out.

Descriptions of the CDNI FCI interface are highlighted in the CDNI 
Problem Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft 
requirements [I-D. ietf-cdni-requirements], and the CDNI framework draft 
[I-D ietf-cdni-framework].  An assessment of these descriptions is 
highlighted in the subsequent sections where the ambiguity associated 
with footprint and capabilities is highlighted.  The objective of this 
document is to clarify the meaning of footprint and capability and 
define the semantics and method for which these attributes are exchanged 
between two cooperating CDN's.
Untitled
| 3.1

  ... I would replace this whole section with a motivation for 
advertising limited coverage.

CDN's are built to minimize the cost of transport and optimize the 
performance of content delivery across that transport.

A dCDN operator may elect to advertise only the footprint for which the 
CDN is optimized.  While a dCDN might feasibly 'reach' a much larger 
footprint, the operator of the dCDN has elected to narrow the scope of 
footprint to insure that the CDN is only used for media delivery when 
clients are topologically or geographically close.

A uCDN may have global coverage enabling media delivery anywhere on the 
Internet; however, the uCDN may recognize that a specific dCDN has been 
optimized for media delivery in a specific topological footprint or a 
specific geographic region.

The quality of 'coverage' and 'reach' may be somewhat subjective. It is 
incumbent upon the uCDN to assess the relative quality of a dCDN; 
therefore, a dCDN should advertise a footprint that is contextually 
consistent with the advertisements of any other dCDN.

| 5. Towards Semantics for Footprint Advertisement

Two types of footprint may be advertised - topological and 
geographical.  A topological advertisement describes the dCDN's 
footprint relative to it's connectivity to the Internet using the BGP 
ASN attributes.  A geographical advertisement describes the dCDN's 
footprint relative to its coverage of a define location.

We might consider two models:

a. Topological Footprint (ASN) scoped by a geographical boundary (think 
of a global ASN where CDN coverage is limited to a particular continent)

     ASN <#>: FR, GE, UK, BE, ...

b. Geographical Footprint scoped by a set of topological boundaries 
(think of a continent where CDN coverage includes a set of ASN)

     US: ASN <#1>, ASN <#2>, ...

If the FCI is intended to provide the temporary state of the negotiated 
contract, either of the above could change over time. A dCDN that covers 
an ASN (by contract) could be expanded to include new countries.  
Likewise, a dCDN that covers a region (by contract) could be expanded to 
include new ASN.

Should the FCI support one or the other of the above models?

| 6. Towards Semantics for Capabilities Advertisement

My experience has highlighted the fact that most of the base 
capabilities must be configured (according to a negotiated contract) to 
facilitate redirection.  What seems relevant to me is where the 
footprint of a given capability changes.  Let's say uCDN has negotiated 
with dCDN to delivery both HTTP and RTMP.  At the time of service 
initialization, the RTMP footprint is smaller than the HTTP footprint; 
therefore, the capability should be advertised and scoped according to a 
footprint.  The default case might be that HTTP and RTMP are configured 
(no capability advertisement required), but that assumes both 
capabilities have global footprint.  Not sure that is always the case.

That is why I'm inclined to include a capability update which is scoped 
by a footprint.

| 7. Open Issues and Questions

| o What is the service model of this interface:...

I'm inclined to say the dCDN advertises its capability and footprint to 
the uCDN and periodically refreshes that advertisement.

| o In addition to "reachability" types of footprint, ...

Not clear that a dCDN will want to advertise resource availability ... 
just service availability.

| o Does a footprint need to explicitly include the "transitive" ...

I would think that the transitive dCDN MAY aggregate and represent a 
concatenated footprint.  Alternatively, the dCDN MAY advertise a subset 
of footprint to conform to a contract between the uCDN and the 
transitive CDN.

| o How exactly can a give dCDN derive its footprint?

I would expect this to be configured.  A dCDN might have a large 
footprint, but only want to advertise to a uCDN a portion of its 
footprint in accordance to a contract.

| o Should the footprint/capabilities advertisement interface only ...

I think the capability advertisement should be mandatory (e.g. HTTP | 
RTMP | RTSP) and it should conform to the contract.  It SHOULD be scoped 
by geography and/or topology where the absence of both footprint means 
global coverage.

On 2/26/13 5:27 AM, Jan Seedorf wrote:
> Dear all,
>
> We have submitted a new version of the footprint/capabilities semantics draft. We revised in particular the sections on what a footprint and capabilities should actually look like, so that the document now reflects the latest agreements in the design team. Thanks to Kevin and Ray for their help with the revision.
>
> Small note: we submitted yesterday the -03 version and shortly after the -04 version, which only fixed minor things in the author's affiliations compared to the -03 version. Just for people who were wondering how we got from -02 to -04.
>
> If you are interested in this, please join the phone call this afternoon. We also intend to update the WG during the CDNI sessions at the upcoming IETF-86 in Orlando.
>
>   - Jan
>
> -----Original Message-----
> From:[email-masked]  [mailto:[email-masked]]
> Sent: Monday, February 25, 2013 5:13 PM
> To: Jan Seedorf
> Cc:[email-masked];[email-masked];[email-masked];[email-masked]
> Subject: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-04.txt
>
>
> A new version of I-D, draft-spp-cdni-rr-foot-cap-semantics-04.txt
> has been successfully submitted by Jan Seedorf and posted to the
> IETF repository.
>
> Filename:	 draft-spp-cdni-rr-foot-cap-semantics
> Revision:	 04
> Title:		 CDNI Request Routing: Footprint and Capabilities Semantics
> Creation date:	 2013-02-25
> Group:		 Individual Submission
> Number of pages: 22
> URL:http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-04.txt
> Status:http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot-cap-semantics
> Htmlized:http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-04
> Diff:http://www.ietf.org/rfcdiff?url2=draft-spp-cdni-rr-foot-cap-semantics-04
>
> 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 Secretariat
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> .
>