Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 Mar 2011 15:35:44 +0000

Guy,

Thanks for the input.

Personally I don't like your suggestion to replace "content" with "content item" because I don't think it adds anything to the clarity of the text but could arguably cause confusion.

IMO using "content" means that the text is readable & the intent is clear but vague enough that we do not need to get into the details of what precisely "content" is.

On the other hand "content item" raises in my mind a number of questions as to what constitutes a single item of content, e.g. in a adaptive streaming scenario such as MS SmoothHD is the "content item" the .ismv file on the Origin, an individual chunk of the .ismv file, does it cover all bitrates or just a specific bitrate, etc. and at this stage I don't think we need to tackle trying to precisely define exactly what we mean by "content item" within the problem statement.

Having said that, if others feel that "content item" is preferable and won't cause us to go down a rathole trying to then define precisely what we mean then I don't feel strongly enough to argue further.

The other edits you suggest are fine by me and we will incorporate them in the definition in an updated problem statement.

Ben

On 28 Feb 2011, at 19:25, Guy Meador wrote:

> Francois, Colleagues,
> 
> I've included some proposed edits to the language for your consideration. Please see below.
> 
> Kind Regards,
> Guy
> 
> 
> On Feb 22, 2011, at 4:53 AM, Francois Le Faucheur wrote:
> 
>> 
>> In line with Phil's initial comment, I'd suggest we try separate handling of content and handling of metadata. How about something like:
>> 
>> "
>> Dynamic content acquisition: Dynamic content acquisition is where a CDN only acquires a content item from the content source in response to an End User requesting that content item from the CDN. In the context of CDN Interconnect, dynamic acquisition means that a downstream CDN does not acquire any the content item from content sources (including upstream CDNs) until a content request for that content item has been delegated to the downstream CDN by an Upstream CDN.
>> 
>> Pre-Positioned content acquisition: Content Pre-positioning is where a CDN acquires a content item from the content source prior to or independent of any End User requesting that content from the CDN. In the context of CDN interconnect the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including upstream CDNs) in advance of or independent of any End User requesting it.
>> 
>> Dynamic CDNI metadata acquisition: In the context of CDN Interconnect, dynamic CDNI metadata acquisition means that a downstream CDN does not acquire CDNI metadata for a content item from the upstream CDN until a content request for that content has been delegated to the downstream CDN by an Upstream CDN.
>> 
>> Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnect, Metadata Pre-positioning is where the Upstream CDN instructs the Downstream CDN to acquire distribution metadata for a content item prior to or independent of any End User requesting that content from the Downstream CDN. 
>> "
>> 
>> Cheers
>> 
>> Francois
>> 
>> PS: If we agree on something like the above, we could also include text discussing possible combinations.
>> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 14 Mar 2011 12:30:32 +0100

On 3 Feb 2011, at 15:58, <[email-masked]> <[email-masked]> wrote:

> Here are some comments on the requirements doc. http://tools.ietf.org/html/draft-lefaucheur-cdni-requirements-00 

Thanks for those. Working on them to incorporate them in the next rev.

> It looks good. Although it is quite detailed at this stage – for example the draft Charter will be much less detailed (presumably) – it is a good idea to start more detailed thinking already.

That's the idea.

>  
> It isn’t exactly clear what MUST, SHOULD and MAY mean in a requirements doc. We assume something like:
> MUST – the protocol will have to do this
> SHOULD – the WG will very likely do this. Further discussion is needed, either about whether it definitely is needed &/or about whether it’s too tricky for the protocol to achieve during the phase covered by the initial charter.
> MAY – it is optional whether the WG does this. Further discussion is needed. But given that there are already a lot of MUSTs & SHOULDs proposed within the initial scope, the default assumption is probably that the WG won’t do this, unless it happens to be naturally included within something else.

I think we now have a common understanding as discussed in http://www.ietf.org/mail-archive/web/cdni/current/msg00121.html. 

> R2
> MUST not => MUST NOT

done.

>  
>    R4  The CDNI solution MUST support delivery to the user agent based
>        on HTTP [ RFC 3040 [RFC2616]].
>  
>    R5  The CDNI solution MUST support acquisition across CDNs based on
>        HTTP [ RFC 3040 [RFC2616]].
>  
>    R6  The CDNI solution MAY support delivery to the user agent based on
>        other protocols than HTTP.
>  
>    R7  The CDNI solution MAY support acquisition across CDNs based on
>        other protocols than HTTP.
>  
> R4 – R7 all seem out of scope, since they’re about content acquisition 

The following clarification note was added:
"
[Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols. Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols]."

>    R8  The CDNI solution SHOULD support cascaded CDN redirection (CDN1
>        redirects to CDN2 that redirects to CDN3) to an arbitrary number
>        of levels.
>  
>    R9  The CDNI solution SHOULD support an arbitrary topology of
>        interconnected CDNs (i.e. the CDN topology cannot be restricted
>        to a tree, a loop-free topology, etc.).
>  
> R8 would fit better in the Request Routing section.
>  
> Should cascading be in initial scope?
> (separate discussion on ML)

So this has been discussed since on mailing list. In general, it affects multiple CDNI APIs/protocols so fits better under the "Generic Reqts" section
In line with that discussion the Reqts doc does following:
	* In initial scope:
		* SHOULD Support cascaded CDNs, SHOULD support arbitrary topologies
		* MUST support loop prevention 
	* Beyond initial scope
		* MUST Support cascaded CDNs, MUST support arbitrary topologies
		
>  
> Suggest merge R9 into R8 & clarify. An arbitrary topology of CDNs seems to be a MUST requirement – so you can have an arbitrary topology in the case where route requests are not cascaded. The question is whether route requests can be cascaded down that topology
>  
>    R12  The CDNI Control API MUST allow the Downstream CDN to
>         communicate to the Upstream CDN coarse information about the
>         Downstream CDN ability and/or willingness to handle requests
>         from the Upstream CDN.
> It might be good to give an example or two. Guess this would be very coarse info, such as “Downstream CDN is too busy to handle requests at the moment”

the example has been included.

>  
>    R13  The CDNI Control API SHOULD allow the Downstream CDN to
>         communicate to the Upstream CDN aggregate information on the
>         Downstream CDN capabilities, resources and affinities (i.e.
>         Preferences or cost).  This information can be taken into
>         account by the Upstream CDN Request Routing system in its CDN
>         Selection decisions.  This information could, for example,
>         include:
> don’t think this is just about the Request Routing system. The information is also useful for the Content Distribution system, eg the Upstream CDN knowing about what content types are supported by the downstream CDN helps it decide what content it will pre-position in this CDN. So add a mention of this in the requirement.

Done.
Added:
"
[Note: Some of this information - such as supported content types and delivery protocols- may also potentially be taken into account by the distribution system in the Upstream CDN for pre-positioning of content and/or metadata in the Downstream CDN in case of pre-positioned content acquisition and/or pre-positioned CDNI metadata acquisition.]
"

> Also, it seems more logical to keep the requirement here (within CDNI Control API) than move it to the Request Routing API.
>  
> R15 & R22
> His => its

done.

>  
>    R16  The CDNI Control API MUST allow the Upstream CDN to request the
>         Downstream CDN (and potential cascaded Downstream CDNs - if
>         cascaded CDNs are supported by the solution) to interrupt
>         delivery of an object (or object set) and trigger specific cache
>         actions or behaviors in the Downstream CDN surrogates (e.g.
>         Object removal from cache, revalidation).  [Editor's note: this
>         functionality is currently described in
>         draft-jenkins-cdni-problem-statement-01 under the Metadata API
>         but probably fits better under the Control API].
> BT (Grant) currently investigating whether it is sufficient to remove ability to access the content, or whether some CSP want the actual bits to be removed.

We are still interested in hearing your conclusions on this. For now, the requirements doc mentions both.

>  
> R20, 21, 22
> Rather than repeating the entire text from R13-R15, think it would be better to say something like:
> R13 upgrades from a SHOULD to a MUST
> This would help the reader understand the deltas.

Added a note along each of the "delta" requirement stating that it is an "upgrade".

>  
> R23
> virtual Downstream CDN => virtual Downstream CDNs

Done.

>  
> note, we have an open issue on the Use Cases draft to add some discussion about virtualisation and about different sorts of Wholesaler model. discuss separately.

OK.

>  
>    R28  The CDNI Request-Routing architecture and API MUST support
>         efficient request-routing for small objects.  This may, for
>         example, call for a mode of operation (e.g.  DNS-based request
>         routing) where freshness and accuracy of CDN/Surrogate selection
>         can be traded-off against reduced request-routing load (e.g.
>         Via lighter-weight queries and caching of request-routing
>         decisions).
>  
>    R29  The CDNI Request-Routing architecture and API MUST support
>         efficient request-routing for large objects.  This may, for
>         example, call for a mode of operation (e.g.  HTTP-based request
>         routing) where freshness and accuracy of CDN/Surrogate selection
>         justifies a per-request decision and a per-request CDNI Request-
>         Routing API call.
>  
> We don’t really understand why these requirements have been split like this –

HTTP-redirect and DNS-redirect methods do not seem objectives in themselves. They just happen to respectively serve well the fundamenatl objectives that are to handle both small objects and large objects effectively.

>  suggest rearrange as:
> R28 – MUST support http-based and DNS-based request routing
> R29 – MUST support both small & large objects and caching vs not-cached 
> Not sure if R29 needs to be said explicitly?
>  
> R28 may be worth discussing, as this might appear directly in the proposed charter. Do people believe 
> -    The proposed WG needs to support both http-based and DNS-based request routing
> -    The proposed WG does NOT do any others
> We think both these points are ok.

Same here.

>  
> R30 & R31
> ... The CDNI Request-Routing    
>         architecture MUST support recursive request routing.
> ... The CDNI
>         Request-Routing architecture MUST support iterative request
>         routing.
>  
> There is a lot of “definition” text (defining Recursive & Iterative) that could be removed with a good definition in another draft. There is a “starter for 10” proposed definition in the Use cases draft. http://tools.ietf.org/html/draft-bertrand-cdni-use-cases . then we could have 
> Rx: The CDNI Request-Routing architecture MUST support recursive request routing and iterative request routing.

The definitions have been extracted and moved up in the "terminology" section. There is a note saying these definitions may be moved to another document later.
The requirements have thus been shortened.

>  
> The key difference seems to be that in the Iterative case the request routing reply comes back to the UA, which then sends out another request to another CDN which replies to the UA with the surrogate’s address. Whereas in the Recursive case the UA sends the request to CDN-A, & CDN-A replies with the surrogate’s address (in the meantime CDN-A sends a request to CDN-B which replies to CDN-A with the surrogate’s address).

The key difference is that with recursive uCDN queries dCDN.
Typically, you'd expect that dCDN would respond to uCDN so that the user can be directly redirected by uCDN to the final dCDN surrogate. However, note that dCDN is free to behave differently (eg respond to uCDN so that the user is redirected to the dCDN request routing system).

>  Note that the text in R30 seems to describe the iterative case, & R31 the recursive one.

R30 said: "...the Upstream CDN can query the Downstream CDN
        Request Routing system via the CDNI Request Routing API"
So R30 was describing recursive. Anyways, please check the definitions in the latest version and let us know if you still see an issue.

>  
>  
>    R32  The CDNI Request-Routing API SHOULD support request loop
>         detection and prevention (e.g.  Prevent request looping in a
>         situation where CDN1 redirects to CDN2 that redirects to CDN3
>         that would redirect to CDN1).
> Perhaps this could refer to R8 (if WG or protocol does R8, then it MUST do R32; if it doesn’t, then R32 is irrelevant)
>  
>    R33  The CDNI Request-Routing loop prevention mechanism SHOULD allow
>         routing of the request (as opposed to the request loop being
>         simply interrupted without routing the request).
> Francois comment:
> << The objective of the requirement is to say that we want more than that: we want to make sure that the loop is detected and the loop is effectively prevented so that the user will get the content somehow.>>
> Agree. Also, there are some other choices – instead of the user getting the content, it may be a failure msg
>  
> Francois comment:
> << Yes. I think R37 is more specific than R38, so I propose we remove R38.>>
> Agree.

Good.

>  It may be worth adding to R37, as examples of the error code, the examples in R38, “by which a Downstream CDN can notify the Upstream CDN when it is unable or unwilling to serve a request”

Done.

>  
> R42 to R46
> Agree that these need some work. 
> The approach suggested (during the Ben /Francois discussion) of a Trigger seems good (for the pre-positioning or “push” case)
> Not sure about the right mix of SHOULD & MUST
> R46 – only applies to the dynamic acquisition model. 
> It would be worth having a definition of dynamic acquisition & pre-positioning (and adding to problem statement). There is some ambiguity whether the terms apply only to content acquisition, or also to metadata. As you could push the CDNI Metadata and then pull the content later.
>  
> So looking at Francois/Ben’s revised proposal:
>  
> <<Rx: The CDNI Control API SHOULD support triggering and control for a pre-positioning model whereby the Upstream CDN requests the Downstream CDN to acquire content and/or associated distribution metadata (and possibly position those into Downstream CDN surrogates) at an appropriate time (now or a specified future time), before the content is actually requested by end users. Note that the actual exchange of metadata and the actual content acquisition are outside the scope of the Control API: those are supported, respectively, via the CDNI Metadata API and the Content Acquisition API. [Editor's Note: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD].
> >> 
>  
> split in two: Rx1 about triggering for content and Rx2 about triggering for CNDI Metadata

Done. In line with agreed separate definitions for "pre-positiong content acquisition" and "pre-positioning CDNI metadata acquisition" .

>  
> <<Rx: The CDNI Metadata API MUST allow the Upstream CDN to provide the Downstream CDN with content distribution metadata of inter-CDN scope.
>  
> Ry:   The CDNI Metadata API MUST support exchange of CDNI metadata for both the dynamic acqusition model (whereby the Downstream CDN surrogates acquire content when it is actually requested by end users) and the pre-positioning model (whereby the Upstream CDN requests the Downstream CDN to acquire content and/or associated distribution metadata before the content is actually requested by endusers). [Editor's Note: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD].
> >> 
> the Metadata API only needs to support dynamic acquisition, ie a request-response; pre-positioning is achieved by the CDN Control API trigger triggering the Metadata API. So suggest both of these are replaced by:
>  
> Rx: The CDNI Metadata API MUST support a model where the Downstream CDN requests content distribution metadata and the Upstream CDN replies with the CDNI Metadata. The request may be triggered by the Upstream CDN through the CDNI Control API (See Rx).
>  
> This also covers, i guess, R45 (“all the relevant Metadata is initially communicated to the Downstream CDN”).
> Open for discussion about R44 (“no, or a subset of, the Metadata is initially communicated to the Downstream CDN along with information about how/where to acquire the rest of the CDNI Metadata”)
>  
>  
> R47
> Francois proposed re-writing as:
> << Rx:      Whether in the pre-positioning model or a dynamic acquisition model, the CDNI Metadata API MUST provide the necessary information to allow the Downstream CDN to acquire the content from an upstream source (e.g. Acquisition protocol and Uniform Resource Identifier in Upstream CDN- or rules to construct this URI).
>  
> Ry:The CDNI metadata MUST allow signaling of one or more upstream sources, where each upstream source can be in the Upstream CDN, in another CDN, the CSP origin server or any arbitrary source designated by the Upstream CDN. Note that some upstream sources (e.g. the content origin server) may or may not be willing to serve the content to the Downstream CDN, if this policy is known to the upstream CDN then it may omit those sources when exchanging CDNI metadata.
> "
>  
> (it says "may omit" and mot "MAY omit" because the document defines requirement on the protocol itself, not so much how an implementation must/should/may use the protocol knobs).

right.

> >> 
> Don’t think this quite works. Just to check what it’s saying:
> Rx: mandatory to USE the api to signal address etc of upstream source from which the downstream CDN can get content
> Ry: CAPABILITY of api to signal address etc of upstream source(s) from which the downstream CDN may be able to get content
>  
> Rx – it seems unrealistic to try to force a guarantee that the source is willing to serve the content to this downstream CDN, as this is about business practices. Delete Rx.

Rx is saying that the CDNI protocol MUST allow uCDN to convey an upstream source from which dCDN can get the content. As you said, this is a "requirements" on the protocol. It does not dictate how this is to be used or not used based on various content/business arrangements. I don't think there is an issue as is.

> Ry: <<The CDNI metadata MUST allow signalling>> - better to say << The CDNI metadata MUST signal>>. Not sure if this is the best place to mention the stuff in the last sentence, but the point is reasonable.
>  
>  
>    R48  The CDNI Metadata API MUST allow the Upstream CDN to add and
>         modify CDNI Metadata into the Downstream CDN.
> => The CDNI Metadata API MUST allow the Upstream CDN to request the addition and modification of CDNI Metadata into the Downstream CDN.
> Similarly, R49 “Request the removal of”
> One CDN asks the other CDN to add/modify/remove CDNI Metadata, but it can’t guarantee what the other CDN actually does

Done.

>  
>    R52  The CDNI Metadata API MUST provide indication by the Downstream
>         CDN to the Upstream CDN of whether the CDNI metadata (and
>         corresponding future request redirections) is accepted or
>         rejected.  When rejected, the CDNI Metadata API MUST allow the
>         Downstream CDN to provide information about the cause of the
>         rejection.
> Is this Requirement realistic? Once a CDN has been told some CDNI Metadata, then it’s that CDN’s information. In other words, it could just lie about whether it is accepted or rejected. The best you can do is an ACK that the information was received.

The requirement is just trying to say that, in case the dCDN does not understand (eg unknown, incorrect metadata) or is not in a position (eg say metadata overload) to accept the new metadata, then the dCDN can indicate that to the uCDN. This is more like basic protocol hygiene.

> An alternative (which we don’t think is a good idea) would be to keep all the CDNI Metadata in sync, signed tokens etc.
> So:-
>    R52  The CDNI Metadata API MUST provide an acknowledgement by the Downstream
>         CDN to the Upstream CDN of the CDNI Metadata request, which potentially includes an error code (for example if the request is rejected).
>  
>    R53  The Metadata that can be distributed by the CDNI Metadata API
>         MUST allow signaling of distribution control policies.  For
>         example, this could potentially include:
> => The CDNI Metadata API MUST...
> Same comment for R54, R57

Done.

> Possibly you could add “(of the content)”

done.

> at the end of the first sentence (ie policies about distribution of the content & not distribution of the CDNI Metadata) – but the examples may make this clear enough.
>  
> R56
> Delete. The changes to R42, 43 have made it redundant
>  
>    R58  The CDNI Metadata API MUST prevent looping of CDNI Metadata
>         distribution across CDNs in the presence of cascaded CDNs.
> Think cascading is being handled as a generic requirement.

Yes.

>  
>    R59  The CDNI Metadata API SHOULD allow signalling of the Virtual CDN
>         identifier to be used in the Downstream CDN for distribution and
>         delivery of the corresponding content (or content set).
> Francois & Ben proposal is good.
>  

Done.

>    R60  The CDNI logging architecture and API MUST ensure reliable, non-
>         repudiable logging of deliveries performed by a Downstream CDN
>        on behalf of an Upstream CDN.
> What does “non-repudiable” mean in this context?
> [1] the downstream CDN cannot deny that it sent a report (at time x, with info y)
> [2] the upstream CDN cannot deny that it received a report (at time x, with info y)
> [3] the CDNs cannot deny the correctness of the info y
> “non-repudiable” definitely means [1], possibly means [2] (interested to hear views), and doesn’t mean [3]. [We think.]

I simplified this requirement to focus on the "reliable" part. To make sure we state that it is not OK to lose transaction log files.
I moved stuff related to non-repudiation in an existing requirement under the security section.

>  
>  
>    R61  The CDNI Logging API MUST provide logging of deliveries to User
>         Agents performed by the Downstream CDN as a result of request
>         redirection by the Upstream CDN.
> This might be interpreted as a list of UAs which have had the content – which is too detailed for a MUST. Guess we want a count of how many times content has been delivered to UA(s).

My assumption is that we want the ability to report down to the per-UA level. 
I added an editor's note to discuss whether there also needs an "aggregate/summarized" format.

>  
>    R62  The CDNI Logging API MUST provide logging of distribution
>         performed by the Upstream CDN as a result of acquisition request
>         by the Downstream CDN.
> ‘acquisition request’ – also applies in the dynamic pre-positioning case.

yes.

>  
> It might be possible to merge R60-63:
>    Rx  The CDNI Logging API MUST provide logging of how many times the Downstream CDN has delivered a piece of content to User Agents as a result of request redirection by the Upstream CDN, or has distributed a piece of content to a Downstream CDN. Delivery of the logging message MUST be reliable and non-repudiable.
>  
> Rx – within initial scope:
> The CDNI Logging API MUST provide control over what is in the logging records, for example: when logging records are sent (eg every 10 minutes, every time 100 content objects have been sent to UAs), what records are of interest (eg these particular objects or object sets) and where to send the records to (different reports might go to different end points, eg report everything once/day to billing end point, report limited info every 10minutes to monitoring end point).
> Perhaps some of this could be beyond initial scope, but seems like there should be some control over what’s in the logging records.

There is a requirement to that effect. It is under the "Control API" section (currently proposed as "beyond initial charter"):
"
Rx:  The CDNI Control protocol SHOULD allow bootstrapping of the CDNI Logging protocol. This information could, for example, include:
	* discovery of the Logging protocol endpoints	
	* information necessary to establish secure communication between the Logging protocol endpoints
	* negotiation/definition of the log file format and set of fields to be exported through the Logging protocol, with some granularity (e.g. On a per content type basis).
	* negotiation/definition of parameters related to transaction Logs export (e.g., export protocol, file compression, export frequency, directory).
"

>  
>    R68  The CDNI Logging API MUST allow a CDN to query another CDN for
>         relevant logging records.
> Clarify that this is historical query (“please re-send me last week’s logging record as i have lost it”)

Actually it was intended for on-demand/real-time query of current logs. I added a clarification.
I am not not clear that there is a requirement for dCDN to support historical logging records. ie as long as dCDN has communicated logging information to uCDN, it is up to uCDN to make sure it stores it for future historical access.
Let us know if you see a requirement for dCDN support of historical logs.

>  
> Missing from the logging section is that the logging record needs to include (aggregated) info where content has been delivered to a UA by a CDN further down a cascade of CDNs.

Yes. Added a requirement for that.

> This is quite challenging and one reason that it seems hard to support cascaded CDNs in the initial WG scope (especially if one allows any flexibility over what is reported, format of reports, security methods, real-time reports, etc).

But, conversely, if flexible report formats, real-time reports etc are not included in the initial scope, it may not bee too difficult to allow reporting of cascaded CDN deliveries. 

>  
>    R70  The CDNI solution MUST provide sufficient protection against
>         Denial of Service attacks.  In particular, this includes
>         protection against spoofed delivery requests sent by user agents
>         directly to a Downstream CDN attempting to appear as if they had
>         been redirected by a given Upstream CDN when they have not.
> “In particular...” seems to imply that it is never valid for a User Agent to request directly to a downstream CDN. But if the downstream CDN is ok to deliver the content then there is no problem.
> Suggest delete “In particular...”

OK.

>  
>    R72  The CDNI solution MUST be able to ensure that the Downstream CDN
>         cannot spoof a transaction log attempting to appear as if it
>         corresponds to a request redirected by a given Upstream CDN when
>         that request has not been redirected by this Upstream CDN.
> Delete. A simpler mechanism would be for the 2 CDNs to compare logs: the downstream CDN’s delivery log vs the upstream CDN’s route-request log. If there are deltas, then have the argument. Meeting R72 would imply lots of tokens etc that seems over-the-top.

So there is some arbitration to be made here. And I agree this may be beyond the bar of initial scope. 
I turned the two related requirements into "SHOULD" so the benefit/complexity trade-off be further discussed before these requirements being dropped.

Thanks a lot for this thorough review.

Francois

>  
> Best wishes,
> Trevor & Phil 
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html