Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

From: stefano previdi <[email-masked]>
Date: Thu, 8 Mar 2012 22:23:21 +0100

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
> Date: March 8, 2012 8:45:53 PM GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> 
> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
> 
> Filename:	 draft-previdi-cdni-footprint-advertisement
> Revision:	 01
> Title:		 CDNI Footprint Advertisement
> Creation date:	 2012-03-08
> WG ID:		 Individual Submission
> Number of pages: 27
> 
> Abstract:
>   This document describes the use of BGP for Content Delivery Networks
>   (CDNs) in order to advertise information about footprint and
>   connectivity to footprint in the context of CDNI.
> 
> 
> 
> This draft is for the CDNI Working Group.
> 
> Thanks.
> s.
> 
> The IETF Secretariat
>

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 22:17:56 +0000

Hi,

The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".

I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the correct meaning is.

Cheers,

g-

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of stefano previdi [[email-masked]]
Sent: 08 March 2012 21:23
To: [email-masked]
Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt

> This draft is for the CDNI Working Group.

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

---

From: Ina Minei <[email-masked]>
Date: Thu, 8 Mar 2012 14:42:46 -0800

Stefano, 

A few questions regarding the new section on capabilities advertisements:
1. Can you list some example capabilities that you are thinking about?
2. Who/how is the mapping made between the capabilities and the communities that represent them and how is this maintained consistent across the mesh? (which is under different admin domains)
3. Can capabilities really be expressed as a community or is a more flexible encoding needed? (I guess I am wondering what you mean by capabilities)
3. The advertisement is for a prefix in the CDN footprint - this implies that when reachability changes for that footprint, capabilities are readvertised, though nothing changes for the CDN itself. This is probably not ideal. Was wondering if you can explain a bit that choice, and if instead the cdn id can be used. 

Thank you, 

Ina

---

From: Jan Seedorf <[email-masked]>
Date: Fri, 9 Mar 2012 08:32:24 +0000

Grant,

I am not speaking for draft-previdi-cdni-footprint-advertisement (since I am not a co-author of that draft), but in general, we are having a broader discussion on what we (the CDNI WG) mean by capabilities, see

http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00

 - Jan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, March 08, 2012 11:18 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-
> footprint-advertisement-01.txt
> 
> 
> Hi,
> 
> The document talks about "Capability Advertisements" and the proposal to
> use MP-BGP messages to advertise/exchange CDN capabilities. However,
> the document does not explicitly define what is ment by "CDN Capability".
> 
> I understand "CDN Capability" to mean things like delivery technology (for
> example RTMP or HTTP etc.) or perhaps a specific form of content
> authorisation etc. Can you confirm I am correct in assuming this or if not
> clarify what the correct meaning is.
> 
> Cheers,
> 
> g-
> 
> 
> 
> > A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has
> been successfully submitted by Stefano Previdi and posted to the IETF
> repository.
> >

---

From: stefano previdi <[email-masked]>
Date: Fri, 9 Mar 2012 11:29:57 +0100

On Mar 9, 2012, at 7:02 AM, Stef van der Ziel wrote:

> Hi,
> 
> I would not recommend to use BGP to share CDN information, that would effectively lock a CDN into the network layer

not really. 

The fact that you use BGP as a tool for propagating footprint 
information doesn't make your CDN a layer3 model.

As described in the proposal, we have a new AF for the purpose 
of CDNI.

s.

> while CDNs need to run on top of multiple networks, abstracted from the network. CDN interconnectivity should be API based. You can't assume that a CDN would use BGP anyway.
> 
> Best, Stef
> 
> 
> 
> On 8 mrt. 2012, at 23:42, Ina Minei <[email-masked]> wrote:
> 
>> Stefano, 
>>

---

From: stefano previdi <[email-masked]>
Date: Fri, 9 Mar 2012 11:39:30 +0100

Hi Ina,

thanks for your comments... some answers below.

> 2. Who/how is the mapping made between the capabilities and the communities that represent them and how is this maintained consistent across the mesh? (which is under different admin domains)

well, at this stage of the proposal, I think about communities as 
an encoding/mapping mechanism for capabilities. When the WG will 
have figured out what capabilities needs to be advertised, we have 
good method for advertising them (std vs ext vs wide).

> 3. Can capabilities really be expressed as a community or is a more flexible encoding needed? (I guess I am wondering what you mean by capabilities)

nothing prevents us from defining a more ad-hoc attribute if 
necessary. We may probably go that path if more structured encoding 
is required.

> 3. The advertisement is for a prefix in the CDN footprint - this implies that when reachability changes for that footprint, capabilities are readvertised,

To my (probably perfectible) knowledge, the capability is associated 
to a CDN, not a prefix. However, nothing prevents the use of 
capability communities to FP element.

When the capability is related to the CDN, you only have to 
advertise the set of capability communities into _one_ prefix 
that is owned by the CDN. Any change on capabilities will not 
trigger any FP element re-advertisement.

s.

> though nothing changes for the CDN itself. This is probably not ideal. Was wondering if you can explain a bit that choice, and if instead the cdn id can be used. 
> 
> Thank you, 
> 
> Ina 
> 
>

---

From: stefano previdi <[email-masked]>
Date: Fri, 9 Mar 2012 11:43:46 +0100

Hi Grant,

> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by…

indeed... and it is somehow intended...

As JanS pointed out, there's another draft that should explicit 
the semantics of FP/Capabilities. In this proposal we define the 
mechanism through which the capability information can be 
exchanged.

Obviously, at some point, we'll have to synchronize.

> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assumi…

My understanding goes in the same direction, so far.

s.

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 11:50:59 +0000

Thanks, understood.

Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?

It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.

g-

-----Original Message-----
From: stefano previdi [mailto:[email-masked]] 
Sent: 09 March 2012 10:44
To: Watson,G,Grant,DMK5 R
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

Hi Grant,

As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we define the mechanism through which the capability information can be exchanged.

s.

>> Subject: New Version Notification for 
>> draft-previdi-cdni-footprint-advertisement-01.txt

---

From: Jan Seedorf <[email-masked]>
Date: Fri, 9 Mar 2012 12:56:58 +0000

> Then my general feedback would be - I think working out what capability
> information needs to be shared between the CDNs would ideally be worked
> though prior to deciding the right way to do it.
This is exactly what the CDNI WG decided at IEF-82 and the rationale for the semantics draft (draft-spp-cdni-rr-foot-cap-semantics). First, let's understand what we want/need, then let's decide on a protocol. We assume some interesting discussions on "working out what capability information needs to be shared between the CDNs" in Paris, we tried to provide input to this discussion in the semantics draft.

 - Jan

> Sent: Friday, March 09, 2012 12:51 PM
> Then my general feedback would be - I think working out what capability
> information needs to be shared between the CDNs would ideally be worked
> though prior to deciding the right way to do it. BGP doesn't feel like an
> obvious choice for exchanging the kind of CDN Capability information I'd
> envisage being passed between CDN. Has a discussion taken place as to why
> BGP over other methods? (e.g. API/metadata) There are drafts discussing
> metadata right now that propose ways of describing the capability
> requirements between CDN (e.g. "deliver this content using RMTP" etc.),
> why would we not also exchange capabilities over the same interface for
> example?
> 
> It's easier to understand why it may be considered that BGP should/could be
> used for the exchange of network footprint information but less so for CDN
> Capabilities, IMHO. In some cases CDN may not want or need to implement
> footprint advertisement entirely (for example in a simple bi-lateral
> relationship the CDN operators could easily elect to exchange footprint
> information out-of-band), in this case they presumably wouldn't want to be
> dependent on BGP to exchange capability information.
> 
> g-
> 
> 
> As JanS pointed out, there's another draft that should explicit the semantics
> of FP/Capabilities. In this proposal we define the mechanism through which
> the capability information can be exchanged.
> 
> >> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt
> has been successfully submitted by Stefano Previdi and posted to the IETF
> repository.
> >>

---

From: HeXiaoyan <[email-masked]>
Date: Mon, 12 Mar 2012 10:32:49 +0800

Hi all,
There is a draft from us addressing the same topic, I encourage the working
group to look at it and take it also as an input
for our discussion in Paris.  
http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/

Thanks. 

Best Regards
Xiaoyan(Susan) He

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jan
> Seedorf
> Sent: Friday, March 09, 2012 8:57 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [CDNi] New Version Notification for
> This is exactly what the CDNI WG decided at IEF-82 and the rationale for
the
> semantics draft (draft-spp-cdni-rr-foot-cap-semantics). First, let's
understand
> what we want/need, then let's decide on a protocol. We assume some
> interesting discussions on "working out what capability information needs
to be
> shared between the CDNs" in Paris, we tried to provide input to this
discussion
> in the semantics draft.
> > Subject: Re: [CDNi] New Version Notification for
draft-previdi-cdni-footprint-
> > advertisement-01.txt
> > Subject: Re: [CDNi] New Version Notification for
draft-previdi-cdni-footprint-
> > advertisement-01.txt
> > > Subject: [CDNi] Fwd: New Version Notification for
draft-previdi-cdni-
> > >> A new version of I-D,

---

From: HeXiaoyan <[email-masked]>
Date: Mon, 12 Mar 2012 10:47:36 +0800

> though prior to deciding the right way to do it.
Agree.  And besides the semantics draft Jan mentioned.  Section 1-5 of our
draft http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
discussed the criteria on determining the capability information needs to be
shared between CDNs and semantics of them. Please experts who are interested
in this topic have a look on it.

>Has a discussion taken place as to why BGP over other  methods? (e.g.
API/metadata).
I have the same concern, and asked a similar question last time in Taipei
meeting, but for the time limit, we have not find chance discussed that
sufficiently  eventually 
I think.  

Best Regards
Xiaoyan(Susan) He

> Sent: Friday, March 09, 2012 7:51 PM
obvious
> choice for exchanging the kind of CDN Capability information I'd envisage
being
> passed between CDN. Has a discussion taken place as to why BGP over other
> methods? (e.g. API/metadata) There are drafts discussing metadata right
now
> that propose ways of describing the capability requirements between CDN
(e.g.
> "deliver this content using RMTP" etc.), why would we not also exchange
> capabilities over the same interface for example?
> 
relationship
> the CDN operators could easily elect to exchange footprint information
> out-of-band), in this case they presumably wouldn't want to be dependent
on
> BGP to exchange capability information.
> 
> g-
> 
> 
> use MP-BGP messages to advertise/exchange CDN capabilities. However, the
> document does not explicitly define what is ment by "CDN Capability".
> 
> 
> As JanS pointed out, there's another draft that should explicit the
semantics of
> FP/Capabilities. In this proposal we define the mechanism through which
the
> capability information can be exchanged.
> 
clarify
> what the correct meaning is.
> 
> 
has

---

From: Scott Wainner <[email-masked]>
Date: Mon, 12 Mar 2012 10:28:10 -0400

I too am struggling with how 'capabilities' can be advertised 
effectively in BGP.  I'm inclined to delineate the 'footprint' from the 
'capabilities'.

Perhaps one approach is to indicate in the 'capabilities' the various 
METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, 
the options for METHODS of determining 'footprint' might be BGP AFI or 
BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it 
has the capability of advertising (or allowing discovery of) different 
methods of 'footprint' advertisements and those methods might be weighted.

I think the dCDN capabilities (e.g. delivery methods, security methods, 
etc.) will become far more complex than can be aggregated into a 
representative set of BGP communities.  Nevertheless, I do think BGP 
communities is a viable method of advertising a 'footprint' ... one that 
is well understood by the network operators.

Scott Wainner

On 3/9/12 6:50 AM, [email-masked] wrote:
>
> Thanks, understood.
>
> Then my general feedback would be - I think working out what 
> capability information needs to be shared between the CDNs would 
> ideally be worked though prior to deciding the right way to do it. BGP 
> doesn't feel like an obvious choice for exchanging the kind of CDN 
> Capability information I'd envisage being passed between CDN. Has a 
> discussion taken place as to why BGP over other methods? (e.g. 
> API/metadata) There are drafts discussing metadata right now that 
> propose ways of describing the capability requirements between CDN 
> (e.g. "deliver this content using RMTP" etc.), why would we not also 
> exchange capabilities over the same interface for example?
>
> It's easier to understand why it may be considered that BGP 
> should/could be used for the exchange of network footprint information 
> but less so for CDN Capabilities, IMHO. In some cases CDN may not want 
> or need to implement footprint advertisement entirely (for example in 
> a simple bi-lateral relationship the CDN operators could easily elect 
> to exchange footprint information out-of-band), in this case they 
> presumably wouldn't want to be dependent on BGP to exchange capability 
> information.
>
> g-
>
>
> > The document talks about "Capability Advertisements" and the 
> proposal to use MP-BGP messages to advertise/exchange CDN 
> capabilities. However, the document does not explicitly define what is 
> ment by "CDN Capability".
>
>
> semantics of FP/Capabilities. In this proposal we define the mechanism 
> through which the capability information can be exchanged.
>
> > I understand "CDN Capability" to mean things like delivery 
> technology (for example RTMP or HTTP etc.) or perhaps a specific form 
> of content authorisation etc. Can you confirm I am correct in assuming 
> this or if not clarify what the correct meaning is.
>
>
> draft-previdi-cdni-footprint-advertisement-01.txt has been 
> successfully submitted by Stefano Previdi and posted to the IETF 
> repository.
> >>

---

From: Stef van der Ziel <[email-masked]>
Date: Wed, 14 Mar 2012 11:07:23 +0100

Hi,

I would not recommend using BGP for CDN capabilities sharing.
BGP is a networking layer protocol. CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol. CDNs should not be locked into networks or become dependent on networking layered protocols. CDN interconnection should be done via APIs.

Kind regards, 

Stef van der Ziel

On 12 mrt. 2012, at 15:28, Scott Wainner wrote:

> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'.
> 
> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
> 
> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
> 
> Scott Wainner
>

---

From: stefano previdi <[email-masked]>
Date: Wed, 14 Mar 2012 11:33:24 +0100

On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:

> BGP is a networking layer protocol.

not in the way we propose to use it in the CDNI context.

> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.

well, BGP is to be intended as MP-BGP with a scope of advertising 
footprint and capability information. In that respect the semantic 
is pretty clear. The fact that BGP is also used in other contexts 
such as network layer routing, MPLS-VPN, multicast, etc. doesn't 
preclude the use of the same technology into another context.

> CDNs should not be locked into networks or become dependent on networking layered protocols.

absolutely agree. As you can see from the proposal, we leverage 
what's available in the BGP databases as for footprint information. 
However, also described in the proposal, we allow complete freedom 
to any CDNI MP-BGP player to define its own policy and elements to 
advertise.

s.

> CDN interconnection should be done via APIs.
> 
> Kind regards, 
> 
> Stef van der Ziel
> 
>

---

From: Stef van der Ziel <[email-masked]>
Date: Wed, 14 Mar 2012 11:38:08 +0100

Hi,

It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended. 
In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios. 
Better use proper APIs! 

Best, Stef

---

From: stefano previdi <[email-masked]>
Date: Wed, 14 Mar 2012 12:25:51 +0100

> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended. 

well, I don't think so. We use the same tool... but differently.

> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios. 

yes, but at the end of the day, the CDN relies on internet routing so 
at some point there's a relationship between the CDN and the network 
layer.

In our proposal we just leverage the reachability information you can 
get from your local SP/ISP so to figure out footprint information.

Capabilities, I agree with you, is a different story but since we 
don't know yet what is a capability (and which format it should/must/may 
have) it's difficult to come with a proper scheme. Having said that, BGP 
(as a tool) has all feature you need so to propagate both FP and caps.

s.

---

From: Stef van der Ziel <[email-masked]>
Date: Wed, 14 Mar 2012 13:29:29 +0100

There are too many scenarios where a CDN does not rely on Internet routing. 
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology. 
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef

---

From: stefano previdi <[email-masked]>
Date: Wed, 14 Mar 2012 13:47:30 +0100

> Think of multiple CDNs within a private network, that have to interoperate.

still you need to route your packets at the end of the day and 
it is likely to be done through a BGP entry.

> A CDN may also have a different footprint than the network topology. 

absolutely. that's why we propose to use MP-BGP for explicit FP 
advertisement.

> Proper APIs offer the same function, but with all the freedom that CDNs will need.

"Proper API" may also fit (CDNI)MP-BGP definition...

s.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Mar 2012 14:39:07 +0100

Hello Stef,

(as an individual)

> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended. 

I am not sure such sweeping statement are really helping the discussion much. Probably no more than saying "considering ALTO for CDN footprint advertisement is bad because it is trying to lock CDNs into Peer-to-peer protocols".

I believe the plan of record for the group is :
	* identify the functional requirements of a cdn footprint advertisement (including notably some potentially challenging aspects of scaling and dynamic updates)
	* document various solutions to support these requirements and assess their applicability
	* select one (or potentially more than one) solution based on applicability

> In most CDNs we deployed, BGP doesn't play any role.

So I think you are saying that regardless of its relative applicability you favor a particular solution because that is what you are familiar with. This is a useful datapoint but not necessarily a killer argument for people who extensively use other base technologies.

> Not even in federated scenarios. 
> Better use proper APIs! 

I think there is agreement on that.
The question remains on what is a proper APIs.

Documenting the "proper API" you have in mind (like is being done for other approaches) would be helpful in this exercise.

Thanks

Francois

---

From: Stef van der Ziel <[email-masked]>
Date: Wed, 14 Mar 2012 14:45:34 +0100

Hi Francois,

I can understand that from a networking / routing gear vendor perspective, Cisco looks at BGP (etc) for CDN functions.
However CDNs aren't necessarily tied into the networking architecture, instead they are more and more abstracted from the network layer.
I don't favor a particular solution, I want to prevent that a standard locks in CDN operators into specific environments. That would be a pitfall for CDN operators.
Using APIs instead, there is no need for a debate and there is no risk for the actual CDN operator.

I would love to share our ideas around CDN capabilities exchange. 

Best, Stef

---

From: Scott Wainner <[email-masked]>
Date: Wed, 14 Mar 2012 09:47:52 -0400

A 'proper API' whether defined by CDN-I or not requires information 
to be conveyed.  That is the fundamental question in my mind.  What 
information needs to be conveyed THROUGH that API / interface?

     We've clearly identified that the 'footprint' of the CDN and the 
network are not congruent.  However, CDN will need to send packets 
through the network to reach the client.  The best proximity path 
between any given delivery node and the client is defined by the network 
topology.  I can have two devices sitting side-by-side while they are 
topologically connected in vastly different manners.  We will certainly 
need some NETWORK INFORMATION conveyed through the API to discern the 
proximity of the client to any given delivery node. See ALTO.

     I think the focus is on what INFORMATION is needed.  Then we can 
focus on the right conduit to convey that information.  I suspect the 
issue is delineating between different types of "capabilities".  There 
are CDN capabilities (ability to deliver content using HSS or HLS) and 
there are network capabilities (ability to reach a given prefix and cost 
associated with that path).  Presumably, the CDN will collect BOTH sets 
of capabilities via various API / CDN-I and make the 'best' choice of 
delivery node.

     What information do we need from the network to make the best 
content routing decision in the uCDN?

     draft-he-cdni-cap-info-advertising-01
     draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / 
footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to 
assimilate and make a congruent assessment.  We don't want to assign a 
delivery node that is not capable of delivering the content even though 
it is closer.  Conversely, we may want to assign a delivery node that is 
topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
> >> It still looks like you're trying to lock CDNs into networking 
> layer protocols and use protocols for which they were not intended.
> >
> >
> >>>> CDNs can and should run independently from the network, or span 
> multiple networks. Or run within a part of a network, where BGP is not 
> the right protocol.
> >>>
> >>>
> effectively in BGP.  I'm inclined to delineate the 'footprint' from 
> the 'capabilities'.
> >>>>>
> >>>>> Perhaps one approach is to indicate in the 'capabilities' the 
> various METHODS for assessing the 'footprint'.  In the 'capabilities' 
> exchange, the options for METHODS of determining 'footprint' might be 
> BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might 
> indicate it has the capability of advertising (or allowing discovery 
> of) different methods of 'footprint' advertisements and those methods 
> might be weighted.
> >>>>>
> >>>>> I think the dCDN capabilities (e.g. delivery methods, security 
> methods, etc.) will become far more complex than can be aggregated 
> into a representative set of BGP communities.  Nevertheless, I do 
> think BGP communities is a viable method of advertising a 'footprint' 
> ... one that is well understood by the network operators.
> >>>>>
> >>>>> Scott Wainner
> >>>>>
> the semantics of FP/Capabilities. In this proposal we           define 
> the mechanism through which the capability information can be exchanged.
> >>>>>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Mar 2012 15:05:38 +0100

Hi again Stef,

On 14 Mar 2012, at 14:45, Stef van der Ziel wrote:

> Hi Francois,
> 
> I can understand that from a networking / routing gear vendor perspective, Cisco looks at BGP (etc)

I don't speak for Cisco in the IETF. I just speak for myself. 
For the record Cisco is also a CDN gear vendor.

> for CDN functions.

This is not for an existing CDN function, this is for a specific CDN interconnection function which is "CDN footprint advertisement". 

> However CDNs aren't necessarily tied into the networking architecture, instead they are more and more abstracted from the network layer.

As I said: I am not sure such sweeping statement are really helping the discussion at hand much.

> Using APIs instead, there is no need for a debate

Hmm, so you don't favor a particular solution but you recommend that we don't consider some solutions on the compelling argument that not considering them would avoid a debate. I guess I am not convinced yet.

By the way, I am not saying that the decision for a BGP-based approach should be made now. What I am saying is that I personally won't exclude a BGP-based approach because of a sweeping statement. I recommend we continue document the information exchange requirements and several candidate approaches in order to make an informed decision.

> and there is no risk for the actual CDN operator.

I don't understand the basis for that statement.

> I would love to share our ideas around CDN capabilities exchange. 

The most effective way in the IETF to share ideas on a proposed approach is to document it in an Internet-Draft. I suggest you consider that, or join one of the existing efforts in documenting an approach.

Cheers

Francois

---

From: Stef van der Ziel <[email-masked]>
Date: Wed, 14 Mar 2012 15:41:22 +0100

Hi,

To get more clarity before talking about the protocols:

- The definition of footprint, is that network PoP footprint, or CDN edge PoP footprint? Topology or geography? What granularity: per country, per ISP, per region, and what is a region? A metro ring? A mobile cell tower?

- What about edge capacity footprint? You can have an edge server or a huge PoP. A CDN could claim presence in a specific region, but that doesn't say anything about the installed or actual capacity in terms of storage and bandwidth. Global CDNs claim to have 'unlimited' bandwidth but if in reality an edge cache is connected to just 100Mbps, is that edge the right choice?

- What about edge capabilities footprint? A PoP edge can be a basic cache edge appliance or a full blown unified protocol delivery node. We all know those global CDNs claiming to have great presence everywhere, but when you look deeper, it turns out that their edge servers don't support RTMP and are basic http caches.

- What about CDN management capabilities exchange? Capabilities exchange is about which ingest protocols are supported, which content distribution controls are supported (delete, distribute, push, flush...), which live relaying protocols are supported (RTMP, RTSP, push, pull, remote origin...), which features the request router supports (output formats, redirect protocols...), which geo blocking features, and file locking, reporting, log formats, does the CDN only support passive caching or does it support active dynamic controlled push of assets? Does the CDN rely on passive DNS geo load balancing or can it do active per request redirection? Which APIs are available, where can you connect, how to authenticate, which API specs do they comply to, which API features are supported? 

- What about footprint and capabilities transparency? Is one CDN allowed to pass through the information from another CDN to a third party CDN or a content publisher? I know that most CDNs act as a black box. I also know that a lot of premium broadcasters will demand as a mandatory feature that interconnected / federated CDNs will be completely transparent about footprint, capacity, capabilities, SLA levels, even if there is a chain of a dozen interconnected CDNs involved. 

- What about allowing third party request routers to directly redirect to an edge node? I know that some vendors have some ideas around it, but IMHO a CDN operator should always have full autonomous control over their infrastructure, so at least we should share a restriction that third parties always must handle requests through our request routers  (in a nice interconnected way).

- What about access security management? Some CDNs have very poor implementations for anti-deep linking. When they turn it on, it kills their performance by half, or they create tokens based on the end users IPv4 IP address, destroying their ability to connect in IPv4 / IPv6 dual mode to various CDN components. Other CDNs do proper full lock-down with private secure tokens between the delivery nodes and the request routers, and with private secure tokens between the request routers and each content owners portal. In interconnected scenarios, multiple CDNs need to exchange secure tokens on a per account or per CDN basis. How are these tokens automatically exchanged?

I think the above is just the tip of the iceberg. It is a quite extensive list that should be shared between 2 CDNs before they can interact... and I don't think BGP was intended to be used for these purposes, not that it is a practical protocol for it. 

Best, Stef

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Mar 2012 16:25:23 +0100

Now we're talking ^).

See below:

> - The definition of footprint, is that network PoP footprint, or CDN edge PoP footprint? Topology or geography? What granularity: per country, per ISP, per region, and what is a region? A metro rin…

I'd say any of the above is needed. Prefixes of variable length is one possible way to support any of these granularity in CDN footprint advertisement with flexibility between amount of information and fine-grain. This happen to be very basic operation in BGP. It could also be supported in other approaches of course.

> - What about edge capacity footprint? You can have an edge server or a huge PoP. A CDN could claim presence in a specific region, but that doesn't say anything about the installed or actual capacit…

I believe this group is under the assumption that CDNs will remain opaque, so will not advertise stuff like edge server capacity.

> - What about edge capabilities footprint? A PoP edge can be a basic cache edge appliance or a full blown unified protocol delivery node. We all know those global CDNs claiming to have great presenc…

Yes, advertisement of capabilities such as delivery protocols is required. Tagging something indicating that sort of capabilities along with a given Prefix in a CDN footprint advertisement is one possible way to do that. This happen to be very basic operation in BGP ("communities"). It could also be supported in other approaches of course.

> - What about CDN management capabilities exchange? Capabilities exchange is about which ingest protocols are supported, which content distribution controls are supported (delete, distribute, push,…

This question indeed needs more thinking. As phrased this probably creates a challenging problem for any approach.
At this stage, I'd observe that:
	* it may be possible to reduce the complexity by mandating a set of base capabilities (geoblocking, logging, purge, ...) supported by all CDNs participating in a CDNI mesh
	* some aspects may be helped/handled by other interfaces (for example, the CDNI metadata interface allows the uCDN to indicate what are the acquisition methods that can be used to access a given content).

I'd need to better understand what is the real set of requirements here to understand what approach is well or not so well suited.

> - What about footprint and capabilities transparency? Is one CDN allowed to pass through the information from another CDN to a third party CDN or a content publisher? I know that most CDNs act as a…

So you'd need configurable knobs to control what gets re-advertised as is, what gets re-advertised with some manipulation, what gets hidden, what gets aggregated .... This happens to be basic operation in BGP. It could also be supported in other approaches of course. But I'd point out that this one aspect where a BGP-based approach has attractiveness because it actually comprises both an interface/API to exchange information (the BGP protocol) and effectively a very flexible rule/policy engine (the BGP engine) while other candidate approaches mentioned so far focus on the interface/API and would have to re-invent the rule/policy engine required in meshed scenarios (ie to determine what needs to get readveristed to who with what modification).

> 
> - What about allowing third party request routers to directly redirect to an edge node? I know that some vendors have some ideas around it, but IMHO a CDN operator should always have full autonomous control over their infrastructure,

I believe the group is also operating under that assumption. But I see this as mostly orthogonal to the footprint/capability advertisement approach discussion.

> so at least we should share a restriction that third parties always must handle requests through our request routers  (in a nice interconnected way).
> 

Not sure this pertain to the footprint/capability advertisement approach discussion.

> 
> I think the above is just the tip of the iceberg.

Yes, there are other considerations. Two major ones that have come up before:
	* the requirement to handle large footprints in very scalable way while at the same time allowing fine-grain advertisement (first point above) 
	* the requirement to handle dynamic updates of footprint/capabilities.
This happens to be common operation for BGP (particularly when augmented with the hierarchical model documented in previdi-cdni-footprint-advertisement. It could also be supported in other approaches of course.

> It is a quite extensive list that should be shared between 2 CDNs before they can interact... and I don't think BGP was intended to be used for these purposes,

it was certainly not intended for this purpose initially (nor was it intended for IPv6 routing initially, nor for MPLS L3 VPNs, nor for the many applications it is now used for ....).

> not that it is a practical protocol for it.

That is the bit I am still missing.

Cheers

Francois

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Mar 2012 13:41:02 -0400

I agree with Scott that the focus must be on what information is needed - and in particular, what information is needed by the uCDN to make a selection of a dCDN. There may be information that is easy to express syntactically, or easy to derive from the network layer, but which does not actually provide the uCDN with the tools it needs to make a decision. It is also the case that dCDNs could expose information that will let uCDNs make a far more granular decision than just picking a dCDN. The discussion of whether we need geography or topography or reachability or whatever is contingent on what we imagine the logic will be that a uCDN uses to select a dCDN.

One of the reasons why I worked with Jan and Stefano on our new draft about footprint and capability semantics was that it didn't seem to me at the last CDNi session that people had a common picture yet of what a uCDN would need to make a decision. In the draft, we consider a couple of alternatives definitions of "footprint" that might be useful to the uCDN, and also a couple of alternatives that might not be so useful. While I agree at a high level that dCDNs need some way to inform a uCDN of their footprint, we need to be careful when we think in terms of coverage or reachability, because a dCDN might not even be the best judge of how reachable its resources are to endpoints outside of its intended scope. We also need to decide how deeply we want a uCDN to understand a dCDNs resources - effectively, we could have very low-level approaches where uCDNs execute the entire request-routing algorithm down to selecting the particular cache, or high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN. Once we get some agreement about these points, deciding what type and what granularity of information dCDNs should advertise will be a lot easier.

Jon Peterson
NeuStar, Inc.

On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote:

    A 'proper API' whether defined by CDN-I or not requires information to be conveyed.  That is the fundamental question in my mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of the CDN and the network are not congruent.  However, CDN will need to send packets through the network to reach the client.  The best proximity path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side while they are topologically connected in vastly different manners.  We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is needed.  Then we can focus on the right conduit to convey that information.  I suspect the issue is delineating between different types of "capabilities".  There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to make the best content routing decision in the uCDN?

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

Best, Stef

On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>>>>> On 3/9/12 6:50 AM, [email-masked]<mailto:[email-masked]> wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Cc: [email-masked]<mailto:[email-masked]>
>>>>>> On Mar 8, 2012, at 11:17 PM, <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
>>>>>>> stefano previdi [[email-masked]<mailto:[email-masked]>]
>>>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>>>>> From: [email-masked]<mailto:[email-masked]>
>>>>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>>>>> Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
>>>>>>>>
>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

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

<ATT00001..txt>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 14 Mar 2012 14:58:33 -0400

Dear all,

I will echo that it is important to first understand the information is 
needed. In particular, I like the comment by Jon that "The discussion of 
whether we need geography or topography or reachability or whatever is 
contingent on what we imagine the logic will be that a uCDN uses to 
select a dCDN". We recently did a study in the context of formulating 
and solving a *single-hop* CDNi problem. We named the formulation 
content multihoming optimization problem. A draft of the paper is at: 
http://www-net.cs.yale.edu/publications/cm12.pdf, and we have not been 
able to turn it into an ID, but we will try after the IETF. The paper 
gives a simple design point -- the setting of the paper is in a limited 
setting of single hop -- on how a uCDN (content publisher) might 
formulate a problem, and what inputs are needed to solve the problem. 
You can safely skip the math on the solution part. Some of our 
measurements could be interesting for this group as well--some CDNs 
impose rate limits, some CDNs already use CDNi to delegate to other 
networks.

Richard

On 3/14/12 1:41 PM, Peterson, Jon wrote:
>
> I agree with Scott that the focus must be on what information is 
> needed - and in particular, what information is needed by the uCDN to 
> make a selection of a dCDN. There may be information that is easy to 
> express syntactically, or easy to derive from the network layer, but 
> which does not actually provide the uCDN with the tools it needs to 
> make a decision. It is also the case that dCDNs could expose 
> information that will let uCDNs make a far more granular decision than 
> just picking a dCDN. The discussion of whether we need geography or 
> topography or reachability or whatever is contingent on what we 
> imagine the logic will be that a uCDN uses to select a dCDN.
>
> One of the reasons why I worked with Jan and Stefano on our new draft 
> about footprint and capability semantics was that it didn't seem to me 
> at the last CDNi session that people had a common picture yet of what 
> a uCDN would need to make a decision. In the draft, we consider a 
> couple of alternatives definitions of "footprint" that might be useful 
> to the uCDN, and also a couple of alternatives that might not be so 
> useful. While I agree at a high level that dCDNs need some way to 
> inform a uCDN of their footprint, we need to be careful when we think 
> in terms of coverage or reachability, because a dCDN might not even be 
> the best judge of how reachable its resources are to endpoints outside 
> of its intended scope. We also need to decide how deeply we want a 
> uCDN to understand a dCDNs resources - effectively, we could have very 
> low-level approaches where uCDNs execute the entire request-routing 
> algorithm down to selecting the particular cache, or high-level 
> approaches where the uCDN has only a general sense of dCDN resources 
> and defers cache selection to the dCDN. Once we get some agreement 
> about these points, deciding what type and what granularity of 
> information dCDNs should advertise will be a lot easier.
>
> Jon Peterson
> NeuStar, Inc.
>
>>     A 'proper API' whether defined by CDN-I or not requires 
>> information to be conveyed.  That is the fundamental question in my 
>> mind.  What information needs to be conveyed THROUGH that API / 
>> interface?
>>
>> between any given delivery node and the client is defined by the 
>> network topology.  I can have two devices sitting side-by-side while 
>> they are topologically connected in vastly different manners.  We 
>> will certainly need some NETWORK INFORMATION conveyed through the API 
>> to discern the proximity of the client to any given delivery node. 
>> See ALTO.
>>
>> issue is delineating between different types of "capabilities".  
>> There are CDN capabilities (ability to deliver content using HSS or 
>> HLS) and there are network capabilities (ability to reach a given 
>> prefix and cost associated with that path).  Presumably, the CDN will 
>> collect BOTH sets of capabilities via various API / CDN-I and make 
>> the 'best' choice of delivery node.
>>
>> I see these as a disjoint set of information that the uCDN will need 
>> to assimilate and make a congruent assessment.  We don't want to 
>> assign a delivery node that is not capable of delivering the content 
>> even though it is closer.  Conversely, we may want to assign a 
>> delivery node that is topologically further away because of access costs.
>>
>> Scott
>>
>>> multiple networks. Or run within a part of a network, where BGP is 
>>> not the right protocol.
>>> >>>
>>> >>>
>>> various METHODS for assessing the 'footprint'.  In the 
>>> 'capabilities' exchange, the options for METHODS of determining 
>>> 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  
>>> Accordingly, a dCDN might indicate it has the capability of 
>>> advertising (or allowing discovery of) different methods of 
>>> 'footprint' advertisements and those methods might be weighted.
>>> >>>>>
>>> think BGP communities is a viable method of advertising a 
>>> 'footprint' ... one that is well understood by the network operators.
>>> >>>>>
>>> >>>>> Scott Wainner
>>> >>>>>
>>> ideally be worked though prior to deciding the right way to do it. 
>>> BGP doesn't feel like an obvious choice for exchanging the kind of 
>>> CDN Capability information I'd envisage being passed between CDN. 
>>> should/could be used for the exchange of network footprint 
>>> information but less so for CDN Capabilities, IMHO. In some cases 
>>> CDN may not want or need to implement footprint advertisement 
>>> entirely (for example in a simple bi-lateral relationship the CDN 
>>> operators could easily elect to exchange footprint information 
>>> out-of-band), in this case they presumably wouldn't want to be 
>>> capabilities. However, the document does not explicitly define what 
>>> is ment by "CDN Capability".
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> As JanS pointed out, there's another draft that should 
>>> explicit the semantics of FP/Capabilities. In this proposal 
>>> we           define the mechanism through which the capability 
>>> information can be exchanged.
>>> >>>>>>
>>> technology (for example RTMP or HTTP etc.) or perhaps a specific 
>>> form of content authorisation etc. Can you confirm I am correct in 
>>> assuming this or if not clarify what the           correct meaning is.
>>> >>>>>>
>>> >>>>>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Mar 2012 20:30:22 +0100

(as an individual)

On 14 Mar 2012, at 18:41, Peterson, Jon wrote:
> 
> We also need to decide how deeply we want a uCDN to understand a dCDNs resources - effectively, we could have very low-level approaches where uCDNs execute the entire request-routing algorithm down to selecting the particular cache, or high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN. Once we get some agreement about these points, deciding what type and what granularity of information dCDNs should advertise will be a lot easier.

I believe this has been discussed and decided by the working group:

From draft-ietf-cdni-requirements-02:
"
   GEN-4   [HIGH] The CDNI solution shall not require intra-CDN
           information to be exposed to other CDNs for effective and
           efficient delivery of the content.  Examples of intra-CDN
           information include surrogate topology, surrogate status,
           cached content, etc.
"

I personally support that decision to focus the current/initial CDNI work on "high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN". In the future, once high level approaches are working we can look into "very low-level approaches where the uCDNs execute the entire request-routing algorithm down to selecting the particular cache" (if dCDNs are willing to allow that).

Cheers

Francois

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Mar 2012 15:40:39 -0400

While I think I agree with you about the general strategy we should take, judging from the drafts submitted for this IETF and the discussion on the list, I would be less confident about saying there is working group consensus behind it. I think people are still all over the map on this. In part that's because there's a pretty slippery slope between the high-level and the low-level, and the words in the requirement GEN-4 that you site - words like "surrogate topology, surrogate status" - are not precise terms. When we start actually trying to define the semantics, be it in terms of geography, topology, reachability, cache enumeration, what have you, that's when we start to see what people are reading into this words. I think today people are still reading some pretty different things into them.

Jon Peterson
NeuStar, Inc.

On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote:

(as an individual)

"

Cheers

Francois

Jon Peterson
NeuStar, Inc.

Scott

Best, Stef

<ATT00001..txt>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Mar 2012 21:11:21 +0100

Hi Jon,

I agree there is some wiggle room about what exact information set a dCDN would provide to the uCDN which requires further discussion (ie pick a spot between a very-high-level approach and a high-enough-level approach). But I believe the requirement below, as well as the intent when it was discussed, clearly excludes low-level approaches where the upstream CDNs gets enough information to make the complete cache selection. I also believe there was consensus  that dCDNs did not want to provide visibility on their CDN resource location/status/load...
So to define this exact information set to be advertised by a dCDN, I think the following are reasonable guiding principles:
	* stick to information that is helpful to the uCDN for selecting the dCDN (and not the final cache)
	* do not expose dCDN caching resources 	

Francois

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 22 Mar 2012 09:44:13 -0700

Tracking requirements from CDNI Interface drafts. Based on the
discussion for draft-previdi-cdni-footprint-advertisement, I'd like to
confirm if there is any updates needed for the requirements. 

Is the GEN-4 requirement sufficiently clear?

           cached content, etc.

Terminology:

Surrogate: A device/function (often called a cache) that interacts

   with other elements of the CDN for the control and distribution of

   Content within the CDN and interacts with User Agents for the

   delivery of the Content.

So this is not the debate about high level vs. low level. Just want to
confirm the level of description is sufficient for the requirement? Or
need additional text for clarification? 

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur (flefauch)
Sent: Wednesday, March 14, 2012 1:11 PM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [CDNi] New Version
Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt

Hi Jon,

I agree there is some wiggle room about what exact information set a
dCDN would provide to the uCDN which requires further discussion (ie
pick a spot between a very-high-level approach and a high-enough-level
approach). But I believe the requirement below, as well as the intent
when it was discussed, clearly excludes low-level approaches where the
upstream CDNs gets enough information to make the complete cache
selection. I also believe there was consensus  that dCDNs did not want
to provide visibility on their CDN resource location/status/load...

So to define this exact information set to be advertised by a dCDN, I
think the following are reasonable guiding principles:

            * stick to information that is helpful to the uCDN for
selecting the dCDN (and not the final cache)

Francois

 

While I think I agree with you about the general strategy we should
take, judging from the drafts submitted for this IETF and the discussion
on the list, I would be less confident about saying there is working
group consensus behind it. I think people are still all over the map on
this. In part that's because there's a pretty slippery slope between the
high-level and the low-level, and the words in the requirement GEN-4
that you site - words like "surrogate topology, surrogate status" - are
not precise terms. When we start actually trying to define the
semantics, be it in terms of geography, topology, reachability, cache
enumeration, what have you, that's when we start to see what people are
reading into this words. I think today people are still reading some
pretty different things into them.

Jon Peterson

NeuStar, Inc.

(as an individual)

	We also need to decide how deeply we want a uCDN to understand a
dCDNs resources - effectively, we could have very low-level approaches
where uCDNs execute the entire request-routing algorithm down to
selecting the particular cache, or high-level approaches where the uCDN
has only a general sense of dCDN resources and defers cache selection to
the dCDN. Once we get some agreement about these points, deciding what
type and what granularity of information dCDNs should advertise will be
a lot easier.

"

           cached content, etc.

"

I personally support that decision to focus the current/initial CDNI
work on "high-level approaches where the uCDN has only a general sense
of dCDN resources and defers cache selection to the dCDN". In the
future, once high level approaches are working we can look into "very
low-level approaches where the uCDNs execute the entire request-routing
algorithm down to selecting the particular cache" (if dCDNs are willing
to allow that).

Cheers

Francois

Jon Peterson

NeuStar, Inc.

<snip>

---

From: Stef van der Ziel <[email-masked]>
Date: Fri, 23 Mar 2012 11:45:08 +0100

Hi,

Todays CDNs act like black boxes. Content owners ingest content and somewhere it gets out.
The content owners have no idea about what is happening within the CDN and which delivery nodes have which capabilities, and whether they have capacity, and they also don't know about the topological / geographical location of delivery nodes.

Well, that is about to change :)

Content publishers demand full transparency and control over where their content is stored. For licensing and legal reasons for instance: content may not be stored in specific countries or networks, or may not be stored within the CDN of a certain company from a specific country due to legal or licensing limitations.  Today that is not really an issue: they select a CDN and can arrange an agreement about this subject. However, when in the future CDNs start to offload content and traffic into other CDNs, the content publisher must be made aware of this, and must have full insight about which dCDNs are used to store delivery their content. Content publishers also require the tools to block certain dCDNs from storing and delivering their content even thought their uCDN prefers to use this dCDN.

Content publishers also want more control over popularity and distribution within CDNs. We for instance allow content publishers to see per object and live stream on which delivery nodes these are present. We give insights in the status of these objects: whether there are issues, whether the object is being distributed to additional servers, and whether the object is already checked for integrity. We allow content publishers to pre-push objects and live streams to edge and bursting servers if they expect the content to be popular. We offer all kinds of transparent tools and distribution and management tools. Content publishers can use our REST/SOAP based APIs to fully integrate their media workflow with the CDNs workflow. That is easy within a single CDN, but the feature must be extended to interconnected CDNs as well.

These are just two arguments for exposure, if needed, I can share more arguments.

It is important that a CDN interconnection standard should not just focus on todays needs and todays limitations of 'black box CDNs', but should be prepared for tomorrows requirements and technologies as well. The risk is that the CDNi statement that CDNs should not expose details about inner details will limit future CDNs and CDN interconnection possibilities because of the assumption that CDNs need not expose details.

So it is my recommendation to extend exposure of delivery nodes, availability of delivery nodes, capabilities of delivery nodes, status feedback about objects and live relays per delivery node, distribution controls of delivery nodes, into CDNi, via a proper CDN capabilities exchange API.

Kind regards, 

Stef van der Ziel

On 22 mrt. 2012, at 17:44, Kent Leung (kleung) wrote:

> Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-previdi-cdni-footprint-advertisement, I’d like to confirm if there is any updates needed for the requirements.
>  
> So this is not the debate about high level vs. low level. Just want to confirm the level of description is sufficient for the requirement? Or need additional text for clarification?
>  
>  
> Kent
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
> Subject: Re: [CDNi] New Version Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt
>  
> Hi Jon,
>

---

From: Stef van der Ziel <[email-masked]>
Date: Fri, 23 Mar 2012 12:05:31 +0100

Hi Francois,

Here are my arguments why BGP is not the right protocol for CDNi capabilities exchange:

Modern CDNs are layered structures:

- Content owners workflow
- CDN control plane
- CDN delivery node
- Underlying IP network

Content owners typically interact and automate their workflow with the CDN control plane. They do this via modern APIs, based upon REST or SOAP for instance (plus webdav, FTP, etc). 

CDN control planes typically interacte and automate their workflow with the CDN delivery nodes. They do this via modern APIs, based upon REST or SOAP for instance.  (plus webdav, FTP, etc). 

CDN delivery nodes can be anything: cloud services, virtual services, COTS based servers, appliances or embedded servers/blades within a switch or router or mobile gateway. Logically they are not locked within the IP network. They are running on top of IP networks: whether it is within a local LAN, a RNC, GGSN, WAN, a metro, a telco network, or spanning multiple networks such as the Internet.

When CDNs start to interconnect, the layering could look like this:

- Content owners workflow
- uCDN control plane
- dCDN control plane
- dCDN delivery node
- Underlying IP network

Since all communication between the content owners workflow, the CDN control planes and the CDN delivery nodes are done via modern REST/SOAP based APIs anyway, why introduce a less modern, less fitting, other protocol such as BGP?

CDN capabilities exchange is not a feature that should be limited to interconnected CDNs. CDN control planes need to be able to understand CDN delivery nodes capabilities as well. Modern CDN control planes and CDN delivery nodes don't communicate via BGP but via SOAP/REST based unified APIs. We work with many vendors for delivery software and hardware and none of them will start using BGP.

From a CDN control plane point of view, a delivery node is just a delivery node. It can actually be an account on another CDN, pretending to be a logical delivery node. It doesn't make sense to use BGP in such scenarios. Unified capabilities, reporting and control APIs based upon REST or SOAP are the way forward.

CDN capabilities exchange is not a feature that should be limited to interconnected CDNs. Content publishers need to be able to understand CDN capabilities as well. Their wish is to be able to connect to their CDN account via REST/SOAP based APIs and automatically read out the CDN not just for status but also for capabilities and use the same unified APIs to instruct the CDN for setup of origin backends, publishing points, object distribution, etc. Content publishers will never accept BGP. 

Best, Stef

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 25 Mar 2012 04:12:00 -0700

Hi Stef. Thanks for your inputs.

I think the priority level was set for the requirement to focus on
getting things done and avoid over-complicating the base functions. The
key question is can the exposure be supported later by extensions to the
CDNI interfaces. If there are no obstacles to prevent providing the
details of the dCDN internals in the solution, then we are still ok with
the current requirement. For example, footprint advertisement may
contain the AS of the dCDN for now but extensible to specific IP
prefixes or  addresses of the Surrogates later. The uCDN can select the
dCDN based on the level of information provided. 

Kent

From: Stef van der Ziel [mailto:[email-masked]] 
Sent: Friday, March 23, 2012 3:45 AM
To: [email-masked]
Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Peterson, Jon
Subject: Re: [CDNi] CDNI Requirements for dCDN Surrogate exposure

Hi,

Todays CDNs act like black boxes. Content owners ingest content and
somewhere it gets out.

The content owners have no idea about what is happening within the CDN
and which delivery nodes have which capabilities, and whether they have
capacity, and they also don't know about the topological / geographical
location of delivery nodes.

Content publishers demand full transparency and control over where their
content is stored. For licensing and legal reasons for instance: content
may not be stored in specific countries or networks, or may not be
stored within the CDN of a certain company from a specific country due
to legal or licensing limitations.  Today that is not really an issue:
they select a CDN and can arrange an agreement about this subject.
However, when in the future CDNs start to offload content and traffic
into other CDNs, the content publisher must be made aware of this, and
must have full insight about which dCDNs are used to store delivery
their content. Content publishers also require the tools to block
certain dCDNs from storing and delivering their content even thought
their uCDN prefers to use this dCDN.

Content publishers also want more control over popularity and
distribution within CDNs. We for instance allow content publishers to
see per object and live stream on which delivery nodes these are
present. We give insights in the status of these objects: whether there
are issues, whether the object is being distributed to additional
servers, and whether the object is already checked for integrity. We
allow content publishers to pre-push objects and live streams to edge
and bursting servers if they expect the content to be popular. We offer
all kinds of transparent tools and distribution and management tools.
Content publishers can use our REST/SOAP based APIs to fully integrate
their media workflow with the CDNs workflow. That is easy within a
single CDN, but the feature must be extended to interconnected CDNs as
well.

These are just two arguments for exposure, if needed, I can share more
arguments.

It is important that a CDN interconnection standard should not just
focus on todays needs and todays limitations of 'black box CDNs', but
should be prepared for tomorrows requirements and technologies as well.
The risk is that the CDNi statement that CDNs should not expose details
about inner details will limit future CDNs and CDN interconnection
possibilities because of the assumption that CDNs need not expose
details.

So it is my recommendation to extend exposure of delivery nodes,
availability of delivery nodes, capabilities of delivery nodes, status
feedback about objects and live relays per delivery node, distribution
controls of delivery nodes, into CDNi, via a proper CDN capabilities
exchange API.

Kind regards, 

Stef van der Ziel

           cached content, etc.

Terminology:

   delivery of the Content.

 

Kent

Hi Jon,

Francois

 

Jon Peterson

NeuStar, Inc.

(as an individual)

"

           cached content, etc.

"

Cheers

Francois

Jon Peterson

NeuStar, Inc.

<snip>