From ben@niven-jenkins.co.uk Tue Feb 1 03:08:23 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD1B3A6914 for ; Tue, 1 Feb 2011 03:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip4q2Gvy1HmR for ; Tue, 1 Feb 2011 03:08:21 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id DDE5A3A68F3 for ; Tue, 1 Feb 2011 03:08:20 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkE91-0001mh-7S; Tue, 01 Feb 2011 11:11:36 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <151967D3-62E3-402C-B3A1-E4968A4C8402@cisco.com> Date: Tue, 1 Feb 2011 11:11:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110126115146.324163A69AB@core3.amsl.com> <7466D828-1FE8-4177-8B87-0369A3E6A16F@cisco.com> <631EFF9A-9F53-4C0E-A626-245EF46BBC19@niven-jenkins.co.uk> <151967D3-62E3-402C-B3A1-E4968A4C8402@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:08:23 -0000 Francois, Thanks for the reply, see inline. I've snipped those parts where we are = in agreement. Ben On 31 Jan 2011, at 12:42, Francois Le Faucheur wrote: > Hi Ben, >> R7 The CDNI solution MAY support acquisition across CDNs based on >> other protocols than HTTP. >>=20 >> s/other protocols than/protocols other than/ >=20 > OK. I assume same goes for R6. >=20 Yes :-) >> R8 The CDNI solution SHOULD support cascaded CDN redirection (CDN1 >> redirects to CDN2 that redirects to CDN3) to an arbitrary number >> of levels. >>=20 >> Based on Haibin=92s e-mail may be include an additional requirement = that it should be possible to limit the number of levels. >=20 > This is covered in the "Request-Routing section" by R34: > " =20 > R34 The CDNI Request-Routing API SHOULD support optional enforcement > of a limit on the number of successive CDN redirections for a > given request. > " > or do you feel this is broader than Request-Routing and should be = moved to the "Generic Requirements" section=20 I am not sure that loop prevention is required for all APIs but it is = probably more generally applicable than just Request Routing, e.g. if I = issue a "content deletion" request which is subsequently cascaded we = probably need to ensure it doesn't loop. >> 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: >> * supported content types and delivery protocols >> * footprint (e.g. layer-3 coverage) >> * a set of metrics/attributes (e.g. Streaming bandwidth, >> storage resources, distribution and delivery priority) >> * a set of affinities (e.g. Preferences, indication of >> distribution/delivery fees) >> * information to facilitate request redirection (e.g. >> Reachability information of Downstream CDN Request Routing >> system).=20 >>=20 >> I am not sure what the exact split should be but I=92d suggest = =93information to facilitate request redirection=94 fits under the CDNI = Request Routing API and much of the other examples may fit best under = the CDNI Metadata API. >=20 > The requirement was intended to bring up "information to facilitate = request redirection=94. In fact, we should just mention exactly that at = the beginning of the requirement. To me, pretty much all of the = examples listed above fit in that category. > I agree this should be move to the "Request-Routing API" section. This = is in line with the recent thread on the list. I think this applies also = to R14, R15, R20, R21 and R22. OK. I think the Request Routing API is a better place for those = requirements but for some things like "information on the capabilities, = resources and affinities of CDNs to which the Downstream CDN may (in = turn) redirect requests" I do wonder whether the Metadata API may be = more appropriate under some circumstances. I think what should drive whether they fit into Request Routing API or = Metadata API is the scope of the information they are expressing. If it = is CDN-wide policy I tend to think metadata API is the better place, if = it's policy within the scope of that particular request routing = transaction then the Request Routing API is probably the right place. I suggest you move them to be requirements on the Request Routing API = and when we are doing the detailed CDNI specification design we'll have = a better idea of the scope of policy we are communicating and the best = API to place it under. >> My thinking is that the CDNI Metadata API is really about = distributing information about an identifiable object (e.g. metadata on = a piece of content, geo-blocking policy, etc.) and for example we could = treat information about footprint in a very similar way to how we would = treat distribution of IP block details for geo-blocking. As such = information is needed by more than just request routers Metdata API = seems a better fit. >=20 > Interesting. I see your point about a similar potential need to = communicate "footprint" descriptions for the sake of conveying = geo-blocking content distribution policies (as part of CDNI Metadata) = and for the sake of conveying CDN footprint coverage (as part of CDNI = Request Routing API). > But I think we can just make a note of that and make sure that if/when = we get to interface specification, a single mechanisms is defined to = convey such footprint description. Then CDNI Metadata interface can = convey information that lists allowed/blocked footprints, while = Request-Routing interface can convey information that associates = capabilities/attributes/etc to footprints. >=20 > In other words, my suggestion is that we keep the discussion on = requirements to convey geo-blocking under CDNI Metadata interface and = requirements to convey CDN coverage/capabilities/attributes as part of = the Request Routing interface, and just consider as a potential encoding = optimization the fact those two may share some common information = elements aka a "footprint"). >=20 > Makes sense?=20 >=20 Yes. I think we will need to specify a naming scheme for well-known = geo-blocks (e.g. based on ISO 3166) so I don't see an issue with both = APIs using the same naming convention for referencing ip blocks (My = geo-location database has approximately 13k ip blocks for the UK [it = would be closer to 20k if they were expressed as valid CIDR blocks) and = I don't want to be passing that volume of data on request routing = transactions). >> R23 The CDNI Control API SHOULD support virtualization of the >> Downstream CDN, so that the Downstream CDN appears as multiple >> virtual Downstream CDN. In that case, the information = discussed >> in the previous requirement MUST be complemented with a Virtual >> CDN Identifier that is unique in the context of the pair of = CDNs >> on both sides of the CDNI Control API. >>=20 >> I am unsure about this requirement as I am not sure exactly what it = is asking for, is there a use case that would illustrate it by way of = example? >=20 > a Downstream CDN may offer multiple delivery services. For example, it = could present a virtual CDN that covers one country only (which may be = of interest to other CDNs that just need coverage of that country) or it = could present a virtual CDN that covers one continent (including the = previous country). Alternatively, it could present two virtual CDNs, one = comprising a given set of resources, and another one with a larger set = of resources. >=20 OK, but how much does the upstream CDN need to know about how (or even = whether) the downstream CDN is virtualised? Can the downstream CDN not = just present itself as two independent CDNs and the upstream doesn't = know (or care) whether they are two "physical" CDNs or two "virtual" = CDNs. As you agreed to remove the last sentence I'm OK with the requirement = staying in - if we need to specify something to support virtualisation = we can, if, as I suspect, we don't need to specify anything specifically = for virtualisation the requirement is harmless. >> R25 The CDNI Control API SHOULD allow bootstrapping of the Content >> Acquisition API. This information could, for example, include: >> * negotiation of the Content Acquisition protocol to be used >> (e.g. HTTP, HTTPS, FTP, ATIS C2), with some granularity >> (e.g. On a per content type basis). >>=20 >> R26 The CDNI Control API SHOULD allow the Upstream CDN to = distribute >> the information necessary to bootstrap delivery authorization >> mechanisms to be performed by Downstream CDN. This information >> could, for example, include: >> * information necessary for surrogates to perform URI >> signature based validation >>=20 >> For R25 & R26 I think the role of the CDNI Control API is to = exchange/negotiate what protocols & authorization mechanisms a CDN = supports. Communication of the specific protocol/auth mechanism to use & = associated details (credentials etc.) should be on a per object (or = object set) basis via the CDNI Metadata API. >=20 > I agree this is a better split. >=20 > I propose to reword as: > " > Rx: The CDNI Control API SHOULD allow bootstrapping of the Content = Acquisition API. This could, for example, include exchange and = negotiation of the Content Acquisition protocols to be used across the = CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2). >=20 > Ry: The CDNI Control API SHOULD allow exchange and negotiation of = delivery authorization mechanisms to be supported across the CDNs (e.g. = URI signature based validation). > " >=20 Works for me. >> 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). >>=20 >> It=92s not clear to me what =93SHOULD allow routing of the request=94 = means, could you provide an example of how it may work? >=20 > Say, there is a redirection loop (CDN1-->CDN2-->CDN3--->CDN1), the = solution could have a pure loop detection mechanism which will result in = a given request/query being dropped when it starts looping. The result = would be that the request is never honored and the user never gets the = content. 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. > Just for example, CDN3 could realize that it is about to redirect a = request to CDN1, while the request had been redirected earlier via CDN1, = so CDN3 may change its "normal" decision and instead serve the request = itself or redirect to another CDN that is not in the "loop". >=20 OK, I understand now. >> R34 The CDNI Request-Routing API SHOULD support optional = enforcement >> of a limit on the number of successive CDN redirections for a >> given request. >>=20 >> =93SHOULD support optional enforcement=94 - Does this mean the CDNI = Request Routing API SHOULD support a mechanism but that honouring the = limit is optional? >=20 > No. It is intended to mean that CDNI Request Routing API should = support a mechanism but invoking the mechanism is optional. >=20 > I propose we reword as: > "The CDNI Request-Routing API SHOULD support an optional mechanism = enforcing a limit on the number of successive CDN redirections for a = given request." >=20 Works for me. >> R43 The CDNI Metadata API SHOULD support a pre-positioning model >> whereby the Upstream CDN requests the Downstream CDN to acquire >> content and 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 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]. >> [Editor's note: this functionality is currently described in >> draft-jenkins-cdni-problem-statement-01 under the Metadata API. >> Should it be moved under the Control API (since it is not >> strictly about exchange of metadata but more about triggering >> multiple actions in downstream CDN, one of them being possibly >> to get metadata) ?]. >>=20 >> The =93trigger=94 is probably better suited to the Control API but = the actual exchange should be via the metadata API, otherwise we will = end up having two different ways to distribute metadata and I think we = want to avoid that situation. >=20 > Agreed. I propose to: >=20 > *1) add a requirement in the Control API section: > " > 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 endusers. 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]. > " >=20 works for me but s/endusers/end users/ > *2) reword R42 and R43 to: > " > Rx: The CDNI Metadata API MUST allow the Upstream CDN to provide the = Downstream CDN with content distribution metadata of inter-CDN scope. >=20 > 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]. > "=20 >=20 works for me >> R44/R45 - I am not sure we need R44 & R45. R42 & R43 are sufficient. = If we have a method to dynamically acquire metadata (R42) and a method = to trigger a downstream CDN to go collect some metadata (R43) I think we = have R44 and R45 covered with the granularity of how much is = communicated in advance controlled by the =93trigger=94. >=20 > I don't think R44 and R45 really follow from R42 and R43. > R42 and R43 just say that there needs to be a way to pass metadata and = that this should work both for dynamic acquisition and for = prepositioning scenarios. It does not imply much on whether this is = achieved by pushing all metadata, pushing some allowing to pull the = rest, issuing a trigger that allows the pull. >=20 OK provided "initially communicated" is understood to be vague enough = that it does not pre-suppose a particular distribution model I'm happy = to leave this until we're doing the detailed design. >> R47 The CDNI Metadata API MUST also provide the necessary >> information to allow the Downstream CDN to attempt to acquire >> the content from the content Origin Server, in case it can not >> be obtained from the Upstream CDN (e.g. Because of a failure >> scenario). Note that the content Origin Server may or may not >> be willing to serve the content to the Downstream CDN since the >> Content Provider may not have a direct agreement/relationship >> with the Downstream CDN for delivery of this content. >>=20 >> In one way this kind of addresses my previous comment >=20 > Right. >=20 >> but my preference would be to combine the two requirements into a = single requirement as follows: >>=20 >> =93Whether 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 one or more = upstream sources. 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. >=20 > I propose to expand a bit and spread over two requirements: >=20 > " > 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).=20 >=20 > 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. > " >=20 > (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). >=20 Works for me. >> R55 appears to be a duplicate of R55 so I suggest it is deleted. >=20 > I think you mean R58. :-) > The trick is that cascaded CDNs may or may not be kept within Initial = scope. > So R55 says: if cascaded CDNs are in initial scope then, the = requirement MUST be met in initial scope. > R58 says that : no matter what, the requirement is to be met in = subsequent scope (ie beyond initial scope). >=20 OK I understand. From ben@niven-jenkins.co.uk Tue Feb 1 03:26:22 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55C13A6CC0 for ; Tue, 1 Feb 2011 03:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smIDCVa3nLyJ for ; Tue, 1 Feb 2011 03:26:19 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 427453A68F3 for ; Tue, 1 Feb 2011 03:26:19 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkEQR-0006SX-6X for cdni@ietf.org; Tue, 01 Feb 2011 11:29:35 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 11:29:35 +0000 References: <03F85AE8-0D91-426C-8C2D-C601E3677C71@niven-jenkins.co.uk> To: cdni@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:26:22 -0000 Colleagues, I originally intended to send the comments below to the list, but forgot = to cc cdni@ietf.org so I am forwarding them now. Ben Begin forwarded message: > From: Ben Niven-Jenkins > Date: 1 February 2011 10:01:05 GMT > To: = > Subject: Some comments on draft-bertrand-cdni-use-cases-01 >=20 > Gilles, Colleagues, >=20 > I read the -01 version of draft-bertrand-cdni-use-cases and had a = couple > of questions and comments which I have included below. I have quoted = some > parts of the draft to provide context and then put my comment or = question > underneath. >=20 >=20 > 2.1.3. Nomadic Users >=20 > Another scenario is nomadic situation. In this scenario a CSP = wishes > to allow users who move to other geographic regions to continue to > access their content. The motivation in this case is to allow > nomadic users to maintain access, rather than to allow all residents > within a region access to the content. >=20 >=20 > =46rom a purely technical perspective I wonder if the nomadic use case > actually differs from the geographic extension use case? i.e. Does the > nomadic use case introduce any new requirements onto the solution? >=20 > Although the text implies a need for a mechanism to restrict access to > just nomadic users and prevent =B3all residents within a region=B2 = having > access I would expect that even in the geographic extension use case = there > would be a requirement to be able to restrict access to a subset of = the > total user population e.g. only those users who had previously > authenticated to the CSP=B9s service. >=20 >=20 > I still think it is worth separately describing the nomadic use case = in > the draft but am I correct in assuming that by itself it doesn't = introduce > any specific requirements that would need to be captured? >=20 >=20 > 2.1.5. Device and Network Technology Extension >=20 > In this use case the CDSP may have the geographic and end-user > coverage that it requires, but wishes to support the delivery of > content to alternative end devices. These devices may sit on remote > networks (such as smartphones connected to a mobile network) and may > also require unique delivery capabilities in the CDN. In this case > the CDSP may federate with another CDSP that offers service to these > Devices. >=20 >=20 > I might be being pedantic but is it the device that requires unique > delivery capabilities or is it that the device only speaks certain > protocols and =B3delivery capabilities in the CDN=B2 really means =B3the= CDN > must support delivery protocol X=B2? >=20 >=20 > The effort required to specifying how to describe different delivery > protocols & which CDNs support them is much reduced compared to = specifying > how to describe the multitude of different devices and their = individual > capabilities. >=20 >=20 > 2.2.2. Resiliency >=20 > ... > Resiliency may also be required against failure to ingest content > from the CSP. In these cases the content may be available from > another CDSP. >=20 >=20 >=20 > I think it would be useful if you could try and expand on the part of = the > resiliency use case related to failures like this as I suspect there = may > be some additional > requirements hiding under the surface. >=20 > For example, is there an assumption that the downstream CDN already = has > the content, or is there an assumption that the failure that meant the > upstream CDN could not ingest the content does not impact the = downstream > CDN's ability to ingest from the same CSP? >=20 >=20 >=20 > 2.4.1. NSP CDSP Use Case >=20 > In a interconnection use case, CDSP-A is likely to offer an SLA to > the CSP including performance or other quality metrics. If it = cannot > meet the SLA it will push content via the interconnection to a = CDSP-B > with CDN capabilities that are in a position to guaranty the SLA, = and > redirect users appropriately to CDSP-B. CDSP-A may not be able to, > or may not wish to deploy its own CDN capabilities to meet the SLA > requirements for only a subset of its CSP customers. The ability to > offer stringent delivery quality SLAs is a differentiator against > other CDSPs and can be sold as a premium service. >=20 >=20 > I think it would be useful if you could try and outline how much of = this > use case you would expect (or require) to be solved technically Vs = some > other channel (e.g. out of band commercial agreements between CDSPs). = That > would help to steer the technical requirement gathering and help keep = the > scope of the problem space well defined. >=20 >=20 > 3.2. Gaps in Existing Solutions and Need for Specifications >=20 >=20 > This section mentions three limitations that were discovered during = your > experiments, I wonder whether they were knock-on effects of those = initial > limitations that it would be worthwhile to describe, for example (and = this > is a made up example) having to define target URLs manually between = CDNs > may have meant that some common CDN features like token/url = authorisation > could not be used. Describing such knock-on effects would be useful as = we > can ensure the CDNI solution addresses those as well as the first = order > requirements. >=20 > (Of course you may not want to reveal all the details of the = limitations > your experiments found and if that's the case, that's OK with me but = you > should still try to ensure the requirements document adequately covers > those use cases). >=20 >=20 >=20 > Regards > Ben >=20 >=20 From dwing@cisco.com Tue Feb 1 08:53:18 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8A03A6C95 for ; Tue, 1 Feb 2011 08:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMMqUaI85uUC for ; Tue, 1 Feb 2011 08:53:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6A9613A6BFF for ; Tue, 1 Feb 2011 08:53:14 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIHAKLKR02rRN+K/2dsb2JhbACWZIEmjH1zoUObIIIbgzgEhRM Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2011 16:56:19 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p11GuJ0d021475; Tue, 1 Feb 2011 16:56:19 GMT From: "Dan Wing" To: Date: Tue, 1 Feb 2011 08:56:19 -0800 Message-ID: <02c301cbc230$f2e9f9f0$d8bdedd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvCMPKlKuWYjkfgTQmzD7RXCSR4Gw== Content-Language: en-us Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:53:18 -0000 > Folks, > > We've posted a "CDNI Requirements" I-D: > https://datatracker.ietf.org/doc/draft-lefaucheur-cdni-requirements/ > > Please, consider this as a first cut whose aim is to facilitate > discussion and convergence on what are "urgent/important" > requirements (that would have to be addressed in a potential initial > WG charter) versus what are "less-urgent/less-important" > requirements (that would be left for future rechartering or left out > of scope altogether). > > Cheers, > > Francois, Mahesh, Grant & Yiu In addition to your existing R4 requirement, the HTTP URI cannot contain an IPv4 address literal. This is necessary for NAT64 to work correctly, and will be necessary for NAT46 to work correctly. The use of IPv4 address literals has been a problem in the wild, but is now mostly resolved. See http://groups.google.com/group/ipv4literals for gory details. -d From yiu_lee@cable.comcast.com Tue Feb 1 09:56:22 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780BE3A6BFA for ; Tue, 1 Feb 2011 09:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.988 X-Spam-Level: X-Spam-Status: No, score=-103.988 tagged_above=-999 required=5 tests=[AWL=-2.253, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLNltiucfZVe for ; Tue, 1 Feb 2011 09:56:21 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 5C8523A6CCC for ; Tue, 1 Feb 2011 09:56:09 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24161138; Tue, 01 Feb 2011 11:10:13 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 12:59:16 -0500 From: "Lee, Yiu" To: Dan Wing , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwjm8QcLGpTjVHkmoijWJ26avqw== Date: Tue, 1 Feb 2011 17:59:15 +0000 Message-ID: In-Reply-To: <02c301cbc230$f2e9f9f0$d8bdedd0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <49EA399811808F428DF3A772B3B40C3C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-lefaucheur-cdni-requirements@tools.ietf.org" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:56:22 -0000 Agreed. So, do you suggest we change the R35 and R54 to FQDN instead? On 2/1/11 11:56 AM, "Dan Wing" wrote: >> Folks, >> >> We've posted a "CDNI Requirements" I-D: >> https://datatracker.ietf.org/doc/draft-lefaucheur-cdni-requirements/ >> >> Please, consider this as a first cut whose aim is to facilitate >> discussion and convergence on what are "urgent/important" >> requirements (that would have to be addressed in a potential initial >> WG charter) versus what are "less-urgent/less-important" >> requirements (that would be left for future rechartering or left out >> of scope altogether). >> >> Cheers, >> >> Francois, Mahesh, Grant & Yiu > >In addition to your existing R4 requirement, the HTTP URI cannot contain >an IPv4 address literal. This is necessary for NAT64 to work correctly, >and will be necessary for NAT46 to work correctly. The use of IPv4 >address >literals has been a problem in the wild, but is now mostly resolved. >See http://groups.google.com/group/ipv4literals for gory details. > >-d > > > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From yiu_lee@cable.comcast.com Tue Feb 1 10:12:05 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5833A6EFD for ; Tue, 1 Feb 2011 10:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.254 X-Spam-Level: X-Spam-Status: No, score=-107.254 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voMd3+beT6-t for ; Tue, 1 Feb 2011 10:12:04 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 338B33A6E9C for ; Tue, 1 Feb 2011 10:12:04 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112382426; Tue, 01 Feb 2011 13:15:17 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 13:15:04 -0500 From: "Lee, Yiu" To: Ben Niven-Jenkins , Francois Le Faucheur Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwjvyFrw8PkcTOk2DHJQWriQcDw== Date: Tue, 1 Feb 2011 18:15:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:12:05 -0000 Hi Ben, On 2/1/11 6:11 AM, "Ben Niven-Jenkins" wrote: >I am not sure that loop prevention is required for all APIs but it is >probably more generally applicable than just Request Routing, e.g. if I >issue a "content deletion" request which is subsequently cascaded we >probably need to ensure it doesn't loop. [YL] I agree with Ben that we loop prevention should only apply on the RR-API. >Yes. I think we will need to specify a naming scheme for well-known >geo-blocks (e.g. based on ISO 3166) so I don't see an issue with both >APIs using the same naming convention for referencing ip blocks (My >geo-location database has approximately 13k ip blocks for the UK [it >would be closer to 20k if they were expressed as valid CIDR blocks) and I >don't want to be passing that volume of data on request routing >transactions). [YL] As Dan Wing pointed out in his other email, I have yet figured out what is the impact when we consider IPv4/IPv6 transition mechanism. At minimum, it is ok for the metadata to contain the actual IP address block information, but all request coming from or going to the end user must be IP address family (ie FQDN) agnostic. >OK, but how much does the upstream CDN need to know about how (or even >whether) the downstream CDN is virtualised? Can the downstream CDN not >just present itself as two independent CDNs and the upstream doesn't know >(or care) whether they are two "physical" CDNs or two "virtual" CDNs. > >As you agreed to remove the last sentence I'm OK with the requirement >staying in - if we need to specify something to support virtualisation we >can, if, as I suspect, we don't need to specify anything specifically for >virtualisation the requirement is harmless. [YL] Ben made me to rethink this requirement. Should we drop the requirement about virtualized CDN altogether? >>> 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). >>>=20 >>> It=B9s not clear to me what =B3SHOULD allow routing of the request=B2 m= eans, >>>could you provide an example of how it may work? >>=20 >> Say, there is a redirection loop (CDN1-->CDN2-->CDN3--->CDN1), the >>solution could have a pure loop detection mechanism which will result in >>a given request/query being dropped when it starts looping. The result >>would be that the request is never honored and the user never gets the >>content. 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. >> Just for example, CDN3 could realize that it is about to redirect a >>request to CDN1, while the request had been redirected earlier via CDN1, >>so CDN3 may change its "normal" decision and instead serve the request >>itself or redirect to another CDN that is not in the "loop". >>=20 > >OK, I understand now. [YL] The loop prevention mechanism should be also smart enough to prevent the follow case: (CDN1-->CDN2-->CDN3-->CDN4-->CDN2) In Francois example, CDN1 can identify who is the origin and detect the loop. In the new example, CDN2 isn't the origin, so CDN2 will need to identify itself in the request so that CDN4 will know. >OK provided "initially communicated" is understood to be vague enough >that it does not pre-suppose a particular distribution model I'm happy to >leave this until we're doing the detailed design. [YL] This is our intention not to "bias" any model in the requirement draft :-) > From dwing@cisco.com Tue Feb 1 10:24:00 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5BC3A6FAC for ; Tue, 1 Feb 2011 10:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbiNCRaRAsoq for ; Tue, 1 Feb 2011 10:23:58 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 679D23A6FA7 for ; Tue, 1 Feb 2011 10:23:58 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcCAEPfR02rR7H+/2dsb2JhbACWJYFljH1zoWGbI4IbgzgEhRM Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2011 18:27:15 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p11IRC9l019511; Tue, 1 Feb 2011 18:27:12 GMT From: "Dan Wing" To: "'Lee, Yiu'" , References: <02c301cbc230$f2e9f9f0$d8bdedd0$@com> In-Reply-To: Date: Tue, 1 Feb 2011 10:27:12 -0800 Message-ID: <035801cbc23d$a53c09c0$efb41d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLwjm8QcLGpTjVHkmoijWJ26avq5Ps9jgg Content-Language: en-us Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:24:00 -0000 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Tuesday, February 01, 2011 9:59 AM > To: Dan Wing; cdni@ietf.org > Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org > Subject: Re: [CDNi] CDNI Requirements I-D > > Agreed. So, do you suggest we change the R35 and R54 to FQDN instead? If I understand those requirements correctly, those two requirements are related to how the CDN moves data amongst its own servers, rather than the URI presented to the client accessing the data. I don't expect anyone will manage a CDN while they are behind a NAT64 or while behind a NAT46, so IPv4 or IPv6 address literals should be fine with those requirements. -d > On 2/1/11 11:56 AM, "Dan Wing" wrote: > > >> Folks, > >> > >> We've posted a "CDNI Requirements" I-D: > >> https://datatracker.ietf.org/doc/draft-lefaucheur-cdni-requirements/ > >> > >> Please, consider this as a first cut whose aim is to facilitate > >> discussion and convergence on what are "urgent/important" > >> requirements (that would have to be addressed in a potential initial > >> WG charter) versus what are "less-urgent/less-important" > >> requirements (that would be left for future rechartering or left out > >> of scope altogether). > >> > >> Cheers, > >> > >> Francois, Mahesh, Grant & Yiu > > > >In addition to your existing R4 requirement, the HTTP URI cannot > contain > >an IPv4 address literal. This is necessary for NAT64 to work > correctly, > >and will be necessary for NAT46 to work correctly. The use of IPv4 > >address > >literals has been a problem in the wild, but is now mostly resolved. > >See http://groups.google.com/group/ipv4literals for gory details. > > > >-d > > > > > > > >_______________________________________________ > >CDNi mailing list > >CDNi@ietf.org > >https://www.ietf.org/mailman/listinfo/cdni From dwing@cisco.com Tue Feb 1 10:35:13 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1B83A6FB1 for ; Tue, 1 Feb 2011 10:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPp80O+1K2rt for ; Tue, 1 Feb 2011 10:35:12 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D07DE3A6844 for ; Tue, 1 Feb 2011 10:35:12 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcCACDiR02rR7H+/2dsb2JhbACWJ4FljH1zoWmbJYVTBIUT Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2011 18:38:30 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p11IcUG3029433; Tue, 1 Feb 2011 18:38:30 GMT From: "Dan Wing" To: "'Ben Niven-Jenkins'" , "'Lee, Yiu'" , References: <035801cbc23d$a53c09c0$efb41d40$@com> In-Reply-To: Date: Tue, 1 Feb 2011 10:38:30 -0800 Message-ID: <037c01cbc23f$38f2b730$aad82590$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvCPobLPJUGjOZcTlK3UfVYfT0NzAAAKLwg Content-Language: en-us Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:35:13 -0000 > >> -----Original Message----- > >> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > >> Sent: Tuesday, February 01, 2011 9:59 AM > >> To: Dan Wing; cdni@ietf.org > >> Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org > >> Subject: Re: [CDNi] CDNI Requirements I-D > >> > >> Agreed. So, do you suggest we change the R35 and R54 to FQDN > instead? > > > >If I understand those requirements correctly, those two requirements > >are related to how the CDN moves data amongst its own servers, rather > >than > >the URI presented to the client accessing the data. I don't expect > >anyone will manage a CDN while they are behind a NAT64 or while > >behind a NAT46, so IPv4 or IPv6 address literals should be fine > >with those requirements. > > > Not quite. > > Part of the response may contain "this is the URI I want you to return > to the UA on my behalf which will redirect the UA to me". thanks. > I would propose adding a general requirement to the document stating > "any > URIs returned to User Agents MUST NOT contain IP address literals in > the > component of the URI" or similar text. Works for me, and that's a nice contained requirement itself. Thanks. -d From yiu_lee@cable.comcast.com Tue Feb 1 10:36:32 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC5F3A6FC9 for ; Tue, 1 Feb 2011 10:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.94 X-Spam-Level: X-Spam-Status: No, score=-103.94 tagged_above=-999 required=5 tests=[AWL=-2.205, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJrX9+eo0Hm2 for ; Tue, 1 Feb 2011 10:36:31 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 620363A6FE1 for ; Tue, 1 Feb 2011 10:36:16 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24169774; Tue, 01 Feb 2011 11:50:09 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 13:39:10 -0500 From: "Lee, Yiu" To: Dan Wing , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwj9QPJUGjOZcTlK3UfVYfT0NzA== Date: Tue, 1 Feb 2011 18:39:10 +0000 Message-ID: In-Reply-To: <035801cbc23d$a53c09c0$efb41d40$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-lefaucheur-cdni-requirements@tools.ietf.org" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:36:32 -0000 Hi Dan, Since CDNi is about to federate CDN in a distributed environment. There may be a case where CDN1 asks CDN2 to stream some contend to the CDN2's user (U2). Let's say U2 is behind a NAT64. In this setup, when U2 generates a URL to the CDN1, the URL may contain the U2's IPv6 address as the request client. This may create problem in CDN1. I have to take back my FQDN suggestion because it won't work either. I have to spend more time to think of this or we can simply declare this is out-of-scope. Nonetheless, the requirement should be clear enough what would be covered and what not. Yiu On 2/1/11 1:27 PM, "Dan Wing" wrote: >> -----Original Message----- >> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >> Sent: Tuesday, February 01, 2011 9:59 AM >> To: Dan Wing; cdni@ietf.org >> Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org >> Subject: Re: [CDNi] CDNI Requirements I-D >>=20 >> Agreed. So, do you suggest we change the R35 and R54 to FQDN instead? > >If I understand those requirements correctly, those two requirements >are related to how the CDN moves data amongst its own servers, rather >than=20 >the URI presented to the client accessing the data. I don't expect >anyone will manage a CDN while they are behind a NAT64 or while >behind a NAT46, so IPv4 or IPv6 address literals should be fine >with those requirements. > >-d > From ben@niven-jenkins.co.uk Tue Feb 1 10:53:33 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAFF3A6FE2 for ; Tue, 1 Feb 2011 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpwACxTJJzXr for ; Tue, 1 Feb 2011 10:53:32 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id D0DC73A6F24 for ; Tue, 1 Feb 2011 10:53:31 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkLPE-0007wM-4D; Tue, 01 Feb 2011 18:56:48 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <035801cbc23d$a53c09c0$efb41d40$@com> Date: Tue, 1 Feb 2011 18:56:46 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <02c301cbc230$f2e9f9f0$d8bdedd0$@com> <035801cbc23d$a53c09c0$efb41d40$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org, cdni@ietf.org, "'Lee, Yiu'" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:53:33 -0000 On 1 Feb 2011, at 18:27, Dan Wing wrote: >> -----Original Message----- >> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >> Sent: Tuesday, February 01, 2011 9:59 AM >> To: Dan Wing; cdni@ietf.org >> Cc: draft-lefaucheur-cdni-requirements@tools.ietf.org >> Subject: Re: [CDNi] CDNI Requirements I-D >> >> Agreed. So, do you suggest we change the R35 and R54 to FQDN instead? > > If I understand those requirements correctly, those two requirements > are related to how the CDN moves data amongst its own servers, rather than > the URI presented to the client accessing the data. I don't expect > anyone will manage a CDN while they are behind a NAT64 or while > behind a NAT46, so IPv4 or IPv6 address literals should be fine > with those requirements. > Not quite. Part of the response may contain "this is the URI I want you to return to the UA on my behalf which will redirect the UA to me". I would propose adding a general requirement to the document stating "any URIs returned to User Agents MUST NOT contain IP address literals in the component of the URI" or similar text. Ben From ben@niven-jenkins.co.uk Tue Feb 1 10:55:00 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DB93A6FC9 for ; Tue, 1 Feb 2011 10:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzJCNpP3+7O5 for ; Tue, 1 Feb 2011 10:54:59 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 5E5E03A6FC4 for ; Tue, 1 Feb 2011 10:54:58 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkLQd-00016V-3V; Tue, 01 Feb 2011 18:58:15 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 1 Feb 2011 18:58:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:55:00 -0000 Yiu, See inline, I've only included the relevant parts of your message and snipped the rest. On 1 Feb 2011, at 18:15, Lee, Yiu wrote: > Hi Ben, >=20 > On 2/1/11 6:11 AM, "Ben Niven-Jenkins" = wrote: >=20 >=20 >> I am not sure that loop prevention is required for all APIs but it is >> probably more generally applicable than just Request Routing, e.g. if = I >> issue a "content deletion" request which is subsequently cascaded we >> probably need to ensure it doesn't loop. >=20 > [YL] I agree with Ben that we loop prevention should only apply on the > RR-API. >=20 Either you misunderstood me or you wrote something different to what you meant. I think loop prevention applies to more than the request routing API (e.g. The Control API or whatever API triggers content deletion) but it is probably not required on all APIs (e.g. Metadata API). Looping requests on the request routing and control APIs are = "dangerous". Looping data on the Metadata and Logging interfaces is probably not "dangerous" but we may still want to have loop prevention as a sanity check (looping data is probably a good indicator something more fundamental is broken somewhere, either in the network or in the CDN configuration). >>>> 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). >>>>=20 >>>> It=B9s not clear to me what =B3SHOULD allow routing of the request=B2= means, >>>> could you provide an example of how it may work? >>>=20 >>> Say, there is a redirection loop (CDN1-->CDN2-->CDN3--->CDN1), the >>> solution could have a pure loop detection mechanism which will = result in >>> a given request/query being dropped when it starts looping. The = result >>> would be that the request is never honored and the user never gets = the >>> content. 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. >>> Just for example, CDN3 could realize that it is about to redirect a >>> request to CDN1, while the request had been redirected earlier via = CDN1, >>> so CDN3 may change its "normal" decision and instead serve the = request >>> itself or redirect to another CDN that is not in the "loop". >>>=20 >>=20 >> OK, I understand now. >=20 > [YL] The loop prevention mechanism should be also smart enough to = prevent > the follow case: > (CDN1-->CDN2-->CDN3-->CDN4-->CDN2) >=20 > In Francois example, CDN1 can identify who is the origin and detect = the > loop. In the new example, CDN2 isn't the origin, so CDN2 will need to > identify itself in the request so that CDN4 will know. Agreed, I think we can achieve both using a pretty simple method similar to BGP's AS-Path but we can debate solutions when we are at the detailed design stage. >=20 >> OK provided "initially communicated" is understood to be vague enough >> that it does not pre-suppose a particular distribution model I'm = happy to >> leave this until we're doing the detailed design. >=20 > [YL] This is our intention not to "bias" any model in the requirement > draft :-) Great :-) Ben From ben@niven-jenkins.co.uk Tue Feb 1 10:55:29 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713B73A6FC9 for ; Tue, 1 Feb 2011 10:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFxZ7mHfVk46 for ; Tue, 1 Feb 2011 10:55:28 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 806BD3A6FC4 for ; Tue, 1 Feb 2011 10:55:28 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkLR7-00016V-He; Tue, 01 Feb 2011 18:58:45 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 1 Feb 2011 18:58:45 +0000 Content-Transfer-Encoding: 7bit Message-Id: <85CBC5C4-E379-4A6F-B487-3BD9744764FA@niven-jenkins.co.uk> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "draft-lefaucheur-cdni-requirements@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:55:29 -0000 On 1 Feb 2011, at 18:39, Lee, Yiu wrote: > Hi Dan, > > Since CDNi is about to federate CDN in a distributed environment. There > may be a case where CDN1 asks CDN2 to stream some contend to the CDN2's > user (U2). Let's say U2 is behind a NAT64. In this setup, when U2 > generates a URL to the CDN1, the URL may contain the U2's IPv6 address as > the request client. This may create problem in CDN1. I have to take back > my FQDN suggestion because it won't work either. U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is not the issue. The issue is that NAT64 relies on the NAT64 device synthesising AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 address literal in the Content-Location header of a HTTP 302 it has no way to communicate with that v4 address as it has no native v4 capability (or no native v4 routing). Using a FQDN (and avoiding v4 address literals) in the Content-Location header would avoid the issue as you first suggested. Ben From yiu_lee@cable.comcast.com Tue Feb 1 10:55:48 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F7B3A6FC9 for ; Tue, 1 Feb 2011 10:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.216 X-Spam-Level: X-Spam-Status: No, score=-107.216 tagged_above=-999 required=5 tests=[AWL=1.247, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE+fbeHRtJ06 for ; Tue, 1 Feb 2011 10:55:47 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 43E3F3A6FC4 for ; Tue, 1 Feb 2011 10:55:47 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112389703; Tue, 01 Feb 2011 13:58:59 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 13:58:55 -0500 From: "Lee, Yiu" To: Ben Niven-Jenkins , Dan Wing , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwkITa0LUlBecsUyiLN9WiQgJXg== Date: Tue, 1 Feb 2011 18:58:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B1369F11750644FA9450AA5A5A14C82@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-lefaucheur-cdni-requirements@tools.ietf.org" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:55:48 -0000 Hi Ben, Thanks for thinking through this. My concern was U2 should put the IP in the URL but it wouldn=B9t happen. This is fine. I agree that if we use the FQDN in the redirect, CDN2 will stream the content to U2 in native v6 if the CDN2 supports v6. Yiu > >U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is not >the issue. The issue is that NAT64 relies on the NAT64 device synthesising >AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 address >literal in the Content-Location header of a HTTP 302 it has no way to >communicate with that v4 address as it has no native v4 capability (or no >native v4 routing). > >Using a FQDN (and avoiding v4 address literals) in the Content-Location >header would avoid the issue as you first suggested. > >Ben > From flefauch@cisco.com Tue Feb 1 10:56:31 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C623A6D4D for ; Tue, 1 Feb 2011 10:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8yyrJjwR0+c for ; Tue, 1 Feb 2011 10:56:30 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 93DDB3A6EBF for ; Tue, 1 Feb 2011 10:56:28 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2011 18:59:45 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p11IxiSA024113; Tue, 1 Feb 2011 18:59:45 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: Date: Tue, 1 Feb 2011 20:00:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Niven-Jenkins Ben , Yiu Lee X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org, Viveganandhan Mahesh Subject: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:56:32 -0000 Ben, Yiu, [breaking into separate topics as this is getting hard to track]: On 1 Feb 2011, at 19:42, Ben Niven-Jenkins wrote: > Yiu, >=20 > See inline, I've only included the relevant parts of your message and > snipped the rest. >=20 > On 01/02/2011 18:15, "Lee, Yiu" wrote: >=20 >> Hi Ben, >>=20 >> On 2/1/11 6:11 AM, "Ben Niven-Jenkins" = wrote: >>=20 >>=20 >>> I am not sure that loop prevention is required for all APIs but it = is >>> probably more generally applicable than just Request Routing, e.g. = if I >>> issue a "content deletion" request which is subsequently cascaded we >>> probably need to ensure it doesn't loop. >>=20 >> [YL] I agree with Ben that we loop prevention should only apply on = the >> RR-API. >=20 > Either you misunderstood me or you wrote something different to what = you > meant. I think loop prevention applies to more than the request = routing > API (e.g. The Control API or whatever API triggers content deletion) = but > it is probably not required on all APIs (e.g. Metadata API). >=20 > Looping requests on the request routing and control APIs are = "dangerous". > Looping data on the Metadata and Logging interfaces is probably not > "dangerous" but we may still want to have loop prevention as a sanity > check (looping data is probably a good indicator something more > fundamental is broken somewhere, either in the network or in the CDN > configuration). This discussion drifted from (i) the ability to limit the number of CDN = redirections (for the sake of avoiding degradation of user experience) = into a discussion on (ii) preventing loops in request touting and other = information exchange. (i) is addressed in: " R34 The CDNI Request-Routing API SHOULD support optional enforcement of a limit on the number of successive CDN redirections for a given request. " (ii) is currently addressed in : 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). 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). (as well as R39 and R40 for longer term) R55 If cascaded CDNs are supported by the CDNI solution, the CDNI Metadata API MUST prevent looping of CDNI Metadata distribution across CDNs. Do you guys still think something is missing? Can you suggest something to cover missing bits? Thanks Francois= From flefauch@cisco.com Tue Feb 1 11:02:44 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFEB3A6DF4 for ; Tue, 1 Feb 2011 11:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7QdecseksPJ for ; Tue, 1 Feb 2011 11:02:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 88D383A6FC4 for ; Tue, 1 Feb 2011 11:02:42 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg, green.gif : 11041, 87 Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2011 19:05:59 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p11J5woH003170; Tue, 1 Feb 2011 19:05:58 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-106-452403164 From: Francois Le Faucheur In-Reply-To: Date: Tue, 1 Feb 2011 20:06:22 +0100 Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: "draft-lefaucheur-cdni-requirements@tools.ietf.org" , "cdni@ietf.org" Subject: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:02:45 -0000 --Apple-Mail-106-452403164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 1 Feb 2011, at 19:58, Lee, Yiu wrote: > Hi Ben, >=20 > Thanks for thinking through this. My concern was U2 should put the IP = in > the URL but it wouldn=B9t happen. This is fine. I agree that if we use = the > FQDN in the redirect, CDN2 will stream the content to U2 in native v6 = if > the CDN2 supports v6. So we should add a requirement along the lines of the one you discussed = earlier with Dan: > I would propose adding a general requirement to the document stating > "any > URIs returned to User Agents MUST NOT contain IP address literals in > the > component of the URI" or similar text. Right? Francois >=20 > Yiu >=20 >>=20 >> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is = not >> the issue. The issue is that NAT64 relies on the NAT64 device = synthesising >> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 = address >> literal in the Content-Location header of a HTTP 302 it has no way to >> communicate with that v4 address as it has no native v4 capability = (or no >> native v4 routing). >>=20 >> Using a FQDN (and avoiding v4 address literals) in the = Content-Location >> header would avoid the issue as you first suggested. >>=20 >> Ben >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com 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 =20 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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 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 --Apple-Mail-106-452403164 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-107-452403164 --Apple-Mail-107-452403164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Ben,

Thanks for thinking through this. My = concern was U2 should put the IP in
the URL but it wouldn=B9t happen. = This is fine. I agree that if we use the
FQDN in the redirect, CDN2 = will stream the content to U2 in native v6 if
the CDN2 supports = v6.

So we should add a = requirement along the lines of the one you discussed earlier with = Dan:

I would = propose adding a general requirement to the document = stating
"any
URIs = returned to User Agents MUST NOT contain IP address literals = in
the
<authority> component of the URI" or similar = text.

Right?
Francois


Yiu


U2 is behind = NAT64 so CDN1 will see an IPv4 address for U2. That is = not
the issue. The issue is = that NAT64 relies on the NAT64 device = synthesising
AAAA DNS = responses as U2 only speaks DNSv6. But if U2 gets an v4 = address
literal in the = Content-Location header of a HTTP 302 it has no way = to
communicate with that v4 = address as it has no native v4 capability (or = no
native v4 = routing).

Using a FQDN = (and avoiding v4 address literals) in the = Content-Location
header would = avoid the issue as you first suggested.

Ben


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

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

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-107-452403164 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-107-452403164-- --Apple-Mail-106-452403164-- From flefauch@cisco.com Tue Feb 1 11:13:30 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC093A6FF8 for ; Tue, 1 Feb 2011 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkOSgMhqQkHV for ; Tue, 1 Feb 2011 11:13:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B36343A6FFB for ; Tue, 1 Feb 2011 11:13:28 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2011 19:16:45 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p11JGiiD006326; Tue, 1 Feb 2011 19:16:45 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-109-453049724 From: Francois Le Faucheur In-Reply-To: Date: Tue, 1 Feb 2011 20:17:09 +0100 Message-Id: <890F0496-50CB-4E24-B501-922A7C43F913@cisco.com> References: <20110126115146.324163A69AB@core3.amsl.com> <7466D828-1FE8-4177-8B87-0369A3E6A16F@cisco.com> <631EFF9A-9F53-4C0E-A626-245EF46BBC19@niven-jenkins.co.uk> <151967D3-62E3-402C-B3A1-E4968A4C8402@cisco.com> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: [CDNi] Information to facilitate request redirection Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:13:30 -0000 --Apple-Mail-109-453049724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 1 Feb 2011, at 12:11, Ben Niven-Jenkins wrote: >=20 >=20 >>> 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: >>> * supported content types and delivery protocols >>> * footprint (e.g. layer-3 coverage) >>> * a set of metrics/attributes (e.g. Streaming bandwidth, >>> storage resources, distribution and delivery priority) >>> * a set of affinities (e.g. Preferences, indication of >>> distribution/delivery fees) >>> * information to facilitate request redirection (e.g. >>> Reachability information of Downstream CDN Request Routing >>> system).=20 >>>=20 >>> I am not sure what the exact split should be but I=92d suggest = =93information to facilitate request redirection=94 fits under the CDNI = Request Routing API and much of the other examples may fit best under = the CDNI Metadata API. >>=20 >> The requirement was intended to bring up "information to facilitate = request redirection=94. In fact, we should just mention exactly that at = the beginning of the requirement. To me, pretty much all of the = examples listed above fit in that category. >> I agree this should be move to the "Request-Routing API" section. = This is in line with the recent thread on the list. I think this applies = also to R14, R15, R20, R21 and R22. >=20 > OK. I think the Request Routing API is a better place for those = requirements but for some things like "information on the capabilities, = resources and affinities of CDNs to which the Downstream CDN may (in = turn) redirect requests" I do wonder whether the Metadata API may be = more appropriate under some circumstances. >=20 > I think what should drive whether they fit into Request Routing API or = Metadata API is the scope of the information they are expressing. If it = is CDN-wide policy I tend to think metadata API is the better place, if = it's policy within the scope of that particular request routing = transaction then the Request Routing API is probably the right place. >=20 > I suggest you move them to be requirements on the Request Routing API = and when we are doing the detailed CDNI specification design we'll have = a better idea of the scope of policy we are communicating and the best = API to place it under. Works for me. Francois --Apple-Mail-109-453049724 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


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:
=      *   supported content types and = delivery protocols
     * =   footprint (e.g. layer-3 = coverage)
     * =   a set of metrics/attributes (e.g.  Streaming = bandwidth,
=          storage resources, = distribution and delivery = priority)
     * =   a set of affinities (e.g.  Preferences, indication = of
=          distribution/deliver= y fees)
     *   information = to facilitate request redirection = (e.g.
=          Reachability = information of Downstream CDN Request = Routing
=          system). =

I am not sure what the exact = split should be but I=92d suggest =93information to facilitate request = redirection=94 fits under the CDNI Request Routing API and much of the = other examples may fit best under the CDNI Metadata = API.

The requirement = was intended to bring up "information to facilitate request = redirection=94. In fact, we should just mention exactly that at the = beginning of the requirement.  To me, pretty much all of the = examples listed above fit in that category.
I agree this should be move to the "Request-Routing API" = section. This is in line with the recent thread on the list. I think = this applies also to R14, R15, R20, R21 and R22.

OK. = I think the Request Routing API is a better place for those requirements = but for some things like "information on the capabilities, resources and = affinities of CDNs to which the Downstream CDN may (in turn) redirect = requests" I do wonder whether the Metadata API may be more appropriate = under some circumstances.

I think what should drive whether they = fit into Request Routing API or Metadata API is the scope of the = information they are expressing. If it is CDN-wide policy I tend to = think metadata API is the better place, if it's policy within the scope = of that particular request routing transaction then the Request Routing = API is probably the right place.

I suggest you move them to be = requirements on the Request Routing API and when we are doing the = detailed CDNI specification design we'll have a better idea of the scope = of policy we are communicating and the best API to place it = under.

Works for = me.

Francois


= --Apple-Mail-109-453049724-- From ben@niven-jenkins.co.uk Tue Feb 1 11:22:30 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A703A6CDB for ; Tue, 1 Feb 2011 11:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Io5I6gJiKP for ; Tue, 1 Feb 2011 11:22:29 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 9D5383A6A7A for ; Tue, 1 Feb 2011 11:22:28 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkLrF-00061L-M7; Tue, 01 Feb 2011 19:25:45 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 1 Feb 2011 19:25:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> References: To: Francois Le Faucheur X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:22:30 -0000 Francois, On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote: > This discussion drifted from (i) the ability to limit the number of = CDN redirections (for the sake of avoiding degradation of user = experience) into a discussion on (ii) preventing loops in request = touting and other information exchange. >=20 That's my fault because I wasn't distinguishing between loop detection = of CDN redirections and other types of loop detection. > (i) is addressed in: > " > R34 The CDNI Request-Routing API SHOULD support optional = enforcement > of a limit on the number of successive CDN redirections for a > given request. > " >=20 > (ii) is currently addressed in : >=20 > 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). >=20 > 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). >=20 > (as well as R39 and R40 for longer term) >=20 > R55 If cascaded CDNs are supported by the CDNI solution, the CDNI > Metadata API MUST prevent looping of CDNI Metadata distribution > across CDNs. >=20 > Do you guys still think something is missing? > Can you suggest something to cover missing bits? >=20 For CDNI Request Routing the above is fine. What I'm saying is I think = loop detection also applies to the control API and may be useful in the = other APIs. I'd therefore suggest making loop detection a general requirement = (SHOULD) and any more specific requirements (e.g. R33) under the = specific API they apply to. Thanks Ben From flefauch@cisco.com Tue Feb 1 11:24:35 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FDF3A6FE0 for ; Tue, 1 Feb 2011 11:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0PoxzEEgrb7 for ; Tue, 1 Feb 2011 11:24:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 69F653A6FDF for ; Tue, 1 Feb 2011 11:24:34 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2011 19:27:51 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p11JRo5E008850; Tue, 1 Feb 2011 19:27:51 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: Date: Tue, 1 Feb 2011 20:28:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BE52158-E0D9-4E1C-9A06-81DD702CD679@cisco.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: [CDNi] Virtual CDNs Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:24:35 -0000 Yiu, On 1 Feb 2011, at 19:15, Lee, Yiu wrote: >=20 >> OK, but how much does the upstream CDN need to know about how (or = even >> whether) the downstream CDN is virtualised? Can the downstream CDN = not >> just present itself as two independent CDNs and the upstream doesn't = know >> (or care) whether they are two "physical" CDNs or two "virtual" CDNs. >>=20 >> As you agreed to remove the last sentence I'm OK with the requirement >> staying in - if we need to specify something to support = virtualisation we >> can, if, as I suspect, we don't need to specify anything specifically = for >> virtualisation the requirement is harmless. >=20 > [YL] Ben made me to rethink this requirement. Should we drop the > requirement about virtualized CDN altogether? The approach suggested above seems fine for me: we keep the requirement = in for now and if it turns out to be achievable without any specific = mechanisms, that's just great. This is only suggested as a potential = "beyond initial scope" item, so I think we may as well keep track of it. Francois From yiu_lee@cable.comcast.com Tue Feb 1 12:19:22 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B76F3A6C5C for ; Tue, 1 Feb 2011 12:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.9 X-Spam-Level: X-Spam-Status: No, score=-103.9 tagged_above=-999 required=5 tests=[AWL=-2.165, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtzDX8T2vEac for ; Tue, 1 Feb 2011 12:19:21 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 610133A6C42 for ; Tue, 1 Feb 2011 12:19:21 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24190750; Tue, 01 Feb 2011 13:33:31 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 15:22:33 -0500 From: "Lee, Yiu" To: Ben Niven-Jenkins , Ben Niven-Jenkins , Francois Le Faucher Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwk3BEUeP0viUi0qgkGD8x06zGQ== Date: Tue, 1 Feb 2011 20:22:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D0CD5B19FB87241AD470FEB1E0ACA09@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:19:22 -0000 Hi Ben, >Either you misunderstood me or you wrote something different to what you >meant. I think loop prevention applies to more than the request routing >API (e.g. The Control API or whatever API triggers content deletion) but >it is probably not required on all APIs (e.g. Metadata API). [YL] Yes, I mis-read you, my bad. > >Looping requests on the request routing and control APIs are "dangerous". >Looping data on the Metadata and Logging interfaces is probably not >"dangerous" but we may still want to have loop prevention as a sanity >check (looping data is probably a good indicator something more >fundamental is broken somewhere, either in the network or in the CDN >configuration). [YL] It is interesting to solve the Control-API looping problem. Actually this makes me think about the recursive nature of the control API (eg. Delete). So we are saying even a downstream CDN peer doesn't have that piece of content, the upstream CDN will send the Delete to it regardless. This seems like a broadcast storm to me. Thoughts? > From yiu_lee@cable.comcast.com Tue Feb 1 12:21:32 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BC13A6C5C for ; Tue, 1 Feb 2011 12:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.82 X-Spam-Level: X-Spam-Status: No, score=-103.82 tagged_above=-999 required=5 tests=[AWL=-2.085, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUVZc4R41mv9 for ; Tue, 1 Feb 2011 12:21:31 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id D04213A6C42 for ; Tue, 1 Feb 2011 12:21:30 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24191137; Tue, 01 Feb 2011 13:35:23 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 15:24:26 -0500 From: "Lee, Yiu" To: Francois Le Faucheur , Niven-Jenkins Ben Thread-Topic: Limit nb of redirects & loop sRe: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwk4FgtT+tszjdEm6tTBPvteKXQ== Date: Tue, 1 Feb 2011 20:24:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <8762BABAFE06F44CA92ED9D1517D22AB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:21:32 -0000 Hi Francois, > >This discussion drifted from (i) the ability to limit the number of CDN >redirections (for the sake of avoiding degradation of user experience) >into a discussion on (ii) preventing loops in request touting and other >information exchange. > >(i) is addressed in: >" > R34 The CDNI Request-Routing API SHOULD support optional enforcement > of a limit on the number of successive CDN redirections for a > given request. >" > >(ii) is currently addressed in : > > 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). > > 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). > >(as well as R39 and R40 for longer term) > > R55 If cascaded CDNs are supported by the CDNI solution, the CDNI > Metadata API MUST prevent looping of CDNI Metadata distribution > across CDNs. > >Do you guys still think something is missing? >Can you suggest something to cover missing bits? > [YL] From the requirement level, I am happy with them. What I discussed in the previous email was more on the design level, not so much on the requirement level. Thanks, Yiu > From ben@niven-jenkins.co.uk Tue Feb 1 14:44:15 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33763A6885 for ; Tue, 1 Feb 2011 14:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.324 X-Spam-Level: X-Spam-Status: No, score=-104.324 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPin2bk1Kk+G for ; Tue, 1 Feb 2011 14:44:15 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 0B96F3A6C85 for ; Tue, 1 Feb 2011 14:44:15 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkP0V-00006d-Pw; Tue, 01 Feb 2011 22:47:32 +0000 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <5F76ED32-580E-4EF7-A3F2-9C815086DA04@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Tue, 1 Feb 2011 22:46:53 +0000 To: "Lee, Yiu" X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:44:16 -0000 Yiu, On 1 Feb 2011, at 20:22, Lee, Yiu wrote: >> Looping requests on the request routing and control APIs are = "dangerous". >> Looping data on the Metadata and Logging interfaces is probably not >> "dangerous" but we may still want to have loop prevention as a sanity >> check (looping data is probably a good indicator something more >> fundamental is broken somewhere, either in the network or in the CDN >> configuration). >=20 > [YL] It is interesting to solve the Control-API looping problem. = Actually > this makes me think about the recursive nature of the control API (eg. > Delete). So we are saying even a downstream CDN peer doesn't have that > piece of content, the upstream CDN will send the Delete to it = regardless. > This seems like a broadcast storm to me. >=20 > Thoughts? In the worst case scenario you could end up with a broadcast storm but I = think we can engineer a solution that avoids that. Firstly not all control API transactions would need to be cascaded - I = haven't done an analysis (we haven't written down a complete view of = what should be in the control API Vs other APIs yet) but I suspect = content deletion may be an exceptional case. Even in the case of content deletion I think a broadcast storm could be = avoided. I'd expect CDNs to have to track who they received delegated = requests from and who they delegated requests to so they can send logs, = produce bills and troubleshoot accordingly. Therefore CDNs should only = cascade deletion requests to CDNs who they think they delegated delivery = to. If a CDN misbehaves and broadcasts the deletion request, downstream = CDNs should be able to determine whether it's relevant to them and not = cascade it if it isn't relevant thus limiting the effect caused by a = misbehaving upstream CDN. Ben From yiu_lee@cable.comcast.com Tue Feb 1 14:56:26 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221C23A6D23 for ; Tue, 1 Feb 2011 14:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.745 X-Spam-Level: X-Spam-Status: No, score=-103.745 tagged_above=-999 required=5 tests=[AWL=-2.010, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D11fX20WOE9 for ; Tue, 1 Feb 2011 14:56:25 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 262BC3A6CA9 for ; Tue, 1 Feb 2011 14:56:25 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24220110; Tue, 01 Feb 2011 16:10:23 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 17:59:26 -0500 From: "Lee, Yiu" To: Benjamin Niven-Jenkins Thread-Topic: [CDNi] CDNI Requirements I-D Thread-Index: AQHLwmOsyPXuoFvgOU2yD7TboBqemQ== Date: Tue, 1 Feb 2011 22:59:25 +0000 Message-ID: In-Reply-To: <5F76ED32-580E-4EF7-A3F2-9C815086DA04@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:56:26 -0000 Hi Ben, I agree with your analysis but what I think is will the TTL is enough rather than proposing a Delete operation altogether. I know it is too early to go to the solution space, but I still want to share my thoughts to you guys. Cheers, Yiu On 2/1/11 5:46 PM, "Benjamin Niven-Jenkins" wrote: >Yiu, > >On 1 Feb 2011, at 20:22, Lee, Yiu wrote: >>> Looping requests on the request routing and control APIs are >>>"dangerous". >>> Looping data on the Metadata and Logging interfaces is probably not >>> "dangerous" but we may still want to have loop prevention as a sanity >>> check (looping data is probably a good indicator something more >>> fundamental is broken somewhere, either in the network or in the CDN >>> configuration). >>=20 >> [YL] It is interesting to solve the Control-API looping problem. >>Actually >> this makes me think about the recursive nature of the control API (eg. >> Delete). So we are saying even a downstream CDN peer doesn't have that >> piece of content, the upstream CDN will send the Delete to it >>regardless. >> This seems like a broadcast storm to me. >>=20 >> Thoughts? > >In the worst case scenario you could end up with a broadcast storm but I >think we can engineer a solution that avoids that. > >Firstly not all control API transactions would need to be cascaded - I >haven't done an analysis (we haven't written down a complete view of what >should be in the control API Vs other APIs yet) but I suspect content >deletion may be an exceptional case. > >Even in the case of content deletion I think a broadcast storm could be >avoided. I'd expect CDNs to have to track who they received delegated >requests from and who they delegated requests to so they can send logs, >produce bills and troubleshoot accordingly. Therefore CDNs should only >cascade deletion requests to CDNs who they think they delegated delivery >to. If a CDN misbehaves and broadcasts the deletion request, downstream >CDNs should be able to determine whether it's relevant to them and not >cascade it if it isn't relevant thus limiting the effect caused by a >misbehaving upstream CDN. > >Ben > > From ben@niven-jenkins.co.uk Tue Feb 1 15:28:53 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A143A6C52 for ; Tue, 1 Feb 2011 15:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.258 X-Spam-Level: X-Spam-Status: No, score=-104.258 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iheHyl2lYzfd for ; Tue, 1 Feb 2011 15:28:52 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id A996D3A688F for ; Tue, 1 Feb 2011 15:28:52 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PkPhh-0005Im-V7; Tue, 01 Feb 2011 23:32:10 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 1 Feb 2011 23:32:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: <96E4975F-A4B8-42FF-ABF9-36A0AA630AF9@niven-jenkins.co.uk> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:28:53 -0000 On 1 Feb 2011, at 22:59, Lee, Yiu wrote: > Hi Ben, > > I agree with your analysis but what I think is will the TTL is enough > rather than proposing a Delete operation altogether. I know it is too > early to go to the solution space, but I still want to share my thoughts > to you guys. IME the majority of the time TTL is sufficient but delete is a mandatory requirement for certain CSPs and without it they'll take their business elsewhere. Otherwise what happens when some CSP accidentally screws up their Cache-Control headers and sets an expiry that is too far in the future, or some disgruntled employee puts a virus infected file on their origin server and the CDN caches it, or they accidentally swap out a childrens TV programme for pornography, etc. Those cases have been seen in the wild (OK, in the case of accidentally serving up porn, the incident I saw in a previous life wasn't CDN related it was an accidental splicing of an adult TV channel into a childrens TV channel) Ben From oran@cisco.com Tue Feb 1 16:44:26 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3F93A703D for ; Tue, 1 Feb 2011 16:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.752 X-Spam-Level: X-Spam-Status: No, score=-109.752 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wot15CGL2Glk for ; Tue, 1 Feb 2011 16:44:25 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DC8B73A7038 for ; Tue, 1 Feb 2011 16:44:25 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2011 00:47:44 +0000 Received: from sjc-vpnasa-287.cisco.com (sjc-vpnasa-287.cisco.com [10.21.105.32]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p120lhDh003770; Wed, 2 Feb 2011 00:47:44 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: Date: Tue, 1 Feb 2011 19:47:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <212C5B7F-B5EC-4CB1-8399-30E88D802EDF@cisco.com> References: To: Francois Le Faucheur X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 00:44:26 -0000 Isn't this a special case of the general 3rd party referral problem? Why = are you writing CDNi-specific requirements? Shouldn't you just say "CDN = interconnection requires third party references and hence depends on = mechanisms for the handling of such in URI's for a number of cases = involving NATs, V4/V6 tunnels, and other scenarios that cause problems = with third party references". I would hate to see a requirement that led to a custom solution for CDN = interconnection that didn't work for any old style of redirection. If IP address literals cause third-party breakage, just banning them = will only mask problems when people add further breakage like split DNS. DaveO On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >=20 > On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >=20 >> Hi Ben, >>=20 >> Thanks for thinking through this. My concern was U2 should put the IP = in >> the URL but it wouldn=B9t happen. This is fine. I agree that if we = use the >> FQDN in the redirect, CDN2 will stream the content to U2 in native v6 = if >> the CDN2 supports v6. >=20 > So we should add a requirement along the lines of the one you = discussed earlier with Dan: >=20 >> I would propose adding a general requirement to the document stating >> "any >> URIs returned to User Agents MUST NOT contain IP address literals in >> the >> component of the URI" or similar text. >=20 > Right? >=20 > Francois >=20 >>=20 >> Yiu >>=20 >>>=20 >>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is = not >>> the issue. The issue is that NAT64 relies on the NAT64 device = synthesising >>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 = address >>> literal in the Content-Location header of a HTTP 302 it has no way = to >>> communicate with that v4 address as it has no native v4 capability = (or no >>> native v4 routing). >>>=20 >>> Using a FQDN (and avoiding v4 address literals) in the = Content-Location >>> header would avoid the issue as you first suggested. >>>=20 >>> Ben >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > >=20 > Francois Le Faucheur > Distinguished Engineer > Corporate Development > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 >=20 > =20 >=20 > > Think before you print. >=20 > 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. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From oran@cisco.com Tue Feb 1 16:50:39 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD69E3A7048 for ; Tue, 1 Feb 2011 16:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.034 X-Spam-Level: X-Spam-Status: No, score=-110.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDfPHKEhW8oZ for ; Tue, 1 Feb 2011 16:50:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 461A73A7045 for ; Tue, 1 Feb 2011 16:50:38 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2011 00:53:56 +0000 Received: from sjc-vpnasa-287.cisco.com (sjc-vpnasa-287.cisco.com [10.21.105.32]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p120rtiI007272; Wed, 2 Feb 2011 00:53:56 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> Date: Tue, 1 Feb 2011 19:53:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 00:50:40 -0000 On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: > Francois, >=20 > On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote: >> This discussion drifted from (i) the ability to limit the number of = CDN redirections (for the sake of avoiding degradation of user = experience) into a discussion on (ii) preventing loops in request = touting and other information exchange. >>=20 >=20 > That's my fault because I wasn't distinguishing between loop detection = of CDN redirections and other types of loop detection. >=20 >> (i) is addressed in: >> " >> R34 The CDNI Request-Routing API SHOULD support optional = enforcement >> of a limit on the number of successive CDN redirections for a >> given request. >> " >>=20 >> (ii) is currently addressed in : >>=20 >> 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). >>=20 >> 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). >>=20 >> (as well as R39 and R40 for longer term) >>=20 >> R55 If cascaded CDNs are supported by the CDNI solution, the CDNI >> Metadata API MUST prevent looping of CDNI Metadata distribution >> across CDNs. >>=20 >> Do you guys still think something is missing? >> Can you suggest something to cover missing bits? >>=20 >=20 > For CDNI Request Routing the above is fine. What I'm saying is I think = loop detection also applies to the control API and may be useful in the = other APIs. >=20 > I'd therefore suggest making loop detection a general requirement = (SHOULD) and any more specific requirements (e.g. R33) under the = specific API they apply to. >=20 I think the requirement is stronger: CDNs need to agree on a common = mechanism for loop detection; otherwise you can get multiplicative loop = diameters and effectively not have useful loop detection when the = non-looping paths are long. This is routing; we know what happens when = you do loop detect with thing like count-to-infinity. Incidently, my favorite loop detection scheme was invented by Knuth all = the way back in volume 2. It has the nice property of detecting loops in = constant memory and with an upper bound of traversing the loop 2 times, = for all loop diameters. Look it up - it's called the "even-odd iteration = counting". DaveO. > Thanks > Ben >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From yiu_lee@cable.comcast.com Tue Feb 1 20:29:43 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB823A6B08 for ; Tue, 1 Feb 2011 20:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.676 X-Spam-Level: X-Spam-Status: No, score=-103.676 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mplX6xXM1L5o for ; Tue, 1 Feb 2011 20:29:42 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 0B3BD3A67D3 for ; Tue, 1 Feb 2011 20:29:41 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24241553; Tue, 01 Feb 2011 21:43:27 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 23:32:26 -0500 From: "Lee, Yiu" To: David R Oran , Francois Le Faucheur Thread-Topic: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D Thread-Index: AQHLwpIw4PlHkEas5UG03D7+C94T3A== Date: Wed, 2 Feb 2011 04:32:24 +0000 Message-ID: In-Reply-To: <212C5B7F-B5EC-4CB1-8399-30E88D802EDF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="utf-8" Content-ID: <1F5B82785C34D642A4C0BDAE34AB943F@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 04:29:43 -0000 QWdyZWVkIGFuZCB3ZSBkaWRuJ3Qgd3JpdGUgYSByZXF1aXJlbWVudCB0aGF0IHdvdWxkIGxlYWQg dG8gYW55IHNwZWNpZmljDQp0ZWNobm9sb2d5LiBBbGwgd2UgYXJlIHNheWluZyBpcyB0aGF0IHRo ZSB0aGUgQ29udGVudC1Mb2NhdGlvbiB3b3VsZA0KY29udGFpbiBGUUROLiBUaGF0J3MgaXQuDQoN Ck9uIDIvMS8xMSA3OjQ3IFBNLCAiRGF2aWQgUiBPcmFuIiA8b3JhbkBjaXNjby5jb20+IHdyb3Rl Og0KDQo+SXNuJ3QgdGhpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCAzcmQgcGFydHkg cmVmZXJyYWwgcHJvYmxlbT8gV2h5DQo+YXJlIHlvdSB3cml0aW5nIENETmktc3BlY2lmaWMgcmVx dWlyZW1lbnRzPyBTaG91bGRuJ3QgeW91IGp1c3Qgc2F5ICJDRE4NCj5pbnRlcmNvbm5lY3Rpb24g cmVxdWlyZXMgdGhpcmQgcGFydHkgcmVmZXJlbmNlcyBhbmQgaGVuY2UgZGVwZW5kcyBvbg0KPm1l Y2hhbmlzbXMgZm9yIHRoZSBoYW5kbGluZyBvZiBzdWNoIGluIFVSSSdzIGZvciBhIG51bWJlciBv ZiBjYXNlcw0KPmludm9sdmluZyBOQVRzLCBWNC9WNiB0dW5uZWxzLCBhbmQgb3RoZXIgc2NlbmFy aW9zIHRoYXQgY2F1c2UgcHJvYmxlbXMNCj53aXRoIHRoaXJkIHBhcnR5IHJlZmVyZW5jZXMiLg0K Pg0KPkkgd291bGQgaGF0ZSB0byBzZWUgYSByZXF1aXJlbWVudCB0aGF0IGxlZCB0byBhIGN1c3Rv bSBzb2x1dGlvbiBmb3IgQ0RODQo+aW50ZXJjb25uZWN0aW9uIHRoYXQgZGlkbid0IHdvcmsgZm9y IGFueSBvbGQgc3R5bGUgb2YgcmVkaXJlY3Rpb24uDQo+DQo+SWYgSVAgYWRkcmVzcyBsaXRlcmFs cyBjYXVzZSB0aGlyZC1wYXJ0eSBicmVha2FnZSwganVzdCBiYW5uaW5nIHRoZW0gd2lsbA0KPm9u bHkgbWFzayBwcm9ibGVtcyB3aGVuIHBlb3BsZSBhZGQgZnVydGhlciBicmVha2FnZSBsaWtlIHNw bGl0IEROUy4NCj4NCj5EYXZlTw0KPg0KPk9uIEZlYiAxLCAyMDExLCBhdCAyOjA2IFBNLCBGcmFu Y29pcyBMZSBGYXVjaGV1ciB3cm90ZToNCj4NCj4+IA0KPj4gT24gMSBGZWIgMjAxMSwgYXQgMTk6 NTgsIExlZSwgWWl1IHdyb3RlOg0KPj4gDQo+Pj4gSGkgQmVuLA0KPj4+IA0KPj4+IFRoYW5rcyBm b3IgdGhpbmtpbmcgdGhyb3VnaCB0aGlzLiBNeSBjb25jZXJuIHdhcyBVMiBzaG91bGQgcHV0IHRo ZSBJUA0KPj4+aW4NCj4+PiB0aGUgVVJMIGJ1dCBpdCB3b3VsZG7CuXQgaGFwcGVuLiBUaGlzIGlz IGZpbmUuIEkgYWdyZWUgdGhhdCBpZiB3ZSB1c2UNCj4+PnRoZQ0KPj4+IEZRRE4gaW4gdGhlIHJl ZGlyZWN0LCBDRE4yIHdpbGwgc3RyZWFtIHRoZSBjb250ZW50IHRvIFUyIGluIG5hdGl2ZSB2Ng0K Pj4+aWYNCj4+PiB0aGUgQ0ROMiBzdXBwb3J0cyB2Ni4NCj4+IA0KPj4gU28gd2Ugc2hvdWxkIGFk ZCBhIHJlcXVpcmVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiB0aGUgb25lIHlvdSBkaXNjdXNzZWQN Cj4+ZWFybGllciB3aXRoIERhbjoNCj4+IA0KPj4+IEkgd291bGQgcHJvcG9zZSBhZGRpbmcgYSBn ZW5lcmFsIHJlcXVpcmVtZW50IHRvIHRoZSBkb2N1bWVudCBzdGF0aW5nDQo+Pj4gImFueQ0KPj4+ IFVSSXMgcmV0dXJuZWQgdG8gVXNlciBBZ2VudHMgTVVTVCBOT1QgY29udGFpbiBJUCBhZGRyZXNz IGxpdGVyYWxzIGluDQo+Pj4gdGhlDQo+Pj4gPGF1dGhvcml0eT4gY29tcG9uZW50IG9mIHRoZSBV UkkiIG9yIHNpbWlsYXIgdGV4dC4NCj4+IA0KPj4gUmlnaHQ/DQo+PiANCj4+IEZyYW5jb2lzDQo+ PiANCj4+PiANCj4+PiBZaXUNCj4+PiANCj4+Pj4gDQo+Pj4+IFUyIGlzIGJlaGluZCBOQVQ2NCBz byBDRE4xIHdpbGwgc2VlIGFuIElQdjQgYWRkcmVzcyBmb3IgVTIuIFRoYXQgaXMNCj4+Pj5ub3QN Cj4+Pj4gdGhlIGlzc3VlLiBUaGUgaXNzdWUgaXMgdGhhdCBOQVQ2NCByZWxpZXMgb24gdGhlIE5B VDY0IGRldmljZQ0KPj4+PnN5bnRoZXNpc2luZw0KPj4+PiBBQUFBIEROUyByZXNwb25zZXMgYXMg VTIgb25seSBzcGVha3MgRE5TdjYuIEJ1dCBpZiBVMiBnZXRzIGFuIHY0DQo+Pj4+YWRkcmVzcw0K Pj4+PiBsaXRlcmFsIGluIHRoZSBDb250ZW50LUxvY2F0aW9uIGhlYWRlciBvZiBhIEhUVFAgMzAy IGl0IGhhcyBubyB3YXkgdG8NCj4+Pj4gY29tbXVuaWNhdGUgd2l0aCB0aGF0IHY0IGFkZHJlc3Mg YXMgaXQgaGFzIG5vIG5hdGl2ZSB2NCBjYXBhYmlsaXR5DQo+Pj4+KG9yIG5vDQo+Pj4+IG5hdGl2 ZSB2NCByb3V0aW5nKS4NCj4+Pj4gDQo+Pj4+IFVzaW5nIGEgRlFETiAoYW5kIGF2b2lkaW5nIHY0 IGFkZHJlc3MgbGl0ZXJhbHMpIGluIHRoZQ0KPj4+PkNvbnRlbnQtTG9jYXRpb24NCj4+Pj4gaGVh ZGVyIHdvdWxkIGF2b2lkIHRoZSBpc3N1ZSBhcyB5b3UgZmlyc3Qgc3VnZ2VzdGVkLg0KPj4+PiAN Cj4+Pj4gQmVuDQo+Pj4+IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4+PiBDRE5pQGlldGYu b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+PiAN Cj4+IDxpbWFnZTAwMS5qcGc+DQo+PiANCj4+IEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+PiBEaXN0 aW5ndWlzaGVkIEVuZ2luZWVyDQo+PiBDb3Jwb3JhdGUgRGV2ZWxvcG1lbnQNCj4+IGZsZWZhdWNo QGNpc2NvLmNvbQ0KPj4gUGhvbmU6ICszMyA0OSA3MjMgMjYxOQ0KPj4gTW9iaWxlOiArMzMgNiAx OSA5OCA1MCA5MA0KPj4gDQo+PiANCj4+IA0KPj4gQ2lzY28gU3lzdGVtcyBGcmFuY2UNCj4+IEdy ZWVuc2lkZQ0KPj4gNDAwIEF2ZSBkZSBSb3VtYW5pbGxlDQo+PiAwNjQxMCBTb3BoaWEgQW50aXBv bGlzDQo+PiBGcmFuY2UNCj4+IENpc2NvLmNvbQ0KPj4gDQo+PiANCj4+ICANCj4+IA0KPj4gPGdy ZWVuLmdpZj4NCj4+ICBUaGluayBiZWZvcmUgeW91IHByaW50Lg0KPj4gDQo+PiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl DQo+PnNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yDQo+PmRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj5yZWNpcGllbnQgKG9yIGF1dGhv cml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0DQo+PnRo ZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVz c2FnZS4NCj4+IA0KPj4gQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25z YWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUNCj4+RGVzbW91bGlucyDigJMgSW1tIEF0bGFu dGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMNCj4+TW91bGluZWF1eCwg QXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVj dGV1cg0KPj5kZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZS4NCj4+IA0K Pj4gRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCj4+IGh0dHA6Ly93d3cu Y2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0K Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBDRE5pIG1haWxpbmcgbGlzdA0KPj4gQ0ROaUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DRE5pIG1haWxpbmcgbGlzdA0KPkNETmlA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0K From flefauch@cisco.com Wed Feb 2 02:40:50 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA613A6C59 for ; Wed, 2 Feb 2011 02:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.647 X-Spam-Level: X-Spam-Status: No, score=-9.647 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4ZMke1JZyy5 for ; Wed, 2 Feb 2011 02:40:49 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 636CD3A6C48 for ; Wed, 2 Feb 2011 02:40:49 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2011 10:44:08 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p12Ai71k008413; Wed, 2 Feb 2011 10:44:07 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: Date: Wed, 2 Feb 2011 11:44:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> To: David R Oran X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 10:40:50 -0000 Dave and all, On 2 Feb 2011, at 01:53, David R Oran wrote: >=20 > On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: >=20 >> Francois, >>=20 >> On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote: >>> This discussion drifted from (i) the ability to limit the number of = CDN redirections (for the sake of avoiding degradation of user = experience) into a discussion on (ii) preventing loops in request = touting and other information exchange. >>>=20 >>=20 >> That's my fault because I wasn't distinguishing between loop = detection of CDN redirections and other types of loop detection. >>=20 >>> (i) is addressed in: >>> " >>> R34 The CDNI Request-Routing API SHOULD support optional = enforcement >>> of a limit on the number of successive CDN redirections for a >>> given request. >>> " >>>=20 >>> (ii) is currently addressed in : >>>=20 >>> 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). >>>=20 >>> 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). >>>=20 >>> (as well as R39 and R40 for longer term) >>>=20 >>> R55 If cascaded CDNs are supported by the CDNI solution, the CDNI >>> Metadata API MUST prevent looping of CDNI Metadata distribution >>> across CDNs. >>>=20 >>> Do you guys still think something is missing? >>> Can you suggest something to cover missing bits? >>>=20 >>=20 >> For CDNI Request Routing the above is fine. What I'm saying is I = think loop detection also applies to the control API and may be useful = in the other APIs. >>=20 >> I'd therefore suggest making loop detection a general requirement = (SHOULD) and any more specific requirements (e.g. R33) under the = specific API they apply to. >>=20 > I think the requirement is stronger: CDNs need to agree on a common = mechanism for loop detection; I agree it is a MUST (as along as "cascaded CDNs" are supported). In the Requirements I-D it was presented: * as a "MUST" for longer term * as a "SHOULD" for shorter term, because support of cascaded = CDNs itself is only listed as a SHOULD for the shorter term (on the = grounds that not supporting it may potentially allow definition of a = simpler solution faster) I think we could either: *A*: * agree right now that the shorter term solution (ie within = initial charter scope) MUST support cascaded CDNs * include a MUST requirement for loop prevention in the Generic = Reqts section and possibly in each API specific section (Control, = Request-Routing, Metadata)=20 *B: * defer the decision about support of cascaded CDNs in shorter = term (ie within initial charter scope) to further discussions * include a "conditional" MUST (ie "if cascaded CDNs are = supported,...") in the Generic Reqts section and possibly in each API = specific section (Control, Request-Routing, Metadata)=20 I would vote for *A* because: * we wouldn't want to go for a shorter term solution that cannot = be easily extended to support cascaded CDNs * there are short term use cases for cascaded CDNs. other voters? Thanks Francois > otherwise you can get multiplicative loop diameters and effectively = not have useful loop detection when the non-looping paths are long. This = is routing; we know what happens when you do loop detect with thing like = count-to-infinity. >=20 > Incidently, my favorite loop detection scheme was invented by Knuth = all the way back in volume 2. It has the nice property of detecting = loops in constant memory and with an upper bound of traversing the loop = 2 times, for all loop diameters. Look it up - it's called the "even-odd = iteration counting". >=20 > DaveO. >=20 >=20 >> Thanks >> Ben >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Wed Feb 2 03:22:17 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472203A6C8F for ; Wed, 2 Feb 2011 03:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.258 X-Spam-Level: X-Spam-Status: No, score=-10.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQJF9k6EjNmV for ; Wed, 2 Feb 2011 03:22:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4B2E33A6BB3 for ; Wed, 2 Feb 2011 03:22:16 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2011 11:25:35 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p12BPYS8018631; Wed, 2 Feb 2011 11:25:35 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 12:26:03 +0100 Message-Id: <8B194528-6D5C-4829-B205-BDF04F66591E@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [CDNi] CDNI BOF at IETF 80 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:22:17 -0000 Hello, This is to announce that a CDNI BOF will take place at IETF 80 (Prague). The BOF request has just been approved by the Transport Area Directors. Initial information on the BOF is available from the IETF BOF Wiki: = http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Additional information will be added as it becomes available. Looking forward to a fruitful discussion in Prague. Francois From oran@cisco.com Wed Feb 2 03:57:57 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41123A6C69 for ; Wed, 2 Feb 2011 03:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.175 X-Spam-Level: X-Spam-Status: No, score=-110.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8lxofAGrii9 for ; Wed, 2 Feb 2011 03:57:56 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9CE6A3A6E66 for ; Wed, 2 Feb 2011 03:57:56 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2011 12:01:16 +0000 Received: from sjc-vpnasa-287.cisco.com (sjc-vpnasa-287.cisco.com [10.21.105.32]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p12C1FEw006318; Wed, 2 Feb 2011 12:01:15 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: <96E4975F-A4B8-42FF-ABF9-36A0AA630AF9@niven-jenkins.co.uk> Date: Wed, 2 Feb 2011 07:01:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1DD63546-ADF1-4144-95CE-8E1BD537C222@cisco.com> References: <96E4975F-A4B8-42FF-ABF9-36A0AA630AF9@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" , Viveganandhan Mahesh , "Lee, Yiu" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:57:57 -0000 On Feb 1, 2011, at 6:32 PM, Ben Niven-Jenkins wrote: >=20 > On 1 Feb 2011, at 22:59, Lee, Yiu wrote: >=20 >> Hi Ben, >>=20 >> I agree with your analysis but what I think is will the TTL is enough >> rather than proposing a Delete operation altogether. I know it is too >> early to go to the solution space, but I still want to share my = thoughts >> to you guys. >=20 > IME the majority of the time TTL is sufficient but delete is a = mandatory > requirement for certain CSPs and without it they'll take their = business > elsewhere. Otherwise what happens when some CSP accidentally screws up > their Cache-Control headers and sets an expiry that is too far in the > future, or some disgruntled employee puts a virus infected file on = their > origin server and the CDN caches it, or they accidentally swap out a > childrens TV programme for pornography, etc. >=20 Of course, a screwup in TTL is likely, while a malfunctioning or = incorrectly applied DELETE is not :-) I agree that there's a requirement for rapidly making an asset = unavailable in the downstream CDN(s). I'm not sure I would phrase the = requirement as being for a delete operation, however. Delete has = arguably clean semantics, but various interesting failure modes and = difficulty in protocol design for distributed operation. I hark back to = my days dealing with the tricky problem of route removal in BGP. Some thoughts on the general removal problem: - Is there a requirement to specify what happens to sessions in progress = with users? Does one CDN get to tell another CDN that they must = instantly abort streaming/download to active users? - Is there a stronger security requirement because now we have a trivial = DoS vector in the protocol? - Is there a need to distinguish between "make this assert unavailable" = and "remove the bits"? For example, there may be a useful feature of = temporarily "disabling" an asset without removing it so that it can be = reinstated without copying the bits all over again? - Can't the whole problem be addressed with less overhead by separating = the content bits from the encryption keys such that there are separate = operations on each? Then revocation of an asset can be done by = invalidating keys without touching the content bits. - =46rom a mechanism standpoint, is there a semantic difference between = "delete" and "update with zero TTL"? We likely need update anyway for = pseudo-live content so conservation of mechanism argues for avoiding a = separate delete operation if it doesn't have usefully different = semantics. > Those cases have been seen in the wild (OK, in the case of = accidentally > serving up porn, the incident I saw in a previous life wasn't CDN = related > it was an accidental splicing of an adult TV channel into a childrens = TV > channel) >=20 Yup, but in at least one case I know of delete would not have helped as = the upstream communication was malfunctioning due to the same root = cause. Cheers, DaveO. > Ben >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From oran@cisco.com Wed Feb 2 06:45:49 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7052A3A6C68 for ; Wed, 2 Feb 2011 06:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.26 X-Spam-Level: X-Spam-Status: No, score=-110.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-hkL8JG6Gmg for ; Wed, 2 Feb 2011 06:45:48 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3FAC23A6B20 for ; Wed, 2 Feb 2011 06:45:48 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2011 14:49:08 +0000 Received: from sjc-vpnasa-939.cisco.com (sjc-vpnasa-939.cisco.com [10.21.107.171]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12En7cD006272; Wed, 2 Feb 2011 14:49:07 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: Date: Wed, 2 Feb 2011 09:49:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <763D5913-8F88-4624-8B9D-48A9103DB7F4@cisco.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 14:45:49 -0000 On Feb 1, 2011, at 11:32 PM, Lee, Yiu wrote: > Agreed and we didn't write a requirement that would lead to any = specific > technology. All we are saying is that the the Content-Location would > contain FQDN. That's it. >=20 I don't follow your reasoning. Saying that is neither necessary (since = in many cases addresses will work), nor sufficient (because in a number = of cases like split DNS an FQDN will not work). I think the requirement is that "people only use URI's that work as = third-party references". This is a difficult area, admittedly, but writing requirements that = don't capture the underlying problem to be solved isn't all that helpful = since in hindsight people will inevitably forget why the requirement = existed. Now, if you want to mandate only FQDNs for some other reason that's = fine, but do you want to close the door to someday having a CDN-friendly = URNs instead of URIs anyway. DaveO. > On 2/1/11 7:47 PM, "David R Oran" wrote: >=20 >> Isn't this a special case of the general 3rd party referral problem? = Why >> are you writing CDNi-specific requirements? Shouldn't you just say = "CDN >> interconnection requires third party references and hence depends on >> mechanisms for the handling of such in URI's for a number of cases >> involving NATs, V4/V6 tunnels, and other scenarios that cause = problems >> with third party references". >>=20 >> I would hate to see a requirement that led to a custom solution for = CDN >> interconnection that didn't work for any old style of redirection. >>=20 >> If IP address literals cause third-party breakage, just banning them = will >> only mask problems when people add further breakage like split DNS. >>=20 >> DaveO >>=20 >> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >>=20 >>>=20 >>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>>=20 >>>> Hi Ben, >>>>=20 >>>> Thanks for thinking through this. My concern was U2 should put the = IP >>>> in >>>> the URL but it wouldn=B9t happen. This is fine. I agree that if we = use >>>> the >>>> FQDN in the redirect, CDN2 will stream the content to U2 in native = v6 >>>> if >>>> the CDN2 supports v6. >>>=20 >>> So we should add a requirement along the lines of the one you = discussed >>> earlier with Dan: >>>=20 >>>> I would propose adding a general requirement to the document = stating >>>> "any >>>> URIs returned to User Agents MUST NOT contain IP address literals = in >>>> the >>>> component of the URI" or similar text. >>>=20 >>> Right? >>>=20 >>> Francois >>>=20 >>>>=20 >>>> Yiu >>>>=20 >>>>>=20 >>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That = is >>>>> not >>>>> the issue. The issue is that NAT64 relies on the NAT64 device >>>>> synthesising >>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 >>>>> address >>>>> literal in the Content-Location header of a HTTP 302 it has no way = to >>>>> communicate with that v4 address as it has no native v4 capability >>>>> (or no >>>>> native v4 routing). >>>>>=20 >>>>> Using a FQDN (and avoiding v4 address literals) in the >>>>> Content-Location >>>>> header would avoid the issue as you first suggested. >>>>>=20 >>>>> Ben >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> >>>=20 >>> Francois Le Faucheur >>> Distinguished Engineer >>> Corporate Development >>> flefauch@cisco.com >>> Phone: +33 49 723 2619 >>> Mobile: +33 6 19 98 50 90 >>>=20 >>>=20 >>>=20 >>> Cisco Systems France >>> Greenside >>> 400 Ave de Roumanille >>> 06410 Sophia Antipolis >>> France >>> Cisco.com >>>=20 >>>=20 >>>=20 >>>=20 >>> >>> Think before you print. >>>=20 >>> 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. >>>=20 >>> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille >>> Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les >>> Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur >>> de la publication: Jean-Luc Michel Givone. >>>=20 >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From trevor.burbridge@bt.com Wed Feb 2 07:01:17 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1EE3A6B20 for ; Wed, 2 Feb 2011 07:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGcNX8k5Qh9i for ; Wed, 2 Feb 2011 07:01:16 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id D9AD33A6CB7 for ; Wed, 2 Feb 2011 07:01:15 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 2 Feb 2011 15:04:34 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.65]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 2 Feb 2011 15:04:34 +0000 From: To: , Date: Wed, 2 Feb 2011 15:04:33 +0000 Thread-Topic: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 Thread-Index: AcvCA1Qy5r+hpupLRlWK/klyRHVaRgA5IVZQ Message-ID: References: <03F85AE8-0D91-426C-8C2D-C601E3677C71@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:01:17 -0000 Thanks for the comments Ben - some replies below: > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: 01 February 2011 11:30 > To: cdni@ietf.org > Subject: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 >=20 > Colleagues, >=20 > I originally intended to send the comments below to the list, but > forgot to cc cdni@ietf.org so I am forwarding them now. >=20 > Ben >=20 >=20 > Begin forwarded message: >=20 > > From: Ben Niven-Jenkins > > Date: 1 February 2011 10:01:05 GMT > > To: ftgroup.com> > > Subject: Some comments on draft-bertrand-cdni-use-cases-01 > > > > Gilles, Colleagues, > > > > I read the -01 version of draft-bertrand-cdni-use-cases and had a > couple > > of questions and comments which I have included below. I have quoted > some > > parts of the draft to provide context and then put my comment or > question > > underneath. > > > > > > 2.1.3. Nomadic Users > > > > Another scenario is nomadic situation. In this scenario a CSP > wishes > > to allow users who move to other geographic regions to continue to > > access their content. The motivation in this case is to allow > > nomadic users to maintain access, rather than to allow all > residents > > within a region access to the content. > > > > > > From a purely technical perspective I wonder if the nomadic use case > > actually differs from the geographic extension use case? i.e. Does > the > > nomadic use case introduce any new requirements onto the solution? No I don't think it differs much. In fact, most of the use cases are very s= imilar if you start looking at technical requirements. > > Although the text implies a need for a mechanism to restrict access > to > > just nomadic users and prevent =B3all residents within a region=B2 havi= ng > > access I would expect that even in the geographic extension use case > there > > would be a requirement to be able to restrict access to a subset of > the > > total user population e.g. only those users who had previously > > authenticated to the CSP=B9s service. As you say the difference is in the Metadata that controls the distribution= . There are probably quite a few scenarios that require a highly expressive= language for the distribution policy. I think standardising things like th= e policy language could be one of the more difficult challenges, and certai= nly one where we have to integrate as much as possible with other industry = bodies. > > I still think it is worth separately describing the nomadic use case > in > > the draft but am I correct in assuming that by itself it doesn't > introduce > > any specific requirements that would need to be captured? We're going through the requirements document now and haven't noticed any g= laring omissions that would be required by the use cases we describe. > > 2.1.5. Device and Network Technology Extension > > > > In this use case the CDSP may have the geographic and end-user > > coverage that it requires, but wishes to support the delivery of > > content to alternative end devices. These devices may sit on > remote > > networks (such as smartphones connected to a mobile network) and > may > > also require unique delivery capabilities in the CDN. In this case > > the CDSP may federate with another CDSP that offers service to > these > > Devices. > > > > > > I might be being pedantic but is it the device that requires unique > > delivery capabilities or is it that the device only speaks certain > > protocols and =B3delivery capabilities in the CDN=B2 really means =B3th= e > CDN > > must support delivery protocol X=B2? Well the CDN requirement would certainly be phrased as you suggest. In tech= nical terms, again there isn't a huge difference - impacts on how expressiv= e the capabilities description is through the control API. This might inclu= de network speed and characteristics, protocols supported, as well as thing= s like screen size and even processing power. Some network characteristics,= some surrogate delivery mechanisms, some device capabilities. > > The effort required to specifying how to describe different delivery > > protocols & which CDNs support them is much reduced compared to > specifying > > how to describe the multitude of different devices and their > individual > > capabilities. Yes, but you may need to know about the devices (at least at some level) - = for example, there's no point in moving a certain encoding to a downstream = CDN if you know that if has no devices that require it. I'm not suggested c= ompiling lists of all devices, but these might be rolled into the CDN capab= ilities at some level. > > 2.2.2. Resiliency > > > > ... > > Resiliency may also be required against failure to ingest content > > from the CSP. In these cases the content may be available from > > another CDSP. > > > > > > > > I think it would be useful if you could try and expand on the part of > the > > resiliency use case related to failures like this as I suspect there > may > > be some additional > > requirements hiding under the surface. > > > > For example, is there an assumption that the downstream CDN already > has > > the content, or is there an assumption that the failure that meant > the > > upstream CDN could not ingest the content does not impact the > downstream > > CDN's ability to ingest from the same CSP? > > > > > > > > 2.4.1. NSP CDSP Use Case > > > > In a interconnection use case, CDSP-A is likely to offer an SLA to > > the CSP including performance or other quality metrics. If it > cannot > > meet the SLA it will push content via the interconnection to a > CDSP-B > > with CDN capabilities that are in a position to guaranty the SLA, > and > > redirect users appropriately to CDSP-B. CDSP-A may not be able to, > > or may not wish to deploy its own CDN capabilities to meet the SLA > > requirements for only a subset of its CSP customers. The ability > to > > offer stringent delivery quality SLAs is a differentiator against > > other CDSPs and can be sold as a premium service. > > > > > > I think it would be useful if you could try and outline how much of > this > > use case you would expect (or require) to be solved technically Vs > some > > other channel (e.g. out of band commercial agreements between CDSPs). > That > > would help to steer the technical requirement gathering and help keep > the > > scope of the problem space well defined. Once again I think it's in the fine detail of metadata and policies. Conten= t metadata might specify SLA delivery criteria. Logging would have to be ab= le to capture similar parameters to measure performance against SLA. CDN ca= pabilities would need to specify performance guarantees or estimates to all= ow an upstream CDN to make an appropriate request routing decision to maint= ain it's SLA agreements. Since the content acquisition (and certainly the business contract) with th= e CSP is out of scope we don't need to worry about the negotiation of the S= LA with the CSP. > > 3.2. Gaps in Existing Solutions and Need for Specifications > > > > > > This section mentions three limitations that were discovered during > your > > experiments, I wonder whether they were knock-on effects of those > initial > > limitations that it would be worthwhile to describe, for example (and > this > > is a made up example) having to define target URLs manually between > CDNs > > may have meant that some common CDN features like token/url > authorisation > > could not be used. Describing such knock-on effects would be useful > as we > > can ensure the CDNI solution addresses those as well as the first > order > > requirements. > > > > (Of course you may not want to reveal all the details of the > limitations > > your experiments found and if that's the case, that's OK with me but > you > > should still try to ensure the requirements document adequately > covers > > those use cases). > > > > > > > > Regards > > Ben > > > > >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange-ftgroup.com Wed Feb 2 09:04:10 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59023A6B58 for ; Wed, 2 Feb 2011 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHKZ3Uw60tn8 for ; Wed, 2 Feb 2011 09:04:09 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 0BE853A6C01 for ; Wed, 2 Feb 2011 09:04:09 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4AC0C6C0009; Wed, 2 Feb 2011 18:07:58 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 3A5116C0007; Wed, 2 Feb 2011 18:07:58 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 18:07:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC2FB.AB453916" Date: Wed, 2 Feb 2011 18:07:26 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02114CFE@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] New (-01) version of CDNI Use Cases drafts Thread-Index: AcvBbZAECiOi4v3LRLCfvZ0sWInFLQAvoKfQACMhw8AAAA8xwAAB3k2QAAA0BFAACRXTMA== From: To: , X-OriginalArrivalTime: 02 Feb 2011 17:07:28.0301 (UTC) FILETIME=[ABACF5D0:01CBC2FB] Subject: [CDNi] TR: New (-01) version of CDNI Use Cases drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:04:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC2FB.AB453916 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, =20 Thanks for your feedback. Please see my comments inline. =20 Best regards, -- Gilles =20 =20 =20 =20 =20 -----Message d'origine----- De : Ben Niven-Jenkins [mailto:ben@velocix.com] Envoy=E9 : lundi 31=20 janvier 2011 18:38 =C0 : BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org=20 Objet : Re: [CDNi] New (-01) version of CDNI Use Cases drafts =20 (...) =20 "2.2.2. Resiliency =20 ... Resiliency may also be required against failure to ingest content from the CSP. In these cases the content may be available from another CDSP." =20 I think it would be useful if you could try and expand on the part=20 of the resiliency use case related to failures like this as I=20 suspect there may be some additional requirements hiding under the = surface. =20 For example, is there an assumption that the downstream CDN already=20 has the content, or is there an assumption that the failure that=20 meant the upstream CDN could not ingest the content does not impact=20 the downstream CDN's ability to ingest from the same CSP? =20 [ GILLES:=20 If the CSP uses some protection=20 mechanism to allow the content ingestion, there could be situations=20 where the upstream CDN successfully ingests the content (the CSP = authorizes the ingestion request), whereas the=20 CSP rejects direct ingestion requests from the downstream CDN. To = circumvent the problem, the dCDN might ingest content through the uCDN. = ] =20 =20 =20 "3.2. Gaps in Existing Solutions and Need for Specifications" =20 =20 This section mentions three limitations that were discovered during=20 your experiments, I wonder whether they were knock-on effects of=20 those initial limitations that it would be worthwhile to describe,=20 for example (and this is a made up example) having to define target=20 URLs manually between CDNs may have meant that some common CDN=20 features like token/url authorisation could not be used. Describing=20 such knock-on effects would be useful as we can ensure the CDNI=20 solution addresses those as well as the first order requirements. =20 (Of course you may not want to reveal all the details of the=20 limitations your experiments found and if that's the case, that's OK=20 with me but you should still try to ensure the requirements document=20 adequately covers those use cases)." =20 [GILLES:=20 The limitations list in this section of the I-D is non exhaustive. We = are=20 preparing an I-D, which will describe our experiments and identified = limitations more in details.=20 We will for sure try to ensure that the requirements draft covers the = identified issues.] =20 ------_=_NextPart_001_01CBC2FB.AB453916 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Ben,

 

Thanks for your feedback. Please = see my comments inline.

 

Best = regards,

--

Gilles

 

 

 

 

 

-----Message d'origine-----

De : Ben Niven-Jenkins = [mailto:ben@velocix.com] Envoy=E9 : lundi 31

janvier 2011 18:38 =C0 : BERTRAND Gilles = RD-CORE-ISS; cdni@ietf.org

Objet : Re: [CDNi] New (-01) version of CDNI Use Cases = drafts

 

(...)

 

"2.2.2.=A0=A0 Resiliency

 

...

Resiliency may also be required against failure to ingest = content

from the CSP.=A0 In = these cases the content may be available from

another = CDSP."

 

I think it would be useful if you could try and expand on = the part

of the resiliency use case related to failures like this as = I

suspect there may be some additional requirements hiding = under the surface.

 

For example, is there an assumption that the downstream CDN = already

has the content, or is there an assumption that the failure = that

meant the upstream CDN could not ingest the content does = not impact

the downstream CDN's ability to ingest from the same = CSP?

 

[ = GILLES:

If = the CSP uses some protection

mechanism to allow the content ingestion, there = could be situations

where the upstream CDN successfully ingests the = content (the CSP authorizes the ingestion request), whereas the =

CSP rejects direct ingestion requests from the = downstream CDN. To circumvent the problem, the dCDN might ingest content = through the uCDN. ]

 

 

 

"3.2.=A0 Gaps in Existing = Solutions and Need for Specifications"

 

 

This section mentions three = limitations that were discovered during

your experiments, I wonder = whether they were knock-on effects of

those initial limitations that = it would be worthwhile to describe,

for example (and this is a made = up example) having to define target

URLs manually between CDNs may = have meant that some common CDN

features like token/url = authorisation could not be used. Describing

such knock-on effects would be = useful as we can ensure the CDNI

solution addresses those as well = as the first order requirements.

 

(Of course you may not want to = reveal all the details of the

limitations your experiments = found and if that's the case, that's OK

with me but you should still try = to ensure the requirements document

adequately covers those use = cases)."

 

[GILLES:

The = limitations list in this section of the I-D is non exhaustive. We are =

preparing an I-D, which = will describe our experiments and identified limitations more in = details.

We will for sure try to = ensure that the requirements draft covers the identified = issues.]

 

------_=_NextPart_001_01CBC2FB.AB453916-- From yiu_lee@cable.comcast.com Wed Feb 2 10:25:00 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA99B3A6DCD for ; Wed, 2 Feb 2011 10:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-1.876, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgvG1BokCsHu for ; Wed, 2 Feb 2011 10:24:59 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id D09723A6D9A for ; Wed, 2 Feb 2011 10:24:58 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.24318344; Wed, 02 Feb 2011 11:39:15 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 2 Feb 2011 13:28:13 -0500 From: "Lee, Yiu" To: David R Oran Thread-Topic: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D Thread-Index: AQHLwwbz4PlHkEas5UG03D7+C94T3A== Date: Wed, 2 Feb 2011 18:28:12 +0000 Message-ID: In-Reply-To: <763D5913-8F88-4624-8B9D-48A9103DB7F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="utf-8" Content-ID: <490C7B9B1219AE4790A9A82BCF78ACD1@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:25:00 -0000 SGkgRGF2ZSwNCg0KTGV0IG1lIGNsYXJpZnkgd2hhdCBJIHRyeSB0byBzYXkuIEluIHRoZSBjdXJy ZW50IHJlcXVpcmVtZW50IGRyYWZ0LCB3ZQ0Kc3BlY2lmaWNhbGx5IGdhdmUgZXhhbXBsZSB0byBp bmNsdWRlIElQIGFkZHJlc3MuIFRoaXMgaXMgd2h5IERhbiByZXBsaWVkDQp3YXJuaW5nIHVzIHRo aXMgd291bGQgYnJlYWsgTkFUNjQuIElNSE8sIHdlIHNob3VsZCByZW1vdmUgdGhvc2UgZXhhbXBs ZXMNCnRvIGhhdmUgSVAgYWRkcmVzcy4gSSBhbSBvayB3aXRoIHlvdXIgc3VnZ2VzdGlvbiAoaWUg dGhpcmQtcGFydHkNCnJlZmVyZW5jZSksIGJ1dCBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBzb21lIGV4 YW1wbGVzIHN1Y2ggYXMgRlFETiwgVVJOLCBldGMNCmFuZCByZW1vdmUgSVAgYWRkcmVzcyBmcm9t IHRoZSBjdXJyZW50IGV4YW1wbGUuDQoNCkNoZWVycywNCllpdQ0KDQoNCk9uIDIvMi8xMSA5OjQ5 IEFNLCAiRGF2aWQgUiBPcmFuIiA8b3JhbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+DQo+T24gRmVi IDEsIDIwMTEsIGF0IDExOjMyIFBNLCBMZWUsIFlpdSB3cm90ZToNCj4NCj4+IEFncmVlZCBhbmQg d2UgZGlkbid0IHdyaXRlIGEgcmVxdWlyZW1lbnQgdGhhdCB3b3VsZCBsZWFkIHRvIGFueSBzcGVj aWZpYw0KPj4gdGVjaG5vbG9neS4gQWxsIHdlIGFyZSBzYXlpbmcgaXMgdGhhdCB0aGUgdGhlIENv bnRlbnQtTG9jYXRpb24gd291bGQNCj4+IGNvbnRhaW4gRlFETi4gVGhhdCdzIGl0Lg0KPj4gDQo+ SSBkb24ndCBmb2xsb3cgeW91ciByZWFzb25pbmcuIFNheWluZyB0aGF0IGlzIG5laXRoZXIgbmVj ZXNzYXJ5IChzaW5jZSBpbg0KPm1hbnkgY2FzZXMgYWRkcmVzc2VzIHdpbGwgd29yayksIG5vciBz dWZmaWNpZW50IChiZWNhdXNlIGluIGEgbnVtYmVyIG9mDQo+Y2FzZXMgbGlrZSBzcGxpdCBETlMg YW4gRlFETiB3aWxsIG5vdCB3b3JrKS4NCj4NCj5JIHRoaW5rIHRoZSByZXF1aXJlbWVudCBpcyB0 aGF0ICJwZW9wbGUgb25seSB1c2UgVVJJJ3MgdGhhdCB3b3JrIGFzDQo+dGhpcmQtcGFydHkgcmVm ZXJlbmNlcyIuDQo+DQo+VGhpcyBpcyBhIGRpZmZpY3VsdCBhcmVhLCBhZG1pdHRlZGx5LCBidXQg d3JpdGluZyByZXF1aXJlbWVudHMgdGhhdCBkb24ndA0KPmNhcHR1cmUgdGhlIHVuZGVybHlpbmcg cHJvYmxlbSB0byBiZSBzb2x2ZWQgaXNuJ3QgYWxsIHRoYXQgaGVscGZ1bCBzaW5jZQ0KPmluIGhp bmRzaWdodCBwZW9wbGUgd2lsbCBpbmV2aXRhYmx5IGZvcmdldCB3aHkgdGhlIHJlcXVpcmVtZW50 IGV4aXN0ZWQuDQo+DQo+Tm93LCBpZiB5b3Ugd2FudCB0byBtYW5kYXRlIG9ubHkgRlFETnMgZm9y IHNvbWUgb3RoZXIgcmVhc29uIHRoYXQncyBmaW5lLA0KPmJ1dCBkbyB5b3Ugd2FudCB0byBjbG9z ZSB0aGUgZG9vciB0byBzb21lZGF5IGhhdmluZyBhIENETi1mcmllbmRseSBVUk5zDQo+aW5zdGVh ZCBvZiBVUklzIGFueXdheS4NCj4NCj5EYXZlTy4NCj4NCj4+IE9uIDIvMS8xMSA3OjQ3IFBNLCAi RGF2aWQgUiBPcmFuIiA8b3JhbkBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gSXNuJ3QgdGhp cyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCAzcmQgcGFydHkgcmVmZXJyYWwgcHJvYmxl bT8NCj4+PldoeQ0KPj4+IGFyZSB5b3Ugd3JpdGluZyBDRE5pLXNwZWNpZmljIHJlcXVpcmVtZW50 cz8gU2hvdWxkbid0IHlvdSBqdXN0IHNheSAiQ0RODQo+Pj4gaW50ZXJjb25uZWN0aW9uIHJlcXVp cmVzIHRoaXJkIHBhcnR5IHJlZmVyZW5jZXMgYW5kIGhlbmNlIGRlcGVuZHMgb24NCj4+PiBtZWNo YW5pc21zIGZvciB0aGUgaGFuZGxpbmcgb2Ygc3VjaCBpbiBVUkkncyBmb3IgYSBudW1iZXIgb2Yg Y2FzZXMNCj4+PiBpbnZvbHZpbmcgTkFUcywgVjQvVjYgdHVubmVscywgYW5kIG90aGVyIHNjZW5h cmlvcyB0aGF0IGNhdXNlIHByb2JsZW1zDQo+Pj4gd2l0aCB0aGlyZCBwYXJ0eSByZWZlcmVuY2Vz Ii4NCj4+PiANCj4+PiBJIHdvdWxkIGhhdGUgdG8gc2VlIGEgcmVxdWlyZW1lbnQgdGhhdCBsZWQg dG8gYSBjdXN0b20gc29sdXRpb24gZm9yIENETg0KPj4+IGludGVyY29ubmVjdGlvbiB0aGF0IGRp ZG4ndCB3b3JrIGZvciBhbnkgb2xkIHN0eWxlIG9mIHJlZGlyZWN0aW9uLg0KPj4+IA0KPj4+IElm IElQIGFkZHJlc3MgbGl0ZXJhbHMgY2F1c2UgdGhpcmQtcGFydHkgYnJlYWthZ2UsIGp1c3QgYmFu bmluZyB0aGVtDQo+Pj53aWxsDQo+Pj4gb25seSBtYXNrIHByb2JsZW1zIHdoZW4gcGVvcGxlIGFk ZCBmdXJ0aGVyIGJyZWFrYWdlIGxpa2Ugc3BsaXQgRE5TLg0KPj4+IA0KPj4+IERhdmVPDQo+Pj4g DQo+Pj4gT24gRmViIDEsIDIwMTEsIGF0IDI6MDYgUE0sIEZyYW5jb2lzIExlIEZhdWNoZXVyIHdy b3RlOg0KPj4+IA0KPj4+PiANCj4+Pj4gT24gMSBGZWIgMjAxMSwgYXQgMTk6NTgsIExlZSwgWWl1 IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIEJlbiwNCj4+Pj4+IA0KPj4+Pj4gVGhhbmtzIGZvciB0 aGlua2luZyB0aHJvdWdoIHRoaXMuIE15IGNvbmNlcm4gd2FzIFUyIHNob3VsZCBwdXQgdGhlIElQ DQo+Pj4+PiBpbg0KPj4+Pj4gdGhlIFVSTCBidXQgaXQgd291bGRuwrl0IGhhcHBlbi4gVGhpcyBp cyBmaW5lLiBJIGFncmVlIHRoYXQgaWYgd2UgdXNlDQo+Pj4+PiB0aGUNCj4+Pj4+IEZRRE4gaW4g dGhlIHJlZGlyZWN0LCBDRE4yIHdpbGwgc3RyZWFtIHRoZSBjb250ZW50IHRvIFUyIGluIG5hdGl2 ZSB2Ng0KPj4+Pj4gaWYNCj4+Pj4+IHRoZSBDRE4yIHN1cHBvcnRzIHY2Lg0KPj4+PiANCj4+Pj4g U28gd2Ugc2hvdWxkIGFkZCBhIHJlcXVpcmVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiB0aGUgb25l IHlvdQ0KPj4+PmRpc2N1c3NlZA0KPj4+PiBlYXJsaWVyIHdpdGggRGFuOg0KPj4+PiANCj4+Pj4+ IEkgd291bGQgcHJvcG9zZSBhZGRpbmcgYSBnZW5lcmFsIHJlcXVpcmVtZW50IHRvIHRoZSBkb2N1 bWVudCBzdGF0aW5nDQo+Pj4+PiAiYW55DQo+Pj4+PiBVUklzIHJldHVybmVkIHRvIFVzZXIgQWdl bnRzIE1VU1QgTk9UIGNvbnRhaW4gSVAgYWRkcmVzcyBsaXRlcmFscyBpbg0KPj4+Pj4gdGhlDQo+ Pj4+PiA8YXV0aG9yaXR5PiBjb21wb25lbnQgb2YgdGhlIFVSSSIgb3Igc2ltaWxhciB0ZXh0Lg0K Pj4+PiANCj4+Pj4gUmlnaHQ/DQo+Pj4+IA0KPj4+PiBGcmFuY29pcw0KPj4+PiANCj4+Pj4+IA0K Pj4+Pj4gWWl1DQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBVMiBpcyBiZWhpbmQgTkFUNjQgc28g Q0ROMSB3aWxsIHNlZSBhbiBJUHY0IGFkZHJlc3MgZm9yIFUyLiBUaGF0IGlzDQo+Pj4+Pj4gbm90 DQo+Pj4+Pj4gdGhlIGlzc3VlLiBUaGUgaXNzdWUgaXMgdGhhdCBOQVQ2NCByZWxpZXMgb24gdGhl IE5BVDY0IGRldmljZQ0KPj4+Pj4+IHN5bnRoZXNpc2luZw0KPj4+Pj4+IEFBQUEgRE5TIHJlc3Bv bnNlcyBhcyBVMiBvbmx5IHNwZWFrcyBETlN2Ni4gQnV0IGlmIFUyIGdldHMgYW4gdjQNCj4+Pj4+ PiBhZGRyZXNzDQo+Pj4+Pj4gbGl0ZXJhbCBpbiB0aGUgQ29udGVudC1Mb2NhdGlvbiBoZWFkZXIg b2YgYSBIVFRQIDMwMiBpdCBoYXMgbm8gd2F5DQo+Pj4+Pj50bw0KPj4+Pj4+IGNvbW11bmljYXRl IHdpdGggdGhhdCB2NCBhZGRyZXNzIGFzIGl0IGhhcyBubyBuYXRpdmUgdjQgY2FwYWJpbGl0eQ0K Pj4+Pj4+IChvciBubw0KPj4+Pj4+IG5hdGl2ZSB2NCByb3V0aW5nKS4NCj4+Pj4+PiANCj4+Pj4+ PiBVc2luZyBhIEZRRE4gKGFuZCBhdm9pZGluZyB2NCBhZGRyZXNzIGxpdGVyYWxzKSBpbiB0aGUN Cj4+Pj4+PiBDb250ZW50LUxvY2F0aW9uDQo+Pj4+Pj4gaGVhZGVyIHdvdWxkIGF2b2lkIHRoZSBp c3N1ZSBhcyB5b3UgZmlyc3Qgc3VnZ2VzdGVkLg0KPj4+Pj4+IA0KPj4+Pj4+IEJlbg0KPj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4+Pj4+IENETmlAaWV0Zi5vcmcNCj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KPj4+PiANCj4+ Pj4gPGltYWdlMDAxLmpwZz4NCj4+Pj4gDQo+Pj4+IEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+Pj4+ IERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4+Pj4gQ29ycG9yYXRlIERldmVsb3BtZW50DQo+Pj4+ IGZsZWZhdWNoQGNpc2NvLmNvbQ0KPj4+PiBQaG9uZTogKzMzIDQ5IDcyMyAyNjE5DQo+Pj4+IE1v YmlsZTogKzMzIDYgMTkgOTggNTAgOTANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gQ2lzY28g U3lzdGVtcyBGcmFuY2UNCj4+Pj4gR3JlZW5zaWRlDQo+Pj4+IDQwMCBBdmUgZGUgUm91bWFuaWxs ZQ0KPj4+PiAwNjQxMCBTb3BoaWEgQW50aXBvbGlzDQo+Pj4+IEZyYW5jZQ0KPj4+PiBDaXNjby5j b20NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxncmVlbi5naWY+DQo+Pj4+IFRo aW5rIGJlZm9yZSB5b3UgcHJpbnQuDQo+Pj4+IA0KPj4+PiBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlDQo+Pj4+IHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yDQo+Pj4+IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZQ0KPj4+PmludGVuZGVkDQo+Pj4+IHJlY2lwaWVudCAob3IgYXV0 aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QNCj4+ Pj4gdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhp cyBtZXNzYWdlLg0KPj4+PiANCj4+Pj4gQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDD oCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUNCj4+Pj4gRGVzbW91bGlucyDi gJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMNCj4+ Pj4gTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1Mg TmFudGVycmUsDQo+Pj4+RGlyZWN0ZXVyDQo+Pj4+IGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1 YyBNaWNoZWwgR2l2b25lLg0KPj4+PiANCj4+Pj4gRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1h dGlvbiBnbyB0bzoNCj4+Pj4gaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1 c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gQ0ROaSBtYWlsaW5n IGxpc3QNCj4+Pj4gQ0ROaUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NkbmkNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IENETmkgbWFpbGluZyBsaXN0DQo+Pj4gQ0ROaUBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KPj4g DQo+DQoNCg== From oran@cisco.com Wed Feb 2 15:26:13 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CED3A6C80 for ; Wed, 2 Feb 2011 15:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.317 X-Spam-Level: X-Spam-Status: No, score=-110.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCWHfz+ZuipH for ; Wed, 2 Feb 2011 15:26:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5A64D3A6BC2 for ; Wed, 2 Feb 2011 15:26:12 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2011 23:29:33 +0000 Received: from sjc-vpnasa-939.cisco.com (sjc-vpnasa-939.cisco.com [10.21.107.171]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p12NTW4H004238; Wed, 2 Feb 2011 23:29:32 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: Date: Wed, 2 Feb 2011 18:29:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <55711E30-4BFA-4749-9EAA-9EBF725BC1FF@cisco.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:26:13 -0000 On Feb 2, 2011, at 1:28 PM, Lee, Yiu wrote: > Hi Dave, >=20 > Let me clarify what I try to say. In the current requirement draft, we > specifically gave example to include IP address. This is why Dan = replied > warning us this would break NAT64. IMHO, we should remove those = examples > to have IP address. I am ok with your suggestion (ie third-party > reference), but I would like to give some examples such as FQDN, URN, = etc > and remove IP address from the current example. >=20 I agree that giving examples of problematic URI forms, including those = that cause third-party reference problems, would be a good addition to = the document. I myself was remiss in being so terse and not giving = examples myself in my email. Thanks for the thoughtful reply. I was mostly aiming at ensuring that we didn't just laser-focus on IP = addresses as problematic in URIs since sometimes they are and sometimes = they aren't. Just banning IP addresses from URIs used in CDNi is = attacking only one manifestation of the problem Incidentally, a good example of where FQDNs can also go astray is the = split-DNS situation I previously alluded to. When you have split DNS, = servers in one domain may return different results from servers in other = domains, or potentially fail to return any useful results. This may in = fact be a real problem in CDNi situations as service providers (and = sometimes enterprises as well) are sometimes enticed by the supposed = benefits of using split-DNS techniques to hide the names of internal = resources. Another example I might raise (with some trepidation) is = "carrier ENUM" where the DNS FQDNs for phone numbers resolve differently = (or not at all) in different SP networks. DaveO > Cheers, > Yiu >=20 >=20 > On 2/2/11 9:49 AM, "David R Oran" wrote: >=20 >>=20 >> On Feb 1, 2011, at 11:32 PM, Lee, Yiu wrote: >>=20 >>> Agreed and we didn't write a requirement that would lead to any = specific >>> technology. All we are saying is that the the Content-Location would >>> contain FQDN. That's it. >>>=20 >> I don't follow your reasoning. Saying that is neither necessary = (since in >> many cases addresses will work), nor sufficient (because in a number = of >> cases like split DNS an FQDN will not work). >>=20 >> I think the requirement is that "people only use URI's that work as >> third-party references". >>=20 >> This is a difficult area, admittedly, but writing requirements that = don't >> capture the underlying problem to be solved isn't all that helpful = since >> in hindsight people will inevitably forget why the requirement = existed. >>=20 >> Now, if you want to mandate only FQDNs for some other reason that's = fine, >> but do you want to close the door to someday having a CDN-friendly = URNs >> instead of URIs anyway. >>=20 >> DaveO. >>=20 >>> On 2/1/11 7:47 PM, "David R Oran" wrote: >>>=20 >>>> Isn't this a special case of the general 3rd party referral = problem? >>>> Why >>>> are you writing CDNi-specific requirements? Shouldn't you just say = "CDN >>>> interconnection requires third party references and hence depends = on >>>> mechanisms for the handling of such in URI's for a number of cases >>>> involving NATs, V4/V6 tunnels, and other scenarios that cause = problems >>>> with third party references". >>>>=20 >>>> I would hate to see a requirement that led to a custom solution for = CDN >>>> interconnection that didn't work for any old style of redirection. >>>>=20 >>>> If IP address literals cause third-party breakage, just banning = them >>>> will >>>> only mask problems when people add further breakage like split DNS. >>>>=20 >>>> DaveO >>>>=20 >>>> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >>>>=20 >>>>>=20 >>>>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>>>>=20 >>>>>> Hi Ben, >>>>>>=20 >>>>>> Thanks for thinking through this. My concern was U2 should put = the IP >>>>>> in >>>>>> the URL but it wouldn=B9t happen. This is fine. I agree that if = we use >>>>>> the >>>>>> FQDN in the redirect, CDN2 will stream the content to U2 in = native v6 >>>>>> if >>>>>> the CDN2 supports v6. >>>>>=20 >>>>> So we should add a requirement along the lines of the one you >>>>> discussed >>>>> earlier with Dan: >>>>>=20 >>>>>> I would propose adding a general requirement to the document = stating >>>>>> "any >>>>>> URIs returned to User Agents MUST NOT contain IP address literals = in >>>>>> the >>>>>> component of the URI" or similar text. >>>>>=20 >>>>> Right? >>>>>=20 >>>>> Francois >>>>>=20 >>>>>>=20 >>>>>> Yiu >>>>>>=20 >>>>>>>=20 >>>>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That = is >>>>>>> not >>>>>>> the issue. The issue is that NAT64 relies on the NAT64 device >>>>>>> synthesising >>>>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 >>>>>>> address >>>>>>> literal in the Content-Location header of a HTTP 302 it has no = way >>>>>>> to >>>>>>> communicate with that v4 address as it has no native v4 = capability >>>>>>> (or no >>>>>>> native v4 routing). >>>>>>>=20 >>>>>>> Using a FQDN (and avoiding v4 address literals) in the >>>>>>> Content-Location >>>>>>> header would avoid the issue as you first suggested. >>>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>> >>>>>=20 >>>>> Francois Le Faucheur >>>>> Distinguished Engineer >>>>> Corporate Development >>>>> flefauch@cisco.com >>>>> Phone: +33 49 723 2619 >>>>> Mobile: +33 6 19 98 50 90 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cisco Systems France >>>>> Greenside >>>>> 400 Ave de Roumanille >>>>> 06410 Sophia Antipolis >>>>> France >>>>> Cisco.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> >>>>> Think before you print. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, = Rue Camille >>>>> Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les >>>>> Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, >>>>> Directeur >>>>> de la publication: Jean-Luc Michel Givone. >>>>>=20 >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>=20 >=20 From philip.eardley@bt.com Thu Feb 3 02:14:44 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F4E3A68F0 for ; Thu, 3 Feb 2011 02:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.422 X-Spam-Level: X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HtsiwpdnVCu for ; Thu, 3 Feb 2011 02:14:43 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 48FB23A68A0 for ; Thu, 3 Feb 2011 02:14:43 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 3 Feb 2011 10:18:04 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.92]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 3 Feb 2011 10:18:04 +0000 From: To: , Date: Thu, 3 Feb 2011 10:18:03 +0000 Thread-Topic: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D Thread-Index: AcvCxjJWx0a1ZACFTFaWTeQyG1WpegAw08VA Message-ID: <9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> <4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com> In-Reply-To: <4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 10:14:44 -0000 Cascaded CDNs would be nice.=20 Cascading is missing from the logging section - where it seems hard. the lo= gging record needs to include (aggregated) info where content has been deli= vered to a UA by a CDN further down a cascade of CDNs. This is quite challe= nging, especially if one allows any flexibility over what is reported, form= at of reports, security methods, real-time reports, etc.=20 Agree that cascading should be mentioned as a generic requirement - and we = treat it at the same requirements level for all the APIs (whether that's: M= UST in initial scope, SHOULD, or beyond initial scope). Personally think there is quite a lot "within initial scope" in the require= ments draft, and cascading might be deferrable if it adds significant work = to standardising the APIs - as most of the value of CDN interconnect seems = to come from the "one hop" case ie: CSP -> Upstream CDN -> Downstream CDN -> UA -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: 02 February 2011 10:45 To: David R Oran Cc: cdni@ietf.org; Viveganandhan Mahesh; Yiu Lee Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D Dave and all, On 2 Feb 2011, at 01:53, David R Oran wrote: >=20 > On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: >=20 >> Francois, >>=20 >> On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote: >>> This discussion drifted from (i) the ability to limit the number of CDN= redirections (for the sake of avoiding degradation of user experience) int= o a discussion on (ii) preventing loops in request touting and other inform= ation exchange. >>>=20 >>=20 >> That's my fault because I wasn't distinguishing between loop detection o= f CDN redirections and other types of loop detection. >>=20 >>> (i) is addressed in: >>> " >>> R34 The CDNI Request-Routing API SHOULD support optional enforcement >>> of a limit on the number of successive CDN redirections for a >>> given request. >>> " >>>=20 >>> (ii) is currently addressed in : >>>=20 >>> 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). >>>=20 >>> 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). >>>=20 >>> (as well as R39 and R40 for longer term) >>>=20 >>> R55 If cascaded CDNs are supported by the CDNI solution, the CDNI >>> Metadata API MUST prevent looping of CDNI Metadata distribution >>> across CDNs. >>>=20 >>> Do you guys still think something is missing? >>> Can you suggest something to cover missing bits? >>>=20 >>=20 >> For CDNI Request Routing the above is fine. What I'm saying is I think l= oop detection also applies to the control API and may be useful in the othe= r APIs. >>=20 >> I'd therefore suggest making loop detection a general requirement (SHOUL= D) and any more specific requirements (e.g. R33) under the specific API the= y apply to. >>=20 > I think the requirement is stronger: CDNs need to agree on a common mecha= nism for loop detection; I agree it is a MUST (as along as "cascaded CDNs" are supported). In the Requirements I-D it was presented: * as a "MUST" for longer term * as a "SHOULD" for shorter term, because support of cascaded CDNs itself = is only listed as a SHOULD for the shorter term (on the grounds that not su= pporting it may potentially allow definition of a simpler solution faster) I think we could either: *A*: * agree right now that the shorter term solution (ie within initial charte= r scope) MUST support cascaded CDNs * include a MUST requirement for loop prevention in the Generic Reqts sect= ion and possibly in each API specific section (Control, Request-Routing, Me= tadata)=20 *B: * defer the decision about support of cascaded CDNs in shorter term (ie wi= thin initial charter scope) to further discussions * include a "conditional" MUST (ie "if cascaded CDNs are supported,...") i= n the Generic Reqts section and possibly in each API specific section (Cont= rol, Request-Routing, Metadata)=20 I would vote for *A* because: * we wouldn't want to go for a shorter term solution that cannot be easily= extended to support cascaded CDNs * there are short term use cases for cascaded CDNs. other voters? Thanks Francois > otherwise you can get multiplicative loop diameters and effectively not h= ave useful loop detection when the non-looping paths are long. This is rout= ing; we know what happens when you do loop detect with thing like count-to-= infinity. >=20 > Incidently, my favorite loop detection scheme was invented by Knuth all t= he way back in volume 2. It has the nice property of detecting loops in con= stant memory and with an upper bound of traversing the loop 2 times, for al= l loop diameters. Look it up - it's called the "even-odd iteration counting= ". >=20 > DaveO. >=20 >=20 >> Thanks >> Ben >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Feb 3 02:25:12 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF3C3A68F9 for ; Thu, 3 Feb 2011 02:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.938 X-Spam-Level: X-Spam-Status: No, score=-8.938 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbfmRir8nGKR for ; Thu, 3 Feb 2011 02:25:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2E4433A68F1 for ; Thu, 3 Feb 2011 02:25:09 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg, green.gif : 11041, 87 Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2011 10:28:30 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p13ASOqq026657; Thu, 3 Feb 2011 10:28:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-446-594155134 From: Francois Le Faucheur In-Reply-To: <9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> Date: Thu, 3 Feb 2011 11:28:54 +0100 Message-Id: References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> <4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com> <9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1082) Cc: mvittal@cisco.com, cdni@ietf.org, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 10:25:12 -0000 --Apple-Mail-446-594155134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Phil, On 3 Feb 2011, at 11:18, wrote: > Cascaded CDNs would be nice.=20 >=20 > Cascading is missing from the logging section - where it seems hard. = 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. There are requirements in the Security section that relate to that: " R71 The CDNI solution MUST be able to ensure that for any given request redirected to a Downstream CDN, the chain of CDN Delegation (leading to that request being served by that CDN) can be established with non-repudiation. 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. " This is meant to apply also to the Logging API. Is that sufficient to capture the topic or do you want to see a specific = requirement under the "Logging API" section? > This is quite challenging, especially if one allows any flexibility = over what is reported, format of reports, security methods, real-time = reports, etc.=20 >=20 > Agree that cascading should be mentioned as a generic requirement - = and we treat it at the same requirements level for all the APIs (whether = that's: MUST in initial scope, SHOULD, or beyond initial scope). >=20 > Personally think there is quite a lot "within initial scope" in the = requirements draft, and cascading might be deferrable if it adds = significant work to standardising the APIs - as most of the value of CDN = interconnect seems to come from the "one hop" case ie: > CSP -> Upstream CDN -> Downstream CDN -> UA I take this as a "B" Vote. Thanks Francois >=20 >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur > Sent: 02 February 2011 10:45 > To: David R Oran > Cc: cdni@ietf.org; Viveganandhan Mahesh; Yiu Lee > Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI = Requirements I-D >=20 > Dave and all, >=20 > On 2 Feb 2011, at 01:53, David R Oran wrote: >=20 >>=20 >> On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: >>=20 >>> Francois, >>>=20 >>> On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote: >>>> This discussion drifted from (i) the ability to limit the number of = CDN redirections (for the sake of avoiding degradation of user = experience) into a discussion on (ii) preventing loops in request = touting and other information exchange. >>>>=20 >>>=20 >>> That's my fault because I wasn't distinguishing between loop = detection of CDN redirections and other types of loop detection. >>>=20 >>>> (i) is addressed in: >>>> " >>>> R34 The CDNI Request-Routing API SHOULD support optional = enforcement >>>> of a limit on the number of successive CDN redirections for a >>>> given request. >>>> " >>>>=20 >>>> (ii) is currently addressed in : >>>>=20 >>>> 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). >>>>=20 >>>> 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). >>>>=20 >>>> (as well as R39 and R40 for longer term) >>>>=20 >>>> R55 If cascaded CDNs are supported by the CDNI solution, the CDNI >>>> Metadata API MUST prevent looping of CDNI Metadata distribution >>>> across CDNs. >>>>=20 >>>> Do you guys still think something is missing? >>>> Can you suggest something to cover missing bits? >>>>=20 >>>=20 >>> For CDNI Request Routing the above is fine. What I'm saying is I = think loop detection also applies to the control API and may be useful = in the other APIs. >>>=20 >>> I'd therefore suggest making loop detection a general requirement = (SHOULD) and any more specific requirements (e.g. R33) under the = specific API they apply to. >>>=20 >> I think the requirement is stronger: CDNs need to agree on a common = mechanism for loop detection; >=20 > I agree it is a MUST (as along as "cascaded CDNs" are supported). > In the Requirements I-D it was presented: > * as a "MUST" for longer term > * as a "SHOULD" for shorter term, because support of cascaded = CDNs itself is only listed as a SHOULD for the shorter term (on the = grounds that not supporting it may potentially allow definition of a = simpler solution faster) >=20 > I think we could either: >=20 > *A*: > * agree right now that the shorter term solution (ie within = initial charter scope) MUST support cascaded CDNs > * include a MUST requirement for loop prevention in the Generic = Reqts section and possibly in each API specific section (Control, = Request-Routing, Metadata)=20 >=20 > *B: > * defer the decision about support of cascaded CDNs in shorter = term (ie within initial charter scope) to further discussions > * include a "conditional" MUST (ie "if cascaded CDNs are = supported,...") in the Generic Reqts section and possibly in each API = specific section (Control, Request-Routing, Metadata)=20 >=20 > I would vote for *A* because: > * we wouldn't want to go for a shorter term solution that cannot = be easily extended to support cascaded CDNs > * there are short term use cases for cascaded CDNs. >=20 > other voters? >=20 > Thanks >=20 > Francois >=20 >> otherwise you can get multiplicative loop diameters and effectively = not have useful loop detection when the non-looping paths are long. This = is routing; we know what happens when you do loop detect with thing like = count-to-infinity. >>=20 >> Incidently, my favorite loop detection scheme was invented by Knuth = all the way back in volume 2. It has the nice property of detecting = loops in constant memory and with an upper bound of traversing the loop = 2 times, for all loop diameters. Look it up - it's called the "even-odd = iteration counting". >>=20 >> DaveO. >>=20 >>=20 >>> Thanks >>> Ben >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com 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 =20 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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 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 --Apple-Mail-446-594155134 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-447-594155134 --Apple-Mail-447-594155134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Phil,

On 3 Feb 2011, at 11:18, <philip.eardley@bt.com> = wrote:

Cascaded CDNs would be nice.

Cascading is = missing from the logging section - where it seems hard. 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.

There are requirements in = the Security section that relate to = that:

"
   R71 =  The CDNI solution MUST be able to ensure that for any = given
        request redirected to a = Downstream CDN, the chain of CDN
       =  Delegation (leading to that request being served by that = CDN)
        can be established with = non-repudiation.

   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.
"

This is meant to apply also to = the Logging API.
Is that sufficient to capture the topic or do = you want to see a specific requirement under the "Logging API" = section?


= This is quite challenging, especially if one allows any flexibility over = what is reported, format of reports, security methods, real-time = reports, etc.

Agree that = cascading should be mentioned as a generic requirement - and we treat it = at the same requirements level for all the APIs (whether that's: MUST in = initial scope, SHOULD, or beyond initial scope).

Personally think = there is quite a lot "within initial scope" in the requirements draft, = and cascading might be deferrable if it adds significant work to = standardising the APIs - as most of the value of CDN interconnect seems = to come from the "one hop" case ie:
CSP -> Upstream CDN -> = Downstream CDN -> UA

I take = this as a "B" = Vote.

Thanks

Francois


-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le = Faucheur
Sent: 02 February 2011 10:45
To: David R Oran
Cc: cdni@ietf.org; Viveganandhan Mahesh; = Yiu Lee
Subject: Re: [CDNi] Limit nb of redirects & loop sRe: = CDNI Requirements I-D

Dave and all,

On 2 Feb 2011, at = 01:53, David R Oran wrote:


On Feb 1, 2011, = at 2:25 PM, Ben Niven-Jenkins wrote:

Francois,

On 1 Feb 2011, at 19:00, = Francois Le Faucheur wrote:
This = discussion drifted from (i) the ability to limit the number of CDN = redirections (for the sake of avoiding degradation of user experience) = into a discussion on (ii) preventing loops in request touting and other = information = exchange.


That's my fault because I wasn't = distinguishing between loop detection of CDN redirections and other = types of loop detection.

(i) is = addressed in:
"
R34 =  The CDNI Request-Routing API SHOULD support optional = enforcement
=     of a limit on the number of successive CDN = redirections for a
=     given = request.
"

(ii) = is currently addressed in = :

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).

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).

(as = well as R39 and R40 for longer = term)

R55 =  If cascaded CDNs are supported by the CDNI solution, the = CDNI
=     Metadata API MUST prevent looping of CDNI = Metadata = distribution
=     across = CDNs.

Do you = guys still think something is = missing?
Can = you suggest something to cover missing = bits?


For CDNI Request Routing the = above is fine. What I'm saying is I think loop detection also applies to = the control API and may be useful in the other = APIs.

I'd therefore suggest making = loop detection a general requirement (SHOULD) and any more specific = requirements (e.g. R33) under the specific API they apply = to.

I = think the requirement is stronger: CDNs need to agree on a common = mechanism for loop detection;

I agree it is a MUST = (as along as "cascaded CDNs" are supported).
In the Requirements I-D = it was presented:
* as a "MUST" for longer = term
= * as a "SHOULD" for shorter term, because support of cascaded = CDNs itself is only listed as a SHOULD for the shorter term (on the = grounds that not supporting it may potentially allow definition of a = simpler solution faster)

I think we could = either:

*A*:
* agree right now that the = shorter term solution (ie within initial charter scope) MUST support = cascaded CDNs
= * include a MUST requirement for loop prevention in the = Generic Reqts section and possibly in each API specific section = (Control, Request-Routing, Metadata)

*B:
* defer = the decision about support of cascaded CDNs in shorter term (ie within = initial charter scope) to further discussions
* include = a "conditional" MUST (ie "if cascaded CDNs are supported,...") in the = Generic Reqts section and possibly in each API specific section = (Control, Request-Routing, Metadata)

I would vote for *A* = because:
= * we wouldn't want to go for a shorter term solution that cannot = be easily extended to support cascaded CDNs
* there = are short term use cases for cascaded CDNs.

other = voters?

Thanks

Francois

otherwise you can get multiplicative loop diameters and = effectively not have useful loop detection when the non-looping paths = are long. This is routing; we know what happens when you do loop detect = with thing like count-to-infinity.

Incidently, my = favorite loop detection scheme was invented by Knuth all the way back in = volume 2. It has the nice property of detecting loops in constant memory = and with an upper bound of traversing the loop 2 times, for all loop = diameters. Look it up - it's called the "even-odd iteration = counting".

DaveO.


Thanks
Ben


_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

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

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-447-594155134 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-447-594155134-- --Apple-Mail-446-594155134-- From flefauch@cisco.com Thu Feb 3 02:44:10 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF1D3A68FA for ; Thu, 3 Feb 2011 02:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.528 X-Spam-Level: X-Spam-Status: No, score=-9.528 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+wlVn6G90Zy for ; Thu, 3 Feb 2011 02:44:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 287643A68F6 for ; Thu, 3 Feb 2011 02:44:06 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg, green.gif : 11041, 87 Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2011 10:47:27 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p13AlOgg008763; Thu, 3 Feb 2011 10:47:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-475-595294806 From: Francois Le Faucheur In-Reply-To: <55711E30-4BFA-4749-9EAA-9EBF725BC1FF@cisco.com> Date: Thu, 3 Feb 2011 11:47:54 +0100 Message-Id: References: <55711E30-4BFA-4749-9EAA-9EBF725BC1FF@cisco.com> To: David R Oran X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" , "Lee, Yiu" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 10:44:10 -0000 --Apple-Mail-475-595294806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 David, Yiu, On 3 Feb 2011, at 00:29, David R Oran wrote: >=20 > On Feb 2, 2011, at 1:28 PM, Lee, Yiu wrote: >=20 >> Hi Dave, >>=20 >> Let me clarify what I try to say. In the current requirement draft, = we >> specifically gave example to include IP address. This is why Dan = replied >> warning us this would break NAT64. IMHO, we should remove those = examples >> to have IP address. I am ok with your suggestion (ie third-party >> reference), but I would like to give some examples such as FQDN, URN, = etc >> and remove IP address from the current example. >>=20 > I agree that giving examples of problematic URI forms, including those = that cause third-party reference problems, would be a good addition to = the document. I have the impression you two are talking slightly past each other = (unless it is me that is past the two of you). I believe Yiu is making the point that the current Requirements document = includes an example of IP address being used as a reference (Yiu, I = assume you refer to R35 in particular?). This was intended to be a = positive example, so it now seems like a real bad example and should be = changed to a better example (eg FQDN). I believe David is making the point that, alongside the new requirement = to be added along the lines of ... the CDNI solution MUST "only use = URI's that work as third-party references", it would be useful to = provide an example of what is a broken 3rd party reference (eg because = it is based on IP address). If I got this right, both points seem valid. David, is there some document that can be referenced to help folks = understand what it means "to work as a third-party reference"? Thanks Francois > I myself was remiss in being so terse and not giving examples myself = in my email. >=20 > Thanks for the thoughtful reply. >=20 > I was mostly aiming at ensuring that we didn't just laser-focus on IP = addresses as problematic in URIs since sometimes they are and sometimes = they aren't. Just banning IP addresses from URIs used in CDNi is = attacking only one manifestation of the problem >=20 > Incidentally, a good example of where FQDNs can also go astray is the = split-DNS situation I previously alluded to. When you have split DNS, = servers in one domain may return different results from servers in other = domains, or potentially fail to return any useful results. This may in = fact be a real problem in CDNi situations as service providers (and = sometimes enterprises as well) are sometimes enticed by the supposed = benefits of using split-DNS techniques to hide the names of internal = resources. Another example I might raise (with some trepidation) is = "carrier ENUM" where the DNS FQDNs for phone numbers resolve differently = (or not at all) in different SP networks. >=20 > DaveO >=20 >=20 >=20 >> Cheers, >> Yiu >>=20 >>=20 >> On 2/2/11 9:49 AM, "David R Oran" wrote: >>=20 >>>=20 >>> On Feb 1, 2011, at 11:32 PM, Lee, Yiu wrote: >>>=20 >>>> Agreed and we didn't write a requirement that would lead to any = specific >>>> technology. All we are saying is that the the Content-Location = would >>>> contain FQDN. That's it. >>>>=20 >>> I don't follow your reasoning. Saying that is neither necessary = (since in >>> many cases addresses will work), nor sufficient (because in a number = of >>> cases like split DNS an FQDN will not work). >>>=20 >>> I think the requirement is that "people only use URI's that work as >>> third-party references". >>>=20 >>> This is a difficult area, admittedly, but writing requirements that = don't >>> capture the underlying problem to be solved isn't all that helpful = since >>> in hindsight people will inevitably forget why the requirement = existed. >>>=20 >>> Now, if you want to mandate only FQDNs for some other reason that's = fine, >>> but do you want to close the door to someday having a CDN-friendly = URNs >>> instead of URIs anyway. >>>=20 >>> DaveO. >>>=20 >>>> On 2/1/11 7:47 PM, "David R Oran" wrote: >>>>=20 >>>>> Isn't this a special case of the general 3rd party referral = problem? >>>>> Why >>>>> are you writing CDNi-specific requirements? Shouldn't you just say = "CDN >>>>> interconnection requires third party references and hence depends = on >>>>> mechanisms for the handling of such in URI's for a number of cases >>>>> involving NATs, V4/V6 tunnels, and other scenarios that cause = problems >>>>> with third party references". >>>>>=20 >>>>> I would hate to see a requirement that led to a custom solution = for CDN >>>>> interconnection that didn't work for any old style of redirection. >>>>>=20 >>>>> If IP address literals cause third-party breakage, just banning = them >>>>> will >>>>> only mask problems when people add further breakage like split = DNS. >>>>>=20 >>>>> DaveO >>>>>=20 >>>>> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >>>>>=20 >>>>>>=20 >>>>>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>>>>>=20 >>>>>>> Hi Ben, >>>>>>>=20 >>>>>>> Thanks for thinking through this. My concern was U2 should put = the IP >>>>>>> in >>>>>>> the URL but it wouldn=B9t happen. This is fine. I agree that if = we use >>>>>>> the >>>>>>> FQDN in the redirect, CDN2 will stream the content to U2 in = native v6 >>>>>>> if >>>>>>> the CDN2 supports v6. >>>>>>=20 >>>>>> So we should add a requirement along the lines of the one you >>>>>> discussed >>>>>> earlier with Dan: >>>>>>=20 >>>>>>> I would propose adding a general requirement to the document = stating >>>>>>> "any >>>>>>> URIs returned to User Agents MUST NOT contain IP address = literals in >>>>>>> the >>>>>>> component of the URI" or similar text. >>>>>>=20 >>>>>> Right? >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>>=20 >>>>>>> Yiu >>>>>>>=20 >>>>>>>>=20 >>>>>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. = That is >>>>>>>> not >>>>>>>> the issue. The issue is that NAT64 relies on the NAT64 device >>>>>>>> synthesising >>>>>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an = v4 >>>>>>>> address >>>>>>>> literal in the Content-Location header of a HTTP 302 it has no = way >>>>>>>> to >>>>>>>> communicate with that v4 address as it has no native v4 = capability >>>>>>>> (or no >>>>>>>> native v4 routing). >>>>>>>>=20 >>>>>>>> Using a FQDN (and avoiding v4 address literals) in the >>>>>>>> Content-Location >>>>>>>> header would avoid the issue as you first suggested. >>>>>>>>=20 >>>>>>>> Ben >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>> >>>>>>=20 >>>>>> Francois Le Faucheur >>>>>> Distinguished Engineer >>>>>> Corporate Development >>>>>> flefauch@cisco.com >>>>>> Phone: +33 49 723 2619 >>>>>> Mobile: +33 6 19 98 50 90 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cisco Systems France >>>>>> Greenside >>>>>> 400 Ave de Roumanille >>>>>> 06410 Sophia Antipolis >>>>>> France >>>>>> Cisco.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> >>>>>> Think before you print. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, = Rue Camille >>>>>> Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les >>>>>> Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, >>>>>> Directeur >>>>>> de la publication: Jean-Luc Michel Givone. >>>>>>=20 >>>>>> For corporate legal information go to: >>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>=20 >>=20 >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com 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 =20 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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 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 --Apple-Mail-475-595294806 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-476-595294807 --Apple-Mail-476-595294807 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Feb 2, 2011, at 1:28 PM, Lee, Yiu = wrote:

Hi = Dave,

Let me clarify = what I try to say. In the current requirement draft, = we
specifically gave example = to include IP address. This is why Dan = replied
warning us this would = break NAT64. IMHO, we should remove those = examples
to have IP address. I = am ok with your suggestion (ie third-party
reference), but I would like to give some examples such as = FQDN, URN, etc
and remove IP = address from the current example.

I agree that giving examples of = problematic URI forms, including those that cause third-party reference = problems, would be a good addition to the document. =

I have the impression you two are = talking slightly past each other (unless it is me that is past the two = of you).

I believe Yiu is making the point that = the current Requirements document includes an example of IP address = being used as a reference (Yiu, I assume you refer to R35 in = particular?). This was intended to be a positive example, so it now = seems like a real bad example and should be changed to a better example = (eg FQDN).

I believe David is making the point = that, alongside the new requirement to be added along the lines of ... = the CDNI solution MUST "only use URI's that work = as third-party references", it would be useful to provide an = example of what is a broken 3rd party reference (eg because it is based = on IP address).

If I got this right, both = points seem valid.

David, is there some = document that can be referenced to help folks understand what it means = "to work as a third-party = reference"?

Thanks

Franc= ois


I myself was = remiss in being so terse and not giving examples myself in my = email.

Thanks for the thoughtful reply.

I was mostly = aiming at ensuring that we didn't just laser-focus on IP addresses as = problematic in URIs since sometimes they are and sometimes they aren't. = Just banning IP addresses from URIs used in CDNi is attacking only one = manifestation of the problem

Incidentally, a good example of = where FQDNs can also go astray is the split-DNS situation I previously = alluded to. When you have split DNS, servers in one domain may return = different results from servers in other domains, or potentially fail to = return any useful results. This may in fact be a real problem in CDNi = situations as service providers (and sometimes enterprises as well) are = sometimes enticed by the supposed benefits of using split-DNS techniques = to hide the names of internal resources. Another example I might raise = (with some trepidation) is "carrier ENUM" where the DNS FQDNs for phone = numbers resolve differently (or not at all) in different SP = networks.

DaveO



Cheers,
Yiu


On 2/2/11 9:49 = AM, "David R Oran" <oran@cisco.com> = wrote:


On Feb 1, 2011, at 11:32 PM, = Lee, Yiu wrote:

Agreed = and we didn't write a requirement that would lead to any = specific
technology. All we are saying is that the the = Content-Location = would
contain = FQDN. That's it.

I don't follow your reasoning. = Saying that is neither necessary (since = in
many cases addresses will work), nor sufficient (because = in a number of
cases like split DNS an FQDN = will not work).

I think the requirement is that = "people only use URI's that work = as
third-party = references".

This is a difficult area, = admittedly, but writing requirements that = don't
capture the underlying problem to be solved isn't all that = helpful since
in hindsight people will = inevitably forget why the requirement = existed.

Now, if you want to mandate only = FQDNs for some other reason that's = fine,
but do you want to close the door to someday having a = CDN-friendly URNs
instead of URIs = anyway.

DaveO.

On = 2/1/11 7:47 PM, "David R Oran" <oran@cisco.com> = wrote:

Isn't this a special case of the = general 3rd party referral = problem?
Why
<= blockquote type=3D"cite">
are you writing CDNi-specific = requirements? Shouldn't you just say = "CDN
interconnection requires third = party references and hence depends = on
mechanisms for the handling of = such in URI's for a number of = cases
involving NATs, V4/V6 tunnels, = and other scenarios that cause = problems
with third party = references".

I would hate to see a = requirement that led to a custom solution for = CDN
interconnection that didn't work = for any old style of = redirection.

If IP address literals cause = third-party breakage, just banning = them
will
=
only mask problems when people = add further breakage like split = DNS.

DaveO

On Feb 1, 2011, at 2:06 PM, = Francois Le Faucheur = wrote:


On 1 = Feb 2011, at 19:58, Lee, Yiu = wrote:

Hi = Ben,
<= /blockquote>

Thanks = for thinking through this. My concern was U2 should put the = IP
in
the = URL but it wouldn=B9t happen. This is fine. I agree that if we = use
the
<= /blockquote>
FQDN = in the redirect, CDN2 will stream the content to U2 in native = v6
if
the = CDN2 supports = v6.

So we = should add a requirement along the lines of the one = you
discussed
earlier with = Dan:
<= blockquote type=3D"cite">

I would propose adding a general = requirement to the document = stating
"any
=
URIs = returned to User Agents MUST NOT contain IP address literals = in
the
<= /blockquote>
<authority> component of the URI" or similar = text.
=

Right?

Francois


Yiu
<= /blockquote>


U2 is behind NAT64 so CDN1 will = see an IPv4 address for U2. That = is
not
<= /blockquote>
the = issue. The issue is that NAT64 relies on the NAT64 = device
synthesising
AAAA = DNS responses as U2 only speaks DNSv6. But if U2 gets an = v4
address
literal = in the Content-Location header of a HTTP 302 it has no = way
to
communicate with that v4 address = as it has no native v4 = capability
(or = no
native v4 = routing).

Using a FQDN (and avoiding v4 = address literals) in = the
Content-Location
<= /blockquote>
header = would avoid the issue as you first = suggested.

Ben
<= /blockquote>


_______________________________________________
CDNi mailing = list
<= /blockquote>
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

<image001.jpg>

Francois= Le = Faucheur
Distinguished = Engineer
Corporate = Development
flefauch@cisco.com
=
Phone: = +33 49 723 = 2619
<= blockquote type=3D"cite">
Mobile: = +33 6 19 98 50 = 90



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




<green.gif>
=
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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille
Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 = Issy = les
Moulineaux, Au capital de 91.470 =80, 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


_______________________________________________
CDNi = mailing = list
<= blockquote type=3D"cite">
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni







Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

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

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-476-595294807 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-476-595294807-- --Apple-Mail-475-595294806-- From oran@cisco.com Thu Feb 3 04:21:15 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE08F3A6960 for ; Thu, 3 Feb 2011 04:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.357 X-Spam-Level: X-Spam-Status: No, score=-110.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBw44yZaxLRg for ; Thu, 3 Feb 2011 04:21:13 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DB47F3A695C for ; Thu, 3 Feb 2011 04:21:13 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2011 12:24:36 +0000 Received: from sjc-vpnasa-325.cisco.com (sjc-vpnasa-325.cisco.com [10.21.105.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13COZkj002940; Thu, 3 Feb 2011 12:24:35 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: Date: Thu, 3 Feb 2011 07:24:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55711E30-4BFA-4749-9EAA-9EBF725BC1FF@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1082) Cc: "cdni@ietf.org" , "Lee, Yiu" Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 12:21:16 -0000 On Feb 3, 2011, at 5:47 AM, Francois Le Faucheur wrote: > David, Yiu, >=20 > On 3 Feb 2011, at 00:29, David R Oran wrote: >=20 >>=20 >> On Feb 2, 2011, at 1:28 PM, Lee, Yiu wrote: >>=20 >>> Hi Dave, >>>=20 >>> Let me clarify what I try to say. In the current requirement draft, = we >>> specifically gave example to include IP address. This is why Dan = replied >>> warning us this would break NAT64. IMHO, we should remove those = examples >>> to have IP address. I am ok with your suggestion (ie third-party >>> reference), but I would like to give some examples such as FQDN, = URN, etc >>> and remove IP address from the current example. >>>=20 >> I agree that giving examples of problematic URI forms, including = those that cause third-party reference problems, would be a good = addition to the document. >=20 > I have the impression you two are talking slightly past each other = (unless it is me that is past the two of you). >=20 > I believe Yiu is making the point that the current Requirements = document includes an example of IP address being used as a reference = (Yiu, I assume you refer to R35 in particular?). This was intended to be = a positive example, so it now seems like a real bad example and should = be changed to a better example (eg FQDN). >=20 Ok. > I believe David is making the point that, alongside the new = requirement to be added along the lines of ... the CDNI solution MUST = "only use URI's that work as third-party references", it would be useful = to provide an example of what is a broken 3rd party reference (eg = because it is based on IP address). >=20 Yes. > If I got this right, both points seem valid. >=20 Yes. > David, is there some document that can be referenced to help folks = understand what it means "to work as a third-party reference"? >=20 I've never seen this all gathered up in one place, aside from even more = general architecture papers that talk about "transparency" and = "end-to-end". If the net were transparent as it's original architects = envisioned then we would not be having this discussion because = third-party references, using either addresses or names, would always = work. I'll ask around though. > Thanks >=20 > Francois >=20 >=20 >> I myself was remiss in being so terse and not giving examples myself = in my email. >>=20 >> Thanks for the thoughtful reply. >>=20 >> I was mostly aiming at ensuring that we didn't just laser-focus on IP = addresses as problematic in URIs since sometimes they are and sometimes = they aren't. Just banning IP addresses from URIs used in CDNi is = attacking only one manifestation of the problem >>=20 >> Incidentally, a good example of where FQDNs can also go astray is the = split-DNS situation I previously alluded to. When you have split DNS, = servers in one domain may return different results from servers in other = domains, or potentially fail to return any useful results. This may in = fact be a real problem in CDNi situations as service providers (and = sometimes enterprises as well) are sometimes enticed by the supposed = benefits of using split-DNS techniques to hide the names of internal = resources. Another example I might raise (with some trepidation) is = "carrier ENUM" where the DNS FQDNs for phone numbers resolve differently = (or not at all) in different SP networks. >>=20 >> DaveO >>=20 >>=20 >>=20 >>> Cheers, >>> Yiu >>>=20 >>>=20 >>> On 2/2/11 9:49 AM, "David R Oran" wrote: >>>=20 >>>>=20 >>>> On Feb 1, 2011, at 11:32 PM, Lee, Yiu wrote: >>>>=20 >>>>> Agreed and we didn't write a requirement that would lead to any = specific >>>>> technology. All we are saying is that the the Content-Location = would >>>>> contain FQDN. That's it. >>>>>=20 >>>> I don't follow your reasoning. Saying that is neither necessary = (since in >>>> many cases addresses will work), nor sufficient (because in a = number of >>>> cases like split DNS an FQDN will not work). >>>>=20 >>>> I think the requirement is that "people only use URI's that work as >>>> third-party references". >>>>=20 >>>> This is a difficult area, admittedly, but writing requirements that = don't >>>> capture the underlying problem to be solved isn't all that helpful = since >>>> in hindsight people will inevitably forget why the requirement = existed. >>>>=20 >>>> Now, if you want to mandate only FQDNs for some other reason that's = fine, >>>> but do you want to close the door to someday having a CDN-friendly = URNs >>>> instead of URIs anyway. >>>>=20 >>>> DaveO. >>>>=20 >>>>> On 2/1/11 7:47 PM, "David R Oran" wrote: >>>>>=20 >>>>>> Isn't this a special case of the general 3rd party referral = problem? >>>>>> Why >>>>>> are you writing CDNi-specific requirements? Shouldn't you just = say "CDN >>>>>> interconnection requires third party references and hence depends = on >>>>>> mechanisms for the handling of such in URI's for a number of = cases >>>>>> involving NATs, V4/V6 tunnels, and other scenarios that cause = problems >>>>>> with third party references". >>>>>>=20 >>>>>> I would hate to see a requirement that led to a custom solution = for CDN >>>>>> interconnection that didn't work for any old style of = redirection. >>>>>>=20 >>>>>> If IP address literals cause third-party breakage, just banning = them >>>>>> will >>>>>> only mask problems when people add further breakage like split = DNS. >>>>>>=20 >>>>>> DaveO >>>>>>=20 >>>>>> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>>>>>>=20 >>>>>>>> Hi Ben, >>>>>>>>=20 >>>>>>>> Thanks for thinking through this. My concern was U2 should put = the IP >>>>>>>> in >>>>>>>> the URL but it wouldn=B9t happen. This is fine. I agree that if = we use >>>>>>>> the >>>>>>>> FQDN in the redirect, CDN2 will stream the content to U2 in = native v6 >>>>>>>> if >>>>>>>> the CDN2 supports v6. >>>>>>>=20 >>>>>>> So we should add a requirement along the lines of the one you >>>>>>> discussed >>>>>>> earlier with Dan: >>>>>>>=20 >>>>>>>> I would propose adding a general requirement to the document = stating >>>>>>>> "any >>>>>>>> URIs returned to User Agents MUST NOT contain IP address = literals in >>>>>>>> the >>>>>>>> component of the URI" or similar text. >>>>>>>=20 >>>>>>> Right? >>>>>>>=20 >>>>>>> Francois >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Yiu >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. = That is >>>>>>>>> not >>>>>>>>> the issue. The issue is that NAT64 relies on the NAT64 device >>>>>>>>> synthesising >>>>>>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an = v4 >>>>>>>>> address >>>>>>>>> literal in the Content-Location header of a HTTP 302 it has no = way >>>>>>>>> to >>>>>>>>> communicate with that v4 address as it has no native v4 = capability >>>>>>>>> (or no >>>>>>>>> native v4 routing). >>>>>>>>>=20 >>>>>>>>> Using a FQDN (and avoiding v4 address literals) in the >>>>>>>>> Content-Location >>>>>>>>> header would avoid the issue as you first suggested. >>>>>>>>>=20 >>>>>>>>> Ben >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> Francois Le Faucheur >>>>>>> Distinguished Engineer >>>>>>> Corporate Development >>>>>>> flefauch@cisco.com >>>>>>> Phone: +33 49 723 2619 >>>>>>> Mobile: +33 6 19 98 50 90 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Cisco Systems France >>>>>>> Greenside >>>>>>> 400 Ave de Roumanille >>>>>>> 06410 Sophia Antipolis >>>>>>> France >>>>>>> Cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> >>>>>>> Think before you print. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, = Rue Camille >>>>>>> Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les >>>>>>> Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, >>>>>>> Directeur >>>>>>> de la publication: Jean-Luc Michel Givone. >>>>>>>=20 >>>>>>> For corporate legal information go to: >>>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > >=20 > Francois Le Faucheur > Distinguished Engineer > Corporate Development > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 >=20 > =20 >=20 > > Think before you print. >=20 > 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. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 From philip.eardley@bt.com Thu Feb 3 06:55:14 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFBE3A6980 for ; Thu, 3 Feb 2011 06:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ8fHKtFBKWD for ; Thu, 3 Feb 2011 06:54:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 7E8943A699E for ; Thu, 3 Feb 2011 06:54:52 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 3 Feb 2011 14:58:13 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.92]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 3 Feb 2011 14:58:14 +0000 From: To: Date: Thu, 3 Feb 2011 14:58:10 +0000 Thread-Topic: Comments on CDNI Requirements Thread-Index: AcvDssZURaxGNS2bSmSDJwDl0JCxfA== Message-ID: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F327828C214EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [CDNi] Comments on CDNI Requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:55:14 -0000 --_000_9510D26531EF184D9017DF24659BB87F327828C214EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are some comments on the requirements doc. http://tools.ietf.org/html/= draft-lefaucheur-cdni-requirements-00 It looks good. Although it is quite detailed at this stage - for example th= e draft Charter will be much less detailed (presumably) - it is a good idea= to start more detailed thinking already. 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, eit= her about whether it definitely is needed &/or about whether it's too trick= y for the protocol to achieve during the phase covered by the initial chart= er. 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. R2 MUST not =3D> MUST NOT 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 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) 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 w= here route requests are not cascaded. The question is whether route request= s 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= " 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 kno= wing 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 t= his in the requirement. 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 =3D> its 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 abili= ty to access the content, or whether some CSP want the actual bits to be re= moved. R20, 21, 22 Rather than repeating the entire text from R13-R15, think it would be bette= r to say something like: R13 upgrades from a SHOULD to a MUST This would help the reader understand the deltas. R23 virtual Downstream CDN =3D> virtual Downstream CDNs note, we have an open issue on the Use Cases draft to add some discussion a= bout virtualisation and about different sorts of Wholesaler model. discuss = separately. 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= - 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. 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 c= ould be removed with a good definition in another draft. There is a "starte= r 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 ro= uting and iterative request routing. The key difference seems to be that in the Iterative case the request routi= ng reply comes back to the UA, which then sends out another request to anot= her CDN which replies to the UA with the surrogate's address. Whereas in th= e Recursive case the UA sends the request to CDN-A, & CDN-A replies with th= e surrogate's address (in the meantime CDN-A sends a request to CDN-B which= replies to CDN-A with the surrogate's address). Note that the text in R30 = seems to describe the iterative case, & R31 the recursive one. 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. It may be worth adding to R37, as examples of the error code, the ex= amples in R38, "by which a Downstream CDN can notify the Upstream CDN when = it is unable or unwilling to serve a request" R42 to R46 Agree that these need some work. The approach suggested (during the Ben /Francois discussion) of a Trigger s= eems 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-position= ing (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: <> split in two: Rx1 about triggering for content and Rx2 about triggering for= CNDI Metadata <> the Metadata API only needs to support dynamic acquisition, ie a request-re= sponse; pre-positioning is achieved by the CDN Control API trigger triggeri= ng the Metadata API. So suggest both of these are replaced by: Rx: The CDNI Metadata API MUST support a model where the Downstream CDN req= uests content distribution metadata and the Upstream CDN replies with the C= DNI 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 com= municated to the Downstream CDN"). Open for discussion about R44 ("no, or a subset of, the Metadata is initial= ly communicated to the Downstream CDN along with information about how/wher= e 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 m= odel, the CDNI Metadata API MUST provide the necessary information to allow= the Downstream CDN to acquire the content from an upstream source (e.g. Ac= quisition protocol and Uniform Resource Identifier in Upstream CDN- or rule= s 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. N= ote 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 i= s 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 require= ment on the protocol itself, not so much how an implementation must/should/= may use the protocol knobs). >> 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 whic= h the downstream CDN may be able to get content Rx - it seems unrealistic to try to force a guarantee that the source is wi= lling to serve the content to this downstream CDN, as this is about busines= s practices. Delete Rx. Ry: <> - 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. =3D> The CDNI Metadata API MUST allow the Upstream CDN to request the addit= ion 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 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. An alternative (which we don't think is a good idea) would be to keep all t= he CDNI Metadata in sync, signed tokens etc. So:- R52 The CDNI Metadata API MUST provide an acknowledgement by the Downst= ream CDN to the Upstream CDN of the CDNI Metadata request, which potenti= ally 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: =3D> The CDNI Metadata API MUST... Same comment for R54, R57 Possibly you could add "(of the content)" at the end of the first sentence = (ie policies about distribution of the content & not distribution of the CD= NI 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. 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. 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 i= nfo 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 he= ar views), and doesn't mean [3]. [We think.] 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 - whi= ch is too detailed for a MUST. Guess we want a count of how many times cont= ent has been delivered to UA(s). 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. It might be possible to merge R60-63: Rx The CDNI Logging API MUST provide logging of how many times the Down= stream CDN has delivered a piece of content to User Agents as a result of r= equest redirection by the Upstream CDN, or has distributed a piece of conte= nt to a Downstream CDN. Delivery of the logging message MUST be reliable an= d non-repudiable. Rx - within initial scope: The CDNI Logging API MUST provide control over what is in the logging recor= ds, 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 intere= st (eg these particular objects or object sets) and where to send the recor= ds to (different reports might go to different end points, eg report everyt= hing 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 sh= ould be some control over what's in the logging records. 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 loggi= ng record as i have lost it") Missing from the logging section is that the logging record needs to includ= e (aggregated) info where content has been delivered to a UA by a CDN furth= er down a cascade of CDNs. 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, secur= ity methods, real-time reports, etc) 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 t= o 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= ..." 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 do= wnstream CDN's delivery log vs the upstream CDN's route-request log. If the= re are deltas, then have the argument. Meeting R72 would imply lots of toke= ns etc that seems over-the-top. Best wishes, Trevor & Phil --_000_9510D26531EF184D9017DF24659BB87F327828C214EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are some co= mments on the requirements doc. http://tools.ietf.org/html/draft-lefauche= ur-cdni-requirements-00

 =

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

 

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 discu= ssion is needed, either about whether it definitely is needed &/or abou= t whether it’s too tricky for the protocol to achieve during the phas= e covered by the initial charter.

MAY &= #8211; it is optional whether the WG does this. Further discussion is neede= d. But given that there are already a lot of MUSTs & SHOULDs proposed w= ithin the initial scope, the default assumption is probably that the WG won= ’t do this, unless it happens to be naturally included within somethi= ng else.

 

R2

MUST not =3D> MUST NO= T

 

  =
 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 C= DNs 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 ac=
ross CDNs based on
      =
; other protocols than HTTP.
&nbs=
p;
R4 – R7 all seem out of scope, since=
 they’re about content acquisition
 
   R8  The CDNI solution SHOULD s=
upport cascaded CDN redirection (CDN1
  &nbs=
p;    redirects to CDN2 that redirects to CDN3) to an arbitr=
ary number
       of lev=
els.
 
   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 bett=
er in the Request Routing section.
=
 
Should cascading be in initial scope?<=
o:p>
(separate discussion on ML) <=
/p>
 
Suggest m=
erge 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 reques=
ts can be cascaded down that topology
 
   R12  The CDNI Control API MUST al=
low the Downstream CDN to
    &nbs=
p;   communicate to the Upstream CDN coarse information about the=

        Downstream=
 CDN ability and/or willingness to handle requests
&nb=
sp;       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 t=
o handle requests at the moment”
<=
o:p> 
   R13  The CDNI Control API SHOULD=
 allow the Downstream CDN to
    &=
nbsp;   communicate to the Upstream CDN aggregate information on =
the
        Downstr=
eam CDN capabilities, resources and affinities (i.e.
&=
nbsp;       Preferences or cost).  This =
information can be taken into
    =
    account by the Upstream CDN Request Routing system in it=
s CDN
        Selec=
tion 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 C=
DN. So add a mention of this in the requirement. Also, it seems more logica=
l to keep the requirement here (within CDNI Control API) than move it to th=
e Request Routing API. 
 
R15 & R22
=
His =3D> its
 
   R16  The CDNI Control API MUST allow the Upstream CDN t=
o request the
      &nbs=
p; Downstream CDN (and potential cascaded Downstream CDNs - if
        cascaded CDNs are suppo=
rted by the solution) to interrupt
   &=
nbsp;    delivery of an object (or object set) and trigger s=
pecific cache
      &nbs=
p; actions or behaviors in the Downstream CDN surrogates (e.g.
        Object removal from cac=
he, revalidation).  [Editor's note: this
 &n=
bsp;      functionality is currently described in<=
o:p>
        draft-j=
enkins-cdni-problem-statement-01 under the Metadata API
        but probably fits better u=
nder the Control API].
BT (Grant) curr=
ently investigating whether it is sufficient to remove ability to access th=
e content, or whether some CSP want the actual bits to be removed. 
 
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.<=
o:p>
 
R23
virtual Downstream CDN =3D> virtual Downstream =
CDNs
 
note, we have an open=
 issue on the Use Cases draft to add some discussion about virtualisation a=
nd about different sorts of Wholesaler model. discuss separately.
 
   R28  The CDNI Req=
uest-Routing architecture and API MUST support
 &=
nbsp;      efficient request-routing for small obj=
ects.  This may, for
     &nb=
sp;  example, call for a mode of operation (e.g.  DNS-based =
request
        rou=
ting) where freshness and accuracy of CDN/Surrogate selection
        can be traded-off agains=
t reduced request-routing load (e.g.
   =
;     Via lighter-weight queries and caching of request=
-routing
        de=
cisions).
 
   R29=
  The CDNI Request-Routing architecture and API MUST support
        efficient request-ro=
uting for large objects.  This may, for
 &nb=
sp;      example, call for a mode of operation (e.=
g.  HTTP-based request
    &n=
bsp;   routing) where freshness and accuracy of CDN/Surrogate sel=
ection
        just=
ifies 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 – suggest rearrange =
as:
R28 – MUST support http-based and DNS-based =
request routing
R29 – MUST support both small &a=
mp; large objects and caching vs not-cached 
Not sure =
if R29 needs to be said explicitly?
 <=
/pre>
R28 may be worth discussing, as this might appear directly in the=
 proposed charter. Do people believe 
-    The proposed WG needs to s=
upport both http-based and DNS-based request routing
-    The propose=
d WG does NOT do any others
We think b=
oth these points are ok.
 
R30 & R31
... The CDNI Re=
quest-Routing    
   &nb=
sp;    architecture MUST support recursive request routing.<=
o:p>
... The CDNI
   &n=
bsp;    Request-Routing architecture MUST support iterative =
request
        rou=
ting.
 
There is a lot of &#=
8220;definition” text (defining Recursive & Iterative) that could=
 be removed with a good definition in another draft. There is a “star=
ter for 10” proposed definition in the Use cases draft. http://tools.ietf.o=
rg/html/draft-bertrand-cdni-use-cases . then we could have <=
/pre>
Rx: The CDNI Request-Routing architecture MUST support recursive =
request routing and iterative request routing.
&n=
bsp;
The key difference seems to be that in the Iterative c=
ase the request routing reply comes back to the UA, which then sends out an=
other request to another CDN which replies to the UA with the surrogateR=
17;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&#=
8217;s address). Note that the text in R30 seems to describe the iterative =
case, & R31 the recursive one.
 
 
   R32  The CDNI Reques=
t-Routing API SHOULD support request loop
  =
      detection and prevention (e.g.  Prevent=
 request looping in a
     &n=
bsp;  situation where CDN1 redirects to CDN2 that redirects to CDN3
        that would re=
direct 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 t=
he request (as opposed to the request loop being
 =
;       simply interrupted without routing th=
e 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 th=
e loop is effectively prevented so that the user will get the content someh=
ow.>>
Agree. Also, there are so=
me other choices – instead of the user getting the content, it may be=
 a failure msg
 
<=
p class=3DMsoPlainText>Francois comment:
<< Yes. I think R37 is more specific than R38, so I propose we re=
move R38.>>
Agree. It may be worth adding to R37, =
as examples of the error code, the examples in R38, “by which a Downs=
tream CDN can notify the Upstream CDN when it is unable or unwilling to ser=
ve a request”
 
R42 to=
 R46
Agree that these need some work. 
The approach suggested (during the Ben /Francois discussion) of a Tri=
gger 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 acquisiti=
on & pre-positioning (and adding to problem statement). There is some a=
mbiguity whether the terms apply only to content acquisition, or also to me=
tadata. As you could push the CDNI Metadata and then pull the content later=
.
 
So looking at Francois/B=
en’s revised proposal:
 
<<Rx: The CDNI Control API SHOULD support trigg=
ering and control for a pre-positioning model whereby the Upstream CDN requ=
ests the Downstream CDN to acquire content and/or associated distribution m=
etadata (and possibly position those into Downstream CDN surrogates) at an =
appropriate time (now or a specified future time), before the content is ac=
tually requested by end users. Note that the actual exchange of metadata an=
d the actual content acquisition are outside the scope of the Control API: =
those are supported, respectively, via the CDNI Metadata API and the Conten=
t Acquisition API. [Editor's Note: how much influence the Upstream CDN ough=
t to have on pre-positioning of the content on surrogates inside the Downst=
ream CDN is TBD].
>> =

 
split in two: Rx1 about triggeri=
ng for content and Rx2 about triggering for CNDI Metadata
<=
pre> 
<<Rx: The CDNI Met=
adata API MUST allow the Upstream CDN to provide the Downstream CDN with co=
ntent distribution metadata of inter-CDN scope.
 
Ry:   The=
 CDNI Metadata API MUST support exchange of CDNI metadata for both the dyna=
mic 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 an=
d/or associated distribution metadata before the content is actually reques=
ted by endusers). [Editor's Note: how much influence the Upstream CDN ought=
 to have on pre-positioning of the content on surrogates inside the Downstr=
eam CDN is TBD].
>> <=
/o:p>
the Metadata API only needs to support dyn=
amic acquisition, ie a request-response; pre-positioning is achieved by the=
 CDN Control API trigger triggering the Metadata API. So suggest both of th=
ese are replaced by:
 
Rx: The CDNI Metadata API MUST support a model=
 where the Downstream CDN requests content distribution metadata and the Up=
stream 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, R4=
5 (“all the relevant Metadata is initially communicated to the Downst=
ream CDN”).
Open for discussion about R44 (̶=
0;no, or a subset of, the Metadata is initially communicated to the Downstr=
eam CDN along with information about how/where to acquire the rest of the C=
DNI Metadata”)
 
=
 
R47
Francois proposed re-writin=
g as:
<< Rx:   =
;   Whether in the pre-positioning model or a dynamic acquisition=
 model, the CDNI Metadata API MUST provide the necessary information to all=
ow the Downstream CDN to acquire the content from an upstream source (e.g. =
Acquisition protocol and Uniform Resource Identifier in Upstream CDN- or ru=
les to construct this URI). 
&nb=
sp;
Ry:The CDNI metadata MUST allow signal=
ing of one or more upstream sources, where each upstream source can be in t=
he Upstream CDN, in another CDN, the CSP origin server or any arbitrary sou=
rce designated by the Upstream CDN. Note that some upstream sources (e.g. t=
he 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 ma=
y omit those sources when exchanging CDNI metadata.
"
 
(it says "may omit" and mot "=
MAY omit" because the document defines requirement on the protocol its=
elf, not so much how an implementation must/should/may use the protocol kno=
bs).
>> 
Don’t thi=
nk 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: CAPA=
BILITY of api to signal address etc of upstream source(s) from which the do=
wnstream CDN may be able to get content
 
Rx – it seems unrealistic to try to force a guarantee t=
hat the source is willing to serve the content to this downstream CDN, as t=
his is about business practices. Delete Rx.
Ry: <&l=
t;The CDNI metadata MUST allow signalling>> - better to say << =
The CDNI metadata MUST signal>>. Not sure if this is the best place t=
o mention the stuff in the last sentence, but the point is reasonable.=

 
 
&n=
bsp;  R48  The CDNI Metadata API MUST allow the Upstream CDN to a=
dd and
       =
 modify CDNI Metadata into the Downstream CDN.
=
=3D> The CDNI Metadata API MUST allow the Upstream CDN to request the ad=
dition 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 Me=
tadata, but it can’t guarantee what the other CDN actually does<=
/o:p>
 
   R52 =
; The CDNI Metadata API MUST provide indication by the Downstream
        CDN to the Upst=
ream CDN of whether the CDNI metadata (and
 =
       corresponding future request redirecti=
ons) is accepted or
    &nb=
sp;   rejected.  When rejected, the CDNI Metadata API MUST a=
llow the
      &nbs=
p; Downstream CDN to provide information about the cause of the<=
/span>
        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 bes=
t you can do is an ACK that the information was received. 
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 Upstrea=
m CDN of the CDNI Metadata request, which potentially includes an error cod=
e (for example if the request is rejected). 
 
   R53  The Metadata that can =
be distributed by the CDNI Metadata API
 &nb=
sp;      MUST allow signaling of distribution cont=
rol policies.  For
    &=
nbsp;   example, this could potentially include:
=3D> The CDNI Metadata API MUST...
S=
ame comment for R54, R57
Possibly you could add &=
#8220;(of the content)” at the end of the first sentence (ie policies=
 about distribution of the content & not distribution of the CDNI Metad=
ata) – but the examples may make this clear enough.=

 
R56
Del=
ete. 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 presen=
ce of cascaded CDNs.
Think cascading is being ha=
ndled as a generic requirement.
<=
span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

   R59  The CDNI Metadata API SHOULD allow s=
ignalling of the Virtual CDN
   &n=
bsp;    identifier to be used in the Downstream CDN for dist=
ribution and
      =
  delivery of the corresponding content (or content set).
Francois & Ben proposal is good.
   R60  The CDNI logging =
architecture and API MUST ensure reliable, non-
&=
nbsp;       repudiable logging of deliveries =
performed by a Downstream CDN
   &=
nbsp;   on behalf of an Upstream CDN.
<=
p class=3DMsoNormal>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 cann=
ot 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 thin=
k.]
 
 <=
/o:p>
   R61  The CDNI Logging API MUST provi=
de logging of deliveries to User
=
  &nbs=
p;     Agents performed by the Downstream CDN as a resu=
lt of request
      =
;  redirection by the Upstream CDN.
This mig=
ht 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 conten=
t has been delivered to UA(s).
 <=
/span>
   R62  The CDNI Logging API MUST provide log=
ging of distribution
    &nb=
sp;   performed by the Upstream CDN as a result of acquisition re=
quest
        =
by the Downstream CDN.
‘acquisition request=
’ – also applies in the dynamic pre-positioning case.
 
It might be possible to m=
erge R60-63:
   Rx  The CDNI Loggi=
ng API MUST provide logging of how many times the Downstream CDN has delive=
red 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 CD=
N. Delivery of the logging message MUST be reliable and non-repudiable.
 
Rx – within i=
nitial scope:
The CDNI Logging API MUST provide c=
ontrol over what is in the logging records, for example: when logging recor=
ds 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 t=
o 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=
.
 
   R=
68  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”)
 
Mis=
sing 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. This is quite challenging and one reason that it se=
ems hard to support cascaded CDNs in the initial WG scope (especially if on=
e allows any flexibility over what is reported, format of reports, security=
 methods, real-time reports, etc) 
 
   R70  The CDNI solution MUST provide suffici=
ent protection against
    &n=
bsp;   Denial of Service attacks.  In particular, this inclu=
des
        pr=
otection against spoofed delivery requests sent by user agents
        directly to a Down=
stream CDN attempting to appear as if they had
&n=
bsp;       been redirected by a given Upstrea=
m CDN when they have not.
“In particular...=
” seems to imply that it is never valid for a User Agent to request d=
irectly to a downstream CDN. But if the downstream CDN is ok to deliver the=
 content then there is no problem. Suggest delete “In particular...&#=
8221;
 
 &nbs=
p; R72  The CDNI solution MUST be able to ensure that the Downstream C=
DN
        can=
not spoof a transaction log attempting to appear as if it=

        corresponds to a reques=
t redirected by a given Upstream CDN when
 &=
nbsp;      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 delive=
ry 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 see=
ms over-the-top.
 
Best=
 wishes,
Trevor & Phil 
 
 
=
 
 
&nb=
sp;
 
 
= --_000_9510D26531EF184D9017DF24659BB87F327828C214EMV65UKRDdoma_-- From ben@niven-jenkins.co.uk Thu Feb 3 12:42:18 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D70E3A6AE1 for ; Thu, 3 Feb 2011 12:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.157 X-Spam-Level: X-Spam-Status: No, score=-104.157 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWnWujE4BG4p for ; Thu, 3 Feb 2011 12:42:17 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 1145A3A6405 for ; Thu, 3 Feb 2011 12:42:16 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pl63c-0001Re-BC; Thu, 03 Feb 2011 20:45:37 +0000 References: <212C5B7F-B5EC-4CB1-8399-30E88D802EDF@cisco.com> In-Reply-To: <212C5B7F-B5EC-4CB1-8399-30E88D802EDF@cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Message-Id: <6C7004BB-9C16-428B-9B51-244C2203C345@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Thu, 3 Feb 2011 20:45:33 +0000 To: David R Oran X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 20:42:18 -0000 Dave, I read the rest of the thread before responding but this earlier e-mail = from you seems the most appropriate one to respond to. On 2 Feb 2011, at 00:47, David R Oran wrote: > Isn't this a special case of the general 3rd party referral problem? = Why are you writing CDNi-specific requirements? Shouldn't you just say = "CDN interconnection requires third party references and hence depends = on mechanisms for the handling of such in URI's for a number of cases = involving NATs, V4/V6 tunnels, and other scenarios that cause problems = with third party references". >=20 I agree, what we need to do is ensure redirects between CDNs work in the = networks and deployments where it is likely to be used. "laser = focussing" on IP address literals was partly my fault for bashing out = quick replies rather taking some time to consider the wider implications = so thanks for pointing this out. > I would hate to see a requirement that led to a custom solution for = CDN interconnection that didn't work for any old style of redirection. >=20 Me too. I guess a slight concern I have is that if (as one of your later = e-mails implied) there is currently no work that pulls all the cases = together then we may end up in something of a catch-22. A CDNI WG is not = the place to define the general case solution for 3rd party redirects = (IMO) but we will need a solution that CDNI can leverage for (at least a = subset) of the issues with 3rd party redirects and if no-one else is = working on the problem we may have an issue when we come to define the = CDNI solution in detail. I appreciate your offer to do some digging and = we can see where that leads. In the meantime I would propose that we make the requirement more = general to refer to 3rd party redirects. We can use IP address literals = as one example of how they can be problematic if folks want to include = it explicitly. When we come to do the detailed specification work we = will hopefully have a better view as to what existing work there is that = we could leverage and if there is no such work we can take AD advice on = how to stimulate that more general work (and the appropriate place to = try and do it) or whether we should go and define a solution for CDNI by = ourselves (e.g. if there is not the energy in the community to take on = the more general problem space of 3rd party redirects). Does that sound reasonable and address your concerns? Ben > If IP address literals cause third-party breakage, just banning them = will only mask problems when people add further breakage like split DNS. >=20 > DaveO >=20 > On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >=20 >>=20 >> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>=20 >>> Hi Ben, >>>=20 >>> Thanks for thinking through this. My concern was U2 should put the = IP in >>> the URL but it wouldn=B9t happen. This is fine. I agree that if we = use the >>> FQDN in the redirect, CDN2 will stream the content to U2 in native = v6 if >>> the CDN2 supports v6. >>=20 >> So we should add a requirement along the lines of the one you = discussed earlier with Dan: >>=20 >>> I would propose adding a general requirement to the document stating >>> "any >>> URIs returned to User Agents MUST NOT contain IP address literals in >>> the >>> component of the URI" or similar text. >>=20 >> Right? >>=20 >> Francois >>=20 >>>=20 >>> Yiu >>>=20 >>>>=20 >>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is = not >>>> the issue. The issue is that NAT64 relies on the NAT64 device = synthesising >>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 = address >>>> literal in the Content-Location header of a HTTP 302 it has no way = to >>>> communicate with that v4 address as it has no native v4 capability = (or no >>>> native v4 routing). >>>>=20 >>>> Using a FQDN (and avoiding v4 address literals) in the = Content-Location >>>> header would avoid the issue as you first suggested. >>>>=20 >>>> Ben >>>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> >>=20 >> Francois Le Faucheur >> Distinguished Engineer >> Corporate Development >> flefauch@cisco.com >> Phone: +33 49 723 2619 >> Mobile: +33 6 19 98 50 90 >>=20 >>=20 >>=20 >> Cisco Systems France >> Greenside >> 400 Ave de Roumanille >> 06410 Sophia Antipolis >> France >> Cisco.com >>=20 >>=20 >>=20 >>=20 >> >> Think before you print. >>=20 >> 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. >>=20 >> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >>=20 >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Thu Feb 3 12:47:54 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DE23A6AEF for ; Thu, 3 Feb 2011 12:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.117 X-Spam-Level: X-Spam-Status: No, score=-104.117 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aWhlGYbrmW1 for ; Thu, 3 Feb 2011 12:47:53 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 469213A6405 for ; Thu, 3 Feb 2011 12:47:53 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pl695-0004Q5-Lz; Thu, 03 Feb 2011 20:51:15 +0000 References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <91DFE416-1B29-4826-ADCD-A9259D75F6B9@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Thu, 3 Feb 2011 20:51:13 +0000 To: David R Oran X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, Viveganandhan Mahesh , Yiu Lee Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 20:47:54 -0000 Dave, On 2 Feb 2011, at 00:53, David R Oran wrote: > On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: >> I'd therefore suggest making loop detection a general requirement = (SHOULD) and any more specific requirements (e.g. R33) under the = specific API they apply to. >>=20 > I think the requirement is stronger: CDNs need to agree on a common = mechanism for loop detection; otherwise you can get multiplicative loop = diameters and effectively not have useful loop detection when the = non-looping paths are long. This is routing; we know what happens when = you do loop detect with thing like count-to-infinity. >=20 Agreed. Requiring a common mechanism is what I had in mind but I = obviously didn't express it as clearly as you have. Thanks. Ben From ben@niven-jenkins.co.uk Thu Feb 3 13:18:10 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD743A6998 for ; Thu, 3 Feb 2011 13:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.082 X-Spam-Level: X-Spam-Status: No, score=-104.082 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ3Yzy3B7ij4 for ; Thu, 3 Feb 2011 13:18:09 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 585753A6846 for ; Thu, 3 Feb 2011 13:18:09 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pl6cJ-0007d4-T5; Thu, 03 Feb 2011 21:21:28 +0000 References: <96E4975F-A4B8-42FF-ABF9-36A0AA630AF9@niven-jenkins.co.uk> <1DD63546-ADF1-4144-95CE-8E1BD537C222@cisco.com> In-Reply-To: <1DD63546-ADF1-4144-95CE-8E1BD537C222@cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <6138910F-65E4-412C-95DE-1B8CA04C36D3@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Thu, 3 Feb 2011 21:21:26 +0000 To: David R Oran X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , Viveganandhan Mahesh , "Lee, Yiu" Subject: Re: [CDNi] CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:18:11 -0000 Dave, On 2 Feb 2011, at 12:01, David R Oran wrote: >=20 > On Feb 1, 2011, at 6:32 PM, Ben Niven-Jenkins wrote: >=20 >>=20 >> On 1 Feb 2011, at 22:59, Lee, Yiu wrote: >>=20 >>> Hi Ben, >>>=20 >>> I agree with your analysis but what I think is will the TTL is = enough >>> rather than proposing a Delete operation altogether. I know it is = too >>> early to go to the solution space, but I still want to share my = thoughts >>> to you guys. >>=20 >> IME the majority of the time TTL is sufficient but delete is a = mandatory >> requirement for certain CSPs and without it they'll take their = business >> elsewhere. Otherwise what happens when some CSP accidentally screws = up >> their Cache-Control headers and sets an expiry that is too far in the >> future, or some disgruntled employee puts a virus infected file on = their >> origin server and the CDN caches it, or they accidentally swap out a >> childrens TV programme for pornography, etc. >>=20 > Of course, a screwup in TTL is likely, while a malfunctioning or = incorrectly applied DELETE is not :-) >=20 :-) The key of course is to provide the tools to let folks recover from = their screw ups. We need to balance the ability to do so in an = "automated" fashion against the engineering cost of building the = additional complexity into the solution and the likely frequency of such = screw ups and the expectations of CSPs. > I agree that there's a requirement for rapidly making an asset = unavailable in the downstream CDN(s). I'm not sure I would phrase the = requirement as being for a delete operation, however. Delete has = arguably clean semantics, but various interesting failure modes and = difficulty in protocol design for distributed operation. I hark back to = my days dealing with the tricky problem of route removal in BGP. >=20 In a previous life when I was building a CDN the feedback directly from = some CSPs was that delete was a requirement. TBH at the time I didn't = pushback on whether an "invalidate" function would be sufficient because = the vendor we were using supported delete but didn't support invalidate. I wasn't involved at the time but I was told today that originally = Velocix (my current employer) only supported invalidate but implemented = delete based on direct feedback from CSPs that invalidate was useful but = not sufficient. > Some thoughts on the general removal problem: >=20 > - Is there a requirement to specify what happens to sessions in = progress with users? Does one CDN get to tell another CDN that they must = instantly abort streaming/download to active users? I think we would need to define what the semantics of = delete/invalidate/whatever are including any expected impact to "in = flight" sessions. I can't answer your second question right now as I = need to check what the expectation from CSPs is today. > - Is there a stronger security requirement because now we have a = trivial DoS vector in the protocol? Possibly. > - Is there a need to distinguish between "make this assert = unavailable" and "remove the bits"? For example, there may be a useful = feature of temporarily "disabling" an asset without removing it so that = it can be reinstated without copying the bits all over again? If we have delete then we can meet the CSPs' requirements as I = understand but delete is an expensive operation and so I think there is = value is also having a cheaper function (maybe "invalidate", maybe "make = unavailable") that doesn't remove the bits but also would only address a = subset of the CSPs' requirements. Whether we do one or both and whether = we do one first and the other later is obviously something for the group = as a whole to decide.=20 The other thing is that this thread started from a discussion about = whether control API requests need to be cascaded or not. Regardless of = whether the control API ends up with functions to "delete" or = "invalidate" or "make unavailable" or whatever I think it's clear that = at least some control API requests do need to be cascaded. > - Can't the whole problem be addressed with less overhead by = separating the content bits from the encryption keys such that there are = separate operations on each? Then revocation of an asset can be done by = invalidating keys without touching the content bits. Two things: not all content is encrypted and not all CDN filing systems = are encrypted. There are many CDN use cases where encryption is an = unnecessary expense. I believe that even for encrypted content some CSPs still have a = requirement to remove the bits. > - =46rom a mechanism standpoint, is there a semantic difference = between "delete" and "update with zero TTL"? We likely need update = anyway for pseudo-live content so conservation of mechanism argues for = avoiding a separate delete operation if it doesn't have usefully = different semantics. >=20 With "update with zero TTL" you are not forced to remove the bits and = are free to include an If-Modified-Since header field in the request to = the Origin and if the Origin responds with a 304 then you're free to use = the bits you already have without re-acquiring anything. With delete you = are forced to remove the bits and any subsequent requests generate a = fresh "vanilla" GET to the Origin.=20 Ben From oran@cisco.com Thu Feb 3 15:05:59 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610C3A6AC3 for ; Thu, 3 Feb 2011 15:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIhFybnUMIGE for ; Thu, 3 Feb 2011 15:05:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A78483A6A17 for ; Thu, 3 Feb 2011 15:05:58 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 23:09:22 +0000 Received: from sjc-vpnasa-397.cisco.com (sjc-vpnasa-397.cisco.com [10.21.105.143]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13N9L0n011898; Thu, 3 Feb 2011 23:09:21 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: <6C7004BB-9C16-428B-9B51-244C2203C345@niven-jenkins.co.uk> Date: Thu, 3 Feb 2011 18:09:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <65F728C7-5F84-4468-9237-CB873BEEAF73@cisco.com> References: <212C5B7F-B5EC-4CB1-8399-30E88D802EDF@cisco.com> <6C7004BB-9C16-428B-9B51-244C2203C345@niven-jenkins.co.uk> To: Benjamin Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:05:59 -0000 On Feb 3, 2011, at 3:45 PM, Benjamin Niven-Jenkins wrote: > Dave, >=20 > I read the rest of the thread before responding but this earlier = e-mail from you seems the most appropriate one to respond to. >=20 > On 2 Feb 2011, at 00:47, David R Oran wrote: >=20 >> Isn't this a special case of the general 3rd party referral problem? = Why are you writing CDNi-specific requirements? Shouldn't you just say = "CDN interconnection requires third party references and hence depends = on mechanisms for the handling of such in URI's for a number of cases = involving NATs, V4/V6 tunnels, and other scenarios that cause problems = with third party references". >>=20 >=20 > I agree, what we need to do is ensure redirects between CDNs work in = the networks and deployments where it is likely to be used. "laser = focussing" on IP address literals was partly my fault for bashing out = quick replies rather taking some time to consider the wider implications = so thanks for pointing this out. >=20 >> I would hate to see a requirement that led to a custom solution for = CDN interconnection that didn't work for any old style of redirection. >>=20 >=20 > Me too. I guess a slight concern I have is that if (as one of your = later e-mails implied) there is currently no work that pulls all the = cases together then we may end up in something of a catch-22. A CDNI WG = is not the place to define the general case solution for 3rd party = redirects (IMO) but we will need a solution that CDNI can leverage for = (at least a subset) of the issues with 3rd party redirects and if no-one = else is working on the problem we may have an issue when we come to = define the CDNI solution in detail. I appreciate your offer to do some = digging and we can see where that leads. >=20 > In the meantime I would propose that we make the requirement more = general to refer to 3rd party redirects. We can use IP address literals = as one example of how they can be problematic if folks want to include = it explicitly. When we come to do the detailed specification work we = will hopefully have a better view as to what existing work there is that = we could leverage and if there is no such work we can take AD advice on = how to stimulate that more general work (and the appropriate place to = try and do it) or whether we should go and define a solution for CDNI by = ourselves (e.g. if there is not the energy in the community to take on = the more general problem space of 3rd party redirects). >=20 > Does that sound reasonable and address your concerns? >=20 WFM! Thanks, DaveO. > Ben >=20 >=20 >=20 >=20 >> If IP address literals cause third-party breakage, just banning them = will only mask problems when people add further breakage like split DNS. >>=20 >> DaveO >>=20 >> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote: >>=20 >>>=20 >>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote: >>>=20 >>>> Hi Ben, >>>>=20 >>>> Thanks for thinking through this. My concern was U2 should put the = IP in >>>> the URL but it wouldn=B9t happen. This is fine. I agree that if we = use the >>>> FQDN in the redirect, CDN2 will stream the content to U2 in native = v6 if >>>> the CDN2 supports v6. >>>=20 >>> So we should add a requirement along the lines of the one you = discussed earlier with Dan: >>>=20 >>>> I would propose adding a general requirement to the document = stating >>>> "any >>>> URIs returned to User Agents MUST NOT contain IP address literals = in >>>> the >>>> component of the URI" or similar text. >>>=20 >>> Right? >>>=20 >>> Francois >>>=20 >>>>=20 >>>> Yiu >>>>=20 >>>>>=20 >>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That = is not >>>>> the issue. The issue is that NAT64 relies on the NAT64 device = synthesising >>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4 = address >>>>> literal in the Content-Location header of a HTTP 302 it has no way = to >>>>> communicate with that v4 address as it has no native v4 capability = (or no >>>>> native v4 routing). >>>>>=20 >>>>> Using a FQDN (and avoiding v4 address literals) in the = Content-Location >>>>> header would avoid the issue as you first suggested. >>>>>=20 >>>>> Ben >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> >>>=20 >>> Francois Le Faucheur >>> Distinguished Engineer >>> Corporate Development >>> flefauch@cisco.com >>> Phone: +33 49 723 2619 >>> Mobile: +33 6 19 98 50 90 >>>=20 >>>=20 >>>=20 >>> Cisco Systems France >>> Greenside >>> 400 Ave de Roumanille >>> 06410 Sophia Antipolis >>> France >>> Cisco.com >>>=20 >>>=20 >>>=20 >>>=20 >>> >>> Think before you print. >>>=20 >>> 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. >>>=20 >>> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >>>=20 >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From trevor.burbridge@bt.com Fri Feb 4 06:38:44 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025DE3A68E4 for ; Fri, 4 Feb 2011 06:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNJG3w40oKeW for ; Fri, 4 Feb 2011 06:38:36 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 7AF483A68E9 for ; Fri, 4 Feb 2011 06:38:35 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 4 Feb 2011 14:41:59 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.65]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 4 Feb 2011 14:41:59 +0000 From: To: , Date: Fri, 4 Feb 2011 14:41:58 +0000 Thread-Topic: White-label, wholesale and brokering WAS: New (-01) version of CDNI Use Cases drafts Thread-Index: AcvBSsvf7uF70zpXRs2hYJq4ds6v5wDKti+A Message-ID: References: <8E09C72DBC577D489F13A71228C0B7BF020D5DC7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF020D5DC7@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72638D2F080EMV64UKRDdoma_" MIME-Version: 1.0 Subject: [CDNi] White-label, wholesale and brokering WAS: New (-01) version of CDNI Use Cases drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:38:44 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72638D2F080EMV64UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In our effort to get the use case revision out promptly we dropped a couple= of potential use cases. Id like to consider adding something along the lin= es of the following use case, potentially under the offload section or as a= section on its own: -- White-label, Wholesale and Brokering Some companies will desire to offer CDN functions under their own branding,= but operated on their behalf by other organisations. Building dedicated CD= Ns is clearly not as cost effective as being able to virtualise a CDN to lo= ok to User Agents and CSPs as if it were multiple CDSPs. Although not stric= tly interconnection (since only one CDN is actually involved) this model of= business will have specific requirements on the UA and CSP interfaces (to = maintain the identity of the virtual CDSP), along with the use of interconn= ection APIs between virtual CDSPs. An alternative is for one CDSP to operate some part of the CDN functions, b= ut to offload the actual content storage and delivery (e.g. the surrogates)= to another CDSP. For example, in this model a 'front-end' CDSP would acqui= re content and receive the initial routing requests from the user agent, al= ong with compiling the logging for the CSP. Another 'back-end' CDSP operate= s the content storage and delivery (distribution) functions. Technically th= e 'back-end' CDSP could provide its own content management and request rout= ing functions, or could expose bare distribution capabilities. This latter = approach would require the externalisation of some of the distribution func= tion internal APIs, including sharing knowledge about surrogate locations a= nd capabilities that would otherwise be obfuscated by the CDN. Such interfa= ces could be developed separately to the initial work on full CDN-interconn= ection. Brokering follows from the wholesale model, where a 'front' end' CDSP is ab= le to direct content and requests to multiple CDSPs or storage and delivery= capabilities from multiple operators. -- Trevor. Trevor Burbridge Network-Based Services Infrastructure | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of gil= les.bertrand@orange-ftgroup.com Sent: 31 January 2011 13:29 To: cdni@ietf.org Subject: [CDNi] New (-01) version of CDNI Use Cases drafts Dear all, We have posted a new version of the CDNI Use Cases I-D, which can be found = here: http://www.ietf.org/id/draft-bertrand-cdni-use-cases-01.txt. It merges draf= t-bertrand-cdni-use-cases-00 and draft-watson-cdni-use-cases-00. A summary of the changes: - Merging of draft-bertrand-cdni-use-cases-00 and draft-watson-cdni-use-cas= es-00 - Update of the Use Cases description - Addition of a section on "Discussion on Priorities for the Proposed Chart= er" to be worked out later according to the discussions on the mailing list Looking forward to your feedback. -- Gilles -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : lundi 31 janvier 2011 14:00 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-bertrand-cdni-use-cases-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Use Cases for Content Distribution Network Intercon= nection Author(s) : G. Bertrand, et al. Filename : draft-bertrand-cdni-use-cases-01.txt Pages : 21 Date : 2011-01-31 Content Delivery Networks (CDNs) are commonly used for improving the footpr= int and the end-user experience of a content delivery service, at a reasona= ble cost. This document outlines real world use-cases (not technical solut= ions) for interconnecting CDNs. The intention is to motivate CDN Interconn= ection and to support the case for formation of a Working Group, which woul= d work on the definition of standardized, inter-operable method(s) for inte= rconnecting CDNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-use-cases-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_000_ED51D9282D1D3942B9438CA8F3372EB72638D2F080EMV64UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In our effort to get the use case revision out promptly we dr= opped a couple of potential use cases. Id like to consider adding something= along the lines of the following use case, potentially under the offload s= ection or as a section on its own:

 

--

 

White-label, Wholesale and Brokerin= g

<= o:p> 

Some companies will desire to offer CDN functions under their own brandi= ng, but operated on their behalf by other organisations. Building dedicated= CDNs is clearly not as cost effective as being able to virtualise a CDN to= look to User Agents and CSPs as if it were multiple CDSPs. Although not st= rictly interconnection (since only one CDN is actually involved) this model= of business will have specific requirements on the UA and CSP interfaces (= to maintain the identity of the virtual CDSP), along with the use of interc= onnection APIs between virtual CDSPs.

 

An alternative is for one CDSP to op= erate some part of the CDN functions, but to offload the actual content sto= rage and delivery (e.g. the surrogates) to another CDSP. For example, in th= is model a ‘front-end’ CDSP would acquire content and receive t= he initial routing requests from the user agent, along with compiling the l= ogging for the CSP. Another ‘back-end’ CDSP operates the conten= t storage and delivery (distribution) functions. Technically the ‘bac= k-end’ CDSP could provide its own content management and request rout= ing functions, or could expose bare distribution capabilities. This latter = approach would require the externalisation of some of the distribution func= tion internal APIs, including sharing knowledge about surrogate locations a= nd capabilities that would otherwise be obfuscated by the CDN. Such interfa= ces could be developed separately to the initial work on full CDN-interconn= ection.

 

Brokering follows from the wholesale model, where a ‘front&#= 8217; end’ CDSP is able to direct content and requests to multiple CD= SPs or storage and delivery capabilities from multiple operators.

 <= /o:p>

&nb= sp;

--

 

= Trevor.

 

Trevor Burbri= dge
Network-Based Services Infrastructure | BT Innovate & Design
= Tel: 01473 645115
Fax: 01473 640929

<= span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif";color:#1F497= D'>This email contains BT information, which may be privileged or confident= ial. It's meant only for the individual(s) or entity named above. If you're= not the intended recipient, note that disclosing, copying, distributing or= using this information is prohibited. If you've received this email in err= or, please let me know immediately on the email address above. Thank you.We monitor our email system, and may record your emails.=
British Telecommunications plc
Registered office: 81 New= gate Street London EC1A 7AJ
Registered in England no: 1800000

From: cdni-bounces= @ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of gilles.bertran= d@orange-ftgroup.com
Sent: 31 January 2011 13:29
To: cd= ni@ietf.org
Subject: [CDNi] New (-01) version of CDNI Use Cases d= rafts

 

Dear all,

 

We have posted a new version of= the CDNI Use Cases I-D, which can be found here:

http://www.ietf.org/id/draft-bertrand-c= dni-use-cases-01.txt. It merges draft-bertrand-cdni-use-cases-00 and dr= aft-watson-cdni-use-cases-00.

=  

A summary of the changes:

- Merging of draft-bertrand-cdni-use-cases-00= and draft-watson-cdni-use-cases-00

- Update of the Use Cases description

- Addition of a section= on "Discussion on Priorities for the Proposed Charter" to be wor= ked out later according to the discussions on the mailing list

 

Looking forward to your fee= dback.

 

--

Gilles

 

<= p class=3DMsoPlainText> 

 

 

-----Message d'origine-----
De : i-d-announce-bou= nces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la part de Internet= -Drafts@ietf.org
Envoy=E9 : lundi 31 janvier 2011 14:00
=C0 = ;: i-d-announce@ietf.org
Objet : I-D Action:draft-bertrand-cdni-use= -cases-01.txt

=  

A Ne= w Internet-Draft is available from the on-line Internet-Drafts directories.=

 = ;

  &n= bsp;   Title         = ;  : Use Cases for Content Distribution Network Interconnection

   = ;   Author(s)       : G. Bertrand, = et al.

&nbs= p;     Filename      &nbs= p; : draft-bertrand-cdni-use-cases-01.txt

      Pages &n= bsp;         : 21=

    &nbs= p; Date            := 2011-01-31

 

Con= tent Delivery Networks (CDNs) are commonly used for improving the footprint= and the end-user experience of a content delivery service, at a reasonable= cost.  This document outlines real world use-cases (not technical sol= utions) for interconnecting CDNs.  The intention is to motivate CDN In= terconnection and to support the case for formation of a Working Group, whi= ch would work on the definition of standardized, inter-operable method(s) f= or interconnecting CDNs.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draf= t-bertrand-cdni-use-cases-01.txt

 

<= span lang=3DEN-US>Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.= org/internet-drafts/

 

Below is the data which will enable a MIME compliant mail reader impleme= ntation to automatically retrieve the ASCII version of the Internet-Draft.<= o:p>

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72638D2F080EMV64UKRDdoma_-- From ben@niven-jenkins.co.uk Sun Feb 6 03:36:16 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69A43A68D4 for ; Sun, 6 Feb 2011 03:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37EdXaUuOOmr for ; Sun, 6 Feb 2011 03:36:15 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 919DD3A68C0 for ; Sun, 6 Feb 2011 03:36:12 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pm2uZ-0000dr-F0; Sun, 06 Feb 2011 11:36:12 +0000 References: <03F85AE8-0D91-426C-8C2D-C601E3677C71@niven-jenkins.co.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <79D4FB8C-8740-4952-B7DC-7CCBF8AAA945@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sun, 6 Feb 2011 11:36:09 +0000 To: X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 11:36:17 -0000 Trevor, Thanks for the response, see inline below. On 2 Feb 2011, at 15:04, = wrote: >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >>> Although the text implies a need for a mechanism to restrict access >> to >>> just nomadic users and prevent =B3all residents within a region=B2 = having >>> access I would expect that even in the geographic extension use case >> there >>> would be a requirement to be able to restrict access to a subset of >> the >>> total user population e.g. only those users who had previously >>> authenticated to the CSP=B9s service. >=20 > As you say the difference is in the Metadata that controls the = distribution. There are probably quite a few scenarios that require a = highly expressive language for the distribution policy. I think = standardising things like the policy language could be one of the more = difficult challenges, and certainly one where we have to integrate as = much as possible with other industry bodies. >=20 Personally I don't think the language needs to that expressive. Distribution policy is typically controlled by the CSP. =46rom the point = of view of a CSP they can typically express their preferences in fairly = simple terms, i.e. split into rules for "serving" and rules for = "delivery" which when combined express their requirements. Serving rules are typically of the form - I don't care where you store & serve my content from as long as my = users/customers can access it - I do care where you store & serve my content from and either: - You must not store/serve it from these locations (which are = typically a geographic region, e.g. country/city/metro area) - You must only store/serve it from these locations. Delivery rules are typically of the form - I don't care where the user is. - I do care where the user is and either: - They must not be in these locations (typically geographic regions, = countries/cities/metro areas)=20 - They must only be in these locations Plus: - Regardless of my other delivery preferences these ranges of IP = addresses can always have access (e.g. the CSP's QA team may be located = in a region they typically do not want the CDN to deliver to) - On top of the CSPs other delivery preferences ensure the user has been = previously authenticated via the CSPs service layer (portal, middleware, = etc.) All the above can be reduced to and expressed as a pair of access = control lists, one for distribution & one for delivery, where the key = variables are how one describes locations and how one indicates a user = is appropriately authenticated. It may be tempting to try to make the policy language more expressive = than an ordered list of locations plus allow/deny/must-be-authenticated = actions but I have yet to see a requirement from a CSP that can not be = suitably addressed/met using such a pair of distribution+delivery access = control lists. >>> I might be being pedantic but is it the device that requires unique >>> delivery capabilities or is it that the device only speaks certain >>> protocols and =B3delivery capabilities in the CDN=B2 really means = =B3the >> CDN >>> must support delivery protocol X=B2? >=20 > Well the CDN requirement would certainly be phrased as you suggest. In = technical terms, again there isn't a huge difference - impacts on how = expressive the capabilities description is through the control API. This = might include network speed and characteristics, protocols supported, as = well as things like screen size and even processing power. Some network = characteristics, some surrogate delivery mechanisms, some device = capabilities. >=20 >>> The effort required to specifying how to describe different delivery >>> protocols & which CDNs support them is much reduced compared to >> specifying >>> how to describe the multitude of different devices and their >> individual >>> capabilities. >=20 > Yes, but you may need to know about the devices (at least at some = level) - for example, there's no point in moving a certain encoding to a = downstream CDN if you know that if has no devices that require it. I'm = not suggested compiling lists of all devices, but these might be rolled = into the CDN capabilities at some level. >=20 We need to be careful not to try and overload the CDN with functions and = responsibilities that are better placed elsewhere. Knowledge of "screen = size", "encodings" and "device types" for example largely sit outside of = the CDN. The CDN delivers what the CSP tells it to. The ultimate choice = of the appropriate version of content to deliver (i.e. screen = size/encoding/format for particular device) should sit with the CSP not = with the CDN as the CDN only has a limited ability to determine those = things. The End User (via their user agent) will in the vast majority of = cases have interacted with the CSP's service layer (portal, middleware, = etc.) prior to being redirected to the CDN and the CSP's service layer = has much better knowledge of the user's preferences and device = capabilities than the CDN does. Getting it wrong means that the user = goes away with a poor experience of the CSP not of the CDN (as the CDN = is largely invisible to all but the most technically minded users). The analogy I'd draw (which may or may not work) is that of a mail order = movie rental company. The movie rental company (i.e. the CSP) is in the = best position to know whether you typically like to receive VHS, DVD or = Blueray movies (either because you've told them or from previous order = history). The courier (i.e. the CDN) who delivers the movie to your home = typically has very little ability to make that determination. Ben From ben@niven-jenkins.co.uk Sun Feb 6 03:38:59 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5831F3A68D4 for ; Sun, 6 Feb 2011 03:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.555 X-Spam-Level: X-Spam-Status: No, score=-101.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0DYOtkNxdLD for ; Sun, 6 Feb 2011 03:38:58 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 8222F3A68AD for ; Sun, 6 Feb 2011 03:38:58 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pm2xG-0003sR-UM; Sun, 06 Feb 2011 11:38:59 +0000 References: <8E09C72DBC577D489F13A71228C0B7BF02114CFE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02114CFE@ftrdmel0.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <2E15F289-DB56-4867-8878-CDD781F6D557@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sun, 6 Feb 2011 11:38:57 +0000 To: X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] TR: New (-01) version of CDNI Use Cases drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 11:38:59 -0000 Gilles, See inline below: On 2 Feb 2011, at 17:07, = wrote: > De : Ben Niven-Jenkins [mailto:ben@velocix.com] Envoy=E9 : lundi 31 > "2.2.2. Resiliency > =20 > ... > Resiliency may also be required against failure to ingest content > from the CSP. In these cases the content may be available from > another CDSP." > =20 > I think it would be useful if you could try and expand on the part > of the resiliency use case related to failures like this as I > suspect there may be some additional requirements hiding under the = surface. > =20 > For example, is there an assumption that the downstream CDN already > has the content, or is there an assumption that the failure that > meant the upstream CDN could not ingest the content does not impact > the downstream CDN's ability to ingest from the same CSP? > =20 > [ GILLES: > If the CSP uses some protection > mechanism to allow the content ingestion, there could be situations > where the upstream CDN successfully ingests the content (the CSP = authorizes the ingestion request), whereas the > CSP rejects direct ingestion requests from the downstream CDN. To = circumvent the problem, the dCDN might ingest content through the uCDN. = ] OK I understand. I think this is already covered in the requirements = draft. > =20 > [GILLES: > The limitations list in this section of the I-D is non exhaustive. We = are > preparing an I-D, which will describe our experiments and identified = limitations more in details. > We will for sure try to ensure that the requirements draft covers the = identified issues.] Great. I very much look forward to reading the draft when it is = available. Ben > =20 From flefauch@cisco.com Sun Feb 6 07:27:08 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1EB3A6965 for ; Sun, 6 Feb 2011 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkrM3g07t6KS for ; Sun, 6 Feb 2011 07:27:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1144C3A6927 for ; Sun, 6 Feb 2011 07:27:06 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2011 15:27:08 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p16FR7rJ014974; Sun, 6 Feb 2011 15:27:07 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Francois Le Faucheur In-Reply-To: <79D4FB8C-8740-4952-B7DC-7CCBF8AAA945@niven-jenkins.co.uk> Date: Sun, 6 Feb 2011 16:27:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1B369F-7696-47DD-BA11-4F9F5402F379@cisco.com> References: <03F85AE8-0D91-426C-8C2D-C601E3677C71@niven-jenkins.co.uk> <79D4FB8C-8740-4952-B7DC-7CCBF8AAA945@niven-jenkins.co.uk> To: Benjamin Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org Subject: Re: [CDNi] Fwd: Some comments on draft-bertrand-cdni-use-cases-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 15:27:08 -0000 Ben, Trevor, On 6 Feb 2011, at 12:36, Benjamin Niven-Jenkins wrote: > Trevor, >=20 > Thanks for the response, see inline below. >=20 > On 2 Feb 2011, at 15:04, = wrote: >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >>> Ben Niven-Jenkins >>>> Although the text implies a need for a mechanism to restrict access >>> to >>>> just nomadic users and prevent =B3all residents within a region=B2 = having >>>> access I would expect that even in the geographic extension use = case >>> there >>>> would be a requirement to be able to restrict access to a subset of >>> the >>>> total user population e.g. only those users who had previously >>>> authenticated to the CSP=B9s service. >>=20 >> As you say the difference is in the Metadata that controls the = distribution. There are probably quite a few scenarios that require a = highly expressive language for the distribution policy. I think = standardising things like the policy language could be one of the more = difficult challenges, and certainly one where we have to integrate as = much as possible with other industry bodies. >>=20 >=20 > Personally I don't think the language needs to that expressive. >=20 > Distribution policy is typically controlled by the CSP. =46rom the = point of view of a CSP they can typically express their preferences in = fairly simple terms, i.e. split into rules for "serving" and rules for = "delivery" which when combined express their requirements. >=20 > Serving rules are typically of the form > - I don't care where you store & serve my content from as long as my = users/customers can access it > - I do care where you store & serve my content from and either: > - You must not store/serve it from these locations (which are = typically a geographic region, e.g. country/city/metro area) > - You must only store/serve it from these locations. >=20 > Delivery rules are typically of the form > - I don't care where the user is. > - I do care where the user is and either: > - They must not be in these locations (typically geographic regions, = countries/cities/metro areas)=20 > - They must only be in these locations >=20 > Plus: > - Regardless of my other delivery preferences these ranges of IP = addresses can always have access (e.g. the CSP's QA team may be located = in a region they typically do not want the CDN to deliver to) > - On top of the CSPs other delivery preferences ensure the user has = been previously authenticated via the CSPs service layer (portal, = middleware, etc.) >=20 > All the above can be reduced to and expressed as a pair of access = control lists, one for distribution & one for delivery, where the key = variables are how one describes locations and how one indicates a user = is appropriately authenticated. >=20 > It may be tempting to try to make the policy language more expressive = than an ordered list of locations plus allow/deny/must-be-authenticated = actions but I have yet to see a requirement from a CSP that can not be = suitably addressed/met using such a pair of distribution+delivery access = control lists. That looks like a good base to start from for the = "geo-blocking/authentication" angle. I would just add the "availability = window" of R53 ie: "=20 "availability window" (i.e. Information defining time windows during = which the content is to be made available or blocked) " Let's start with these and see if someone makes a clear case for = additional requirements. Francois= From emile.stephan@orange-ftgroup.com Mon Feb 7 00:28:48 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C543A6CE6 for ; Mon, 7 Feb 2011 00:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.409 X-Spam-Level: X-Spam-Status: No, score=-98.409 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRQPPEyE4V7t for ; Mon, 7 Feb 2011 00:28:47 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 6D6FC3A6CC4 for ; Mon, 7 Feb 2011 00:28:46 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C30986C0007; Mon, 7 Feb 2011 09:29:18 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B34516C0006; Mon, 7 Feb 2011 09:29:18 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 09:28:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 7 Feb 2011 09:28:47 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AcvDjSBTYhM2IaB0QTKHQvcN8YOeQADDDahw References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 07 Feb 2011 08:28:48.0709 (UTC) FILETIME=[0B04CF50:01CBC6A1] Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:28:48 -0000 SGkgRnJhbmNvaXMsDQoNCkNETkkgaW50ZXJmYWNlcyBtdXN0IHN1cHBvcnQgbG9vcCBkZXRlY3Rp b24gZXZlbiB3aGVuIHRoZXJlIGlzIG9ubHkgMiBDRE5zIGludGVyY29ubmVjdGVkLiBIZW5jZSB0 aGlzIHJlcSBpcyB0aWVkIG5vciB0byB0aGUgbnVtYmVyIG9mIENETnMgb2YgdGhlIENETmkgY2hh aW4gbm9yIHRvIGl0cyBuYXR1cmUuDQoNClNvIGltbyBzdXBwb3J0IGZvciBsb29wIGRldGVjdGlv biBpcyBhIGdlbmVyaWMgTVVTVCB0aGF0IGFwcGxpZXMgdG8gZWFjaCBDRE5pIEFQSXMuIA0KDQpJ IHN1Z2dlc3QgaW5zZXJ0aW5nIHRoaXMgcmVxIGRpcmVjdGx5IGluIHRoZSBoZWFkZXIgb2YgdGhl IHNlY3Rpb24gMyBvZiB0aGUgcmVxIGRyYWZ0LiANCg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGNkbmktYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiBGcmFuY29p cyBMZSBGYXVjaGV1cg0KPiBFbnZvecOpwqA6IGpldWRpIDMgZsOpdnJpZXIgMjAxMSAxMToyOQ0K PiDDgMKgOiBwaGlsaXAuZWFyZGxleUBidC5jb20NCj4gQ2PCoDogbXZpdHRhbEBjaXNjby5jb207 IGNkbmlAaWV0Zi5vcmc7IFlpdV9MZWVAQ2FibGUuQ29tY2FzdC5jb20NCj4gT2JqZXTCoDogUmU6 IFtDRE5pXSBMaW1pdCBuYiBvZiByZWRpcmVjdHMgJiBsb29wIHNSZTogQ0ROSSBSZXF1aXJlbWVu dHMgSS1EDQo+IA0KPiBIaSBQaGlsLA0KPiANCj4gT24gMyBGZWIgMjAxMSwgYXQgMTE6MTgsIDxw aGlsaXAuZWFyZGxleUBidC5jb20+IHdyb3RlOg0KPiANCj4gDQo+IAlDYXNjYWRlZCBDRE5zIHdv dWxkIGJlIG5pY2UuDQo+IA0KPiAJQ2FzY2FkaW5nIGlzIG1pc3NpbmcgZnJvbSB0aGUgbG9nZ2lu ZyBzZWN0aW9uIC0gd2hlcmUgaXQgc2VlbXMgaGFyZC4NCj4gdGhlIGxvZ2dpbmcgcmVjb3JkIG5l ZWRzIHRvIGluY2x1ZGUgKGFnZ3JlZ2F0ZWQpIGluZm8gd2hlcmUgY29udGVudCBoYXMNCj4gYmVl biBkZWxpdmVyZWQgdG8gYSBVQSBieSBhIENETiBmdXJ0aGVyIGRvd24gYSBjYXNjYWRlIG9mIENE TnMuDQo+IA0KPiANCj4gVGhlcmUgYXJlIHJlcXVpcmVtZW50cyBpbiB0aGUgU2VjdXJpdHkgc2Vj dGlvbiB0aGF0IHJlbGF0ZSB0byB0aGF0Og0KPiANCj4gIg0KPiAgICBSNzEgIFRoZSBDRE5JIHNv bHV0aW9uIE1VU1QgYmUgYWJsZSB0byBlbnN1cmUgdGhhdCBmb3IgYW55IGdpdmVuDQo+ICAgICAg ICAgcmVxdWVzdCByZWRpcmVjdGVkIHRvIGEgRG93bnN0cmVhbSBDRE4sIHRoZSBjaGFpbiBvZiBD RE4NCj4gICAgICAgICBEZWxlZ2F0aW9uIChsZWFkaW5nIHRvIHRoYXQgcmVxdWVzdCBiZWluZyBz ZXJ2ZWQgYnkgdGhhdCBDRE4pDQo+ICAgICAgICAgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGggbm9u LXJlcHVkaWF0aW9uLg0KPiANCj4gICAgUjcyICBUaGUgQ0ROSSBzb2x1dGlvbiBNVVNUIGJlIGFi bGUgdG8gZW5zdXJlIHRoYXQgdGhlIERvd25zdHJlYW0gQ0RODQo+ICAgICAgICAgY2Fubm90IHNw b29mIGEgdHJhbnNhY3Rpb24gbG9nIGF0dGVtcHRpbmcgdG8gYXBwZWFyIGFzIGlmIGl0DQo+ICAg ICAgICAgY29ycmVzcG9uZHMgdG8gYSByZXF1ZXN0IHJlZGlyZWN0ZWQgYnkgYSBnaXZlbiBVcHN0 cmVhbSBDRE4gd2hlbg0KPiAgICAgICAgIHRoYXQgcmVxdWVzdCBoYXMgbm90IGJlZW4gcmVkaXJl Y3RlZCBieSB0aGlzIFVwc3RyZWFtIENETi4NCj4gIg0KPiANCj4gVGhpcyBpcyBtZWFudCB0byBh cHBseSBhbHNvIHRvIHRoZSBMb2dnaW5nIEFQSS4NCj4gSXMgdGhhdCBzdWZmaWNpZW50IHRvIGNh cHR1cmUgdGhlIHRvcGljIG9yIGRvIHlvdSB3YW50IHRvIHNlZSBhIHNwZWNpZmljDQo+IHJlcXVp cmVtZW50IHVuZGVyIHRoZSAiTG9nZ2luZyBBUEkiIHNlY3Rpb24/DQo+IA0KPiANCj4gDQo+IAlU aGlzIGlzIHF1aXRlIGNoYWxsZW5naW5nLCBlc3BlY2lhbGx5IGlmIG9uZSBhbGxvd3MgYW55IGZs ZXhpYmlsaXR5DQo+IG92ZXIgd2hhdCBpcyByZXBvcnRlZCwgZm9ybWF0IG9mIHJlcG9ydHMsIHNl Y3VyaXR5IG1ldGhvZHMsIHJlYWwtdGltZQ0KPiByZXBvcnRzLCBldGMuDQo+IA0KPiANCj4gDQo+ IAlBZ3JlZSB0aGF0IGNhc2NhZGluZyBzaG91bGQgYmUgbWVudGlvbmVkIGFzIGEgZ2VuZXJpYyBy ZXF1aXJlbWVudCAtDQo+IGFuZCB3ZSB0cmVhdCBpdCBhdCB0aGUgc2FtZSByZXF1aXJlbWVudHMg bGV2ZWwgZm9yIGFsbCB0aGUgQVBJcyAod2hldGhlcg0KPiB0aGF0J3M6IE1VU1QgaW4gaW5pdGlh bCBzY29wZSwgU0hPVUxELCBvciBiZXlvbmQgaW5pdGlhbCBzY29wZSkuDQo+IA0KPiAJUGVyc29u YWxseSB0aGluayB0aGVyZSBpcyBxdWl0ZSBhIGxvdCAid2l0aGluIGluaXRpYWwgc2NvcGUiIGlu IHRoZQ0KPiByZXF1aXJlbWVudHMgZHJhZnQsIGFuZCBjYXNjYWRpbmcgbWlnaHQgYmUgZGVmZXJy YWJsZSBpZiBpdCBhZGRzDQo+IHNpZ25pZmljYW50IHdvcmsgdG8gc3RhbmRhcmRpc2luZyB0aGUg QVBJcyAtIGFzIG1vc3Qgb2YgdGhlIHZhbHVlIG9mIENETg0KPiBpbnRlcmNvbm5lY3Qgc2VlbXMg dG8gY29tZSBmcm9tIHRoZSAib25lIGhvcCIgY2FzZSBpZToNCj4gCUNTUCAtPiBVcHN0cmVhbSBD RE4gLT4gRG93bnN0cmVhbSBDRE4gLT4gVUENCj4gDQo+IA0KPiANCj4gSSB0YWtlIHRoaXMgYXMg YSAiQiIgVm90ZS4NCj4gDQo+IFRoYW5rcw0KPiANCj4gRnJhbmNvaXMNCj4gDQo+IA0KPiANCj4g DQo+IAktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAJRnJvbTogY2RuaS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRnJh bmNvaXMgTGUgRmF1Y2hldXINCj4gCVNlbnQ6IDAyIEZlYnJ1YXJ5IDIwMTEgMTA6NDUNCj4gCVRv OiBEYXZpZCBSIE9yYW4NCj4gCUNjOiBjZG5pQGlldGYub3JnOyBWaXZlZ2FuYW5kaGFuIE1haGVz aDsgWWl1IExlZQ0KPiAJU3ViamVjdDogUmU6IFtDRE5pXSBMaW1pdCBuYiBvZiByZWRpcmVjdHMg JiBsb29wIHNSZTogQ0ROSQ0KPiBSZXF1aXJlbWVudHMgSS1EDQo+IA0KPiAJRGF2ZSBhbmQgYWxs LA0KPiANCj4gCU9uIDIgRmViIDIwMTEsIGF0IDAxOjUzLCBEYXZpZCBSIE9yYW4gd3JvdGU6DQo+ IA0KPiANCj4gDQo+IA0KPiAJCU9uIEZlYiAxLCAyMDExLCBhdCAyOjI1IFBNLCBCZW4gTml2ZW4t SmVua2lucyB3cm90ZToNCj4gDQo+IA0KPiANCj4gCQkJRnJhbmNvaXMsDQo+IA0KPiANCj4gDQo+ IAkJCU9uIDEgRmViIDIwMTEsIGF0IDE5OjAwLCBGcmFuY29pcyBMZSBGYXVjaGV1ciB3cm90ZToN Cj4gDQo+IA0KPiAJCQkJVGhpcyBkaXNjdXNzaW9uIGRyaWZ0ZWQgZnJvbSAoaSkgdGhlIGFiaWxp dHkgdG8NCj4gbGltaXQgdGhlIG51bWJlciBvZiBDRE4gcmVkaXJlY3Rpb25zIChmb3IgdGhlIHNh a2Ugb2YgYXZvaWRpbmcgZGVncmFkYXRpb24NCj4gb2YgdXNlciBleHBlcmllbmNlKSBpbnRvIGEg ZGlzY3Vzc2lvbiBvbiAoaWkpIHByZXZlbnRpbmcgbG9vcHMgaW4gcmVxdWVzdA0KPiB0b3V0aW5n IGFuZCBvdGhlciBpbmZvcm1hdGlvbiBleGNoYW5nZS4NCj4gDQo+IA0KPiANCj4gDQo+IAkJCVRo YXQncyBteSBmYXVsdCBiZWNhdXNlIEkgd2Fzbid0IGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4NCj4g bG9vcCBkZXRlY3Rpb24gb2YgQ0ROIHJlZGlyZWN0aW9ucyBhbmQgb3RoZXIgdHlwZXMgb2YgbG9v cCBkZXRlY3Rpb24uDQo+IA0KPiANCj4gDQo+IAkJCQkoaSkgaXMgYWRkcmVzc2VkIGluOg0KPiAN Cj4gDQo+IAkJCQkiDQo+IA0KPiANCj4gCQkJCVIzNCAgVGhlIENETkkgUmVxdWVzdC1Sb3V0aW5n IEFQSSBTSE9VTEQgc3VwcG9ydA0KPiBvcHRpb25hbCBlbmZvcmNlbWVudA0KPiANCj4gDQo+IAkJ CQkgICAgb2YgYSBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1Y2Nlc3NpdmUgQ0RODQo+IHJlZGly ZWN0aW9ucyBmb3IgYQ0KPiANCj4gDQo+IAkJCQkgICAgZ2l2ZW4gcmVxdWVzdC4NCj4gDQo+IA0K PiAJCQkJIg0KPiANCj4gDQo+IA0KPiAJCQkJKGlpKSBpcyBjdXJyZW50bHkgYWRkcmVzc2VkIGlu IDoNCj4gDQo+IA0KPiANCj4gCQkJCVIzMiAgVGhlIENETkkgUmVxdWVzdC1Sb3V0aW5nIEFQSSBT SE9VTEQgc3VwcG9ydA0KPiByZXF1ZXN0IGxvb3ANCj4gDQo+IA0KPiAJCQkJICAgIGRldGVjdGlv biBhbmQgcHJldmVudGlvbiAoZS5nLiAgUHJldmVudA0KPiByZXF1ZXN0IGxvb3BpbmcgaW4gYQ0K PiANCj4gDQo+IAkJCQkgICAgc2l0dWF0aW9uIHdoZXJlIENETjEgcmVkaXJlY3RzIHRvIENETjIg dGhhdA0KPiByZWRpcmVjdHMgdG8gQ0ROMw0KPiANCj4gDQo+IAkJCQkgICAgdGhhdCB3b3VsZCBy ZWRpcmVjdCB0byBDRE4xKS4NCj4gDQo+IA0KPiANCj4gCQkJCVIzMyAgVGhlIENETkkgUmVxdWVz dC1Sb3V0aW5nIGxvb3AgcHJldmVudGlvbg0KPiBtZWNoYW5pc20gU0hPVUxEIGFsbG93DQo+IA0K PiANCj4gCQkJCSAgICByb3V0aW5nIG9mIHRoZSByZXF1ZXN0IChhcyBvcHBvc2VkIHRvIHRoZQ0K PiByZXF1ZXN0IGxvb3AgYmVpbmcNCj4gDQo+IA0KPiAJCQkJICAgIHNpbXBseSBpbnRlcnJ1cHRl ZCB3aXRob3V0IHJvdXRpbmcgdGhlDQo+IHJlcXVlc3QpLg0KPiANCj4gDQo+IA0KPiAJCQkJKGFz IHdlbGwgYXMgUjM5IGFuZCBSNDAgZm9yIGxvbmdlciB0ZXJtKQ0KPiANCj4gDQo+IA0KPiAJCQkJ UjU1ICBJZiBjYXNjYWRlZCBDRE5zIGFyZSBzdXBwb3J0ZWQgYnkgdGhlIENETkkNCj4gc29sdXRp b24sIHRoZSBDRE5JDQo+IA0KPiANCj4gCQkJCSAgICBNZXRhZGF0YSBBUEkgTVVTVCBwcmV2ZW50 IGxvb3Bpbmcgb2YgQ0ROSQ0KPiBNZXRhZGF0YSBkaXN0cmlidXRpb24NCj4gDQo+IA0KPiAJCQkJ ICAgIGFjcm9zcyBDRE5zLg0KPiANCj4gDQo+IA0KPiAJCQkJRG8geW91IGd1eXMgc3RpbGwgdGhp bmsgc29tZXRoaW5nIGlzIG1pc3Npbmc/DQo+IA0KPiANCj4gCQkJCUNhbiB5b3Ugc3VnZ2VzdCBz b21ldGhpbmcgdG8gY292ZXIgbWlzc2luZyBiaXRzPw0KPiANCj4gDQo+IA0KPiANCj4gCQkJRm9y IENETkkgUmVxdWVzdCBSb3V0aW5nIHRoZSBhYm92ZSBpcyBmaW5lLiBXaGF0IEknbQ0KPiBzYXlp bmcgaXMgSSB0aGluayBsb29wIGRldGVjdGlvbiBhbHNvIGFwcGxpZXMgdG8gdGhlIGNvbnRyb2wg QVBJIGFuZCBtYXkNCj4gYmUgdXNlZnVsIGluIHRoZSBvdGhlciBBUElzLg0KPiANCj4gDQo+IA0K PiAJCQlJJ2QgdGhlcmVmb3JlIHN1Z2dlc3QgbWFraW5nIGxvb3AgZGV0ZWN0aW9uIGEgZ2VuZXJh bA0KPiByZXF1aXJlbWVudCAoU0hPVUxEKSBhbmQgYW55IG1vcmUgc3BlY2lmaWMgcmVxdWlyZW1l bnRzIChlLmcuIFIzMykgdW5kZXINCj4gdGhlIHNwZWNpZmljIEFQSSB0aGV5IGFwcGx5IHRvLg0K PiANCj4gDQo+IA0KPiAJCUkgdGhpbmsgdGhlIHJlcXVpcmVtZW50IGlzIHN0cm9uZ2VyOiBDRE5z IG5lZWQgdG8gYWdyZWUgb24gYQ0KPiBjb21tb24gbWVjaGFuaXNtIGZvciBsb29wIGRldGVjdGlv bjsNCj4gDQo+IA0KPiANCj4gCUkgYWdyZWUgaXQgaXMgYSBNVVNUIChhcyBhbG9uZyBhcyAiY2Fz Y2FkZWQgQ0ROcyIgYXJlIHN1cHBvcnRlZCkuDQo+IAlJbiB0aGUgUmVxdWlyZW1lbnRzIEktRCBp dCB3YXMgcHJlc2VudGVkOg0KPiAJKiBhcyBhICJNVVNUIiBmb3IgbG9uZ2VyIHRlcm0NCj4gCSog YXMgYSAiU0hPVUxEIiBmb3Igc2hvcnRlciB0ZXJtLCBiZWNhdXNlIHN1cHBvcnQgb2YgY2FzY2Fk ZWQgQ0ROcw0KPiBpdHNlbGYgaXMgb25seSBsaXN0ZWQgYXMgYSBTSE9VTEQgZm9yIHRoZSBzaG9y dGVyIHRlcm0gKG9uIHRoZSBncm91bmRzDQo+IHRoYXQgbm90IHN1cHBvcnRpbmcgaXQgbWF5IHBv dGVudGlhbGx5IGFsbG93IGRlZmluaXRpb24gb2YgYSBzaW1wbGVyDQo+IHNvbHV0aW9uIGZhc3Rl cikNCj4gDQo+IAlJIHRoaW5rIHdlIGNvdWxkIGVpdGhlcjoNCj4gDQo+IAkqQSo6DQo+IAkqIGFn cmVlIHJpZ2h0IG5vdyB0aGF0IHRoZSBzaG9ydGVyIHRlcm0gc29sdXRpb24gKGllIHdpdGhpbiBp bml0aWFsDQo+IGNoYXJ0ZXIgc2NvcGUpIE1VU1Qgc3VwcG9ydCBjYXNjYWRlZCBDRE5zDQo+IAkq IGluY2x1ZGUgYSBNVVNUIHJlcXVpcmVtZW50IGZvciBsb29wIHByZXZlbnRpb24gaW4gdGhlIEdl bmVyaWMNCj4gUmVxdHMgc2VjdGlvbiBhbmQgcG9zc2libHkgaW4gZWFjaCBBUEkgc3BlY2lmaWMg c2VjdGlvbiAoQ29udHJvbCwgUmVxdWVzdC0NCj4gUm91dGluZywgTWV0YWRhdGEpDQo+IA0KPiAJ KkI6DQo+IAkqIGRlZmVyIHRoZSBkZWNpc2lvbiBhYm91dCBzdXBwb3J0IG9mIGNhc2NhZGVkIENE TnMgaW4gc2hvcnRlciB0ZXJtDQo+IChpZSB3aXRoaW4gaW5pdGlhbCBjaGFydGVyIHNjb3BlKSB0 byBmdXJ0aGVyIGRpc2N1c3Npb25zDQo+IAkqIGluY2x1ZGUgYSAiY29uZGl0aW9uYWwiIE1VU1Qg KGllICJpZiBjYXNjYWRlZCBDRE5zIGFyZQ0KPiBzdXBwb3J0ZWQsLi4uIikgaW4gdGhlIEdlbmVy aWMgUmVxdHMgc2VjdGlvbiBhbmQgcG9zc2libHkgaW4gZWFjaCBBUEkNCj4gc3BlY2lmaWMgc2Vj dGlvbiAoQ29udHJvbCwgUmVxdWVzdC1Sb3V0aW5nLCBNZXRhZGF0YSkNCj4gDQo+IAlJIHdvdWxk IHZvdGUgZm9yICpBKiBiZWNhdXNlOg0KPiAJKiB3ZSB3b3VsZG4ndCB3YW50IHRvIGdvIGZvciBh IHNob3J0ZXIgdGVybSBzb2x1dGlvbiB0aGF0IGNhbm5vdCBiZQ0KPiBlYXNpbHkgZXh0ZW5kZWQg dG8gc3VwcG9ydCBjYXNjYWRlZCBDRE5zDQo+IAkqIHRoZXJlIGFyZSBzaG9ydCB0ZXJtIHVzZSBj YXNlcyBmb3IgY2FzY2FkZWQgQ0ROcy4NCj4gDQo+IAlvdGhlciB2b3RlcnM/DQo+IA0KPiAJVGhh bmtzDQo+IA0KPiAJRnJhbmNvaXMNCj4gDQo+IA0KPiANCj4gCQlvdGhlcndpc2UgeW91IGNhbiBn ZXQgbXVsdGlwbGljYXRpdmUgbG9vcCBkaWFtZXRlcnMgYW5kDQo+IGVmZmVjdGl2ZWx5IG5vdCBo YXZlIHVzZWZ1bCBsb29wIGRldGVjdGlvbiB3aGVuIHRoZSBub24tbG9vcGluZyBwYXRocyBhcmUN Cj4gbG9uZy4gVGhpcyBpcyByb3V0aW5nOyB3ZSBrbm93IHdoYXQgaGFwcGVucyB3aGVuIHlvdSBk byBsb29wIGRldGVjdCB3aXRoDQo+IHRoaW5nIGxpa2UgY291bnQtdG8taW5maW5pdHkuDQo+IA0K PiANCj4gDQo+IAkJSW5jaWRlbnRseSwgbXkgZmF2b3JpdGUgbG9vcCBkZXRlY3Rpb24gc2NoZW1l IHdhcyBpbnZlbnRlZCBieQ0KPiBLbnV0aCBhbGwgdGhlIHdheSBiYWNrIGluIHZvbHVtZSAyLiBJ dCBoYXMgdGhlIG5pY2UgcHJvcGVydHkgb2YgZGV0ZWN0aW5nDQo+IGxvb3BzIGluIGNvbnN0YW50 IG1lbW9yeSBhbmQgd2l0aCBhbiB1cHBlciBib3VuZCBvZiB0cmF2ZXJzaW5nIHRoZSBsb29wIDIN Cj4gdGltZXMsIGZvciBhbGwgbG9vcCBkaWFtZXRlcnMuIExvb2sgaXQgdXAgLSBpdCdzIGNhbGxl ZCB0aGUgImV2ZW4tb2RkDQo+IGl0ZXJhdGlvbiBjb3VudGluZyIuDQo+IA0KPiANCj4gDQo+IAkJ RGF2ZU8uDQo+IA0KPiANCj4gDQo+IA0KPiAJCQlUaGFua3MNCj4gDQo+IA0KPiAJCQlCZW4NCj4g DQo+IA0KPiANCj4gDQo+IAkJCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IA0KPiANCj4gCQkJQ0ROaSBtYWlsaW5nIGxpc3QNCj4gDQo+IA0KPiAJCQlD RE5pQGlldGYub3JnDQo+IA0KPiANCj4gCQkJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jZG5pDQo+IA0KPiANCj4gDQo+IA0KPiAJX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gCUNETmkgbWFpbGluZyBsaXN0DQo+IAlDRE5pQGll dGYub3JnDQo+IAlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCj4g DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRnJhbmNvaXMgTGUgRmF1Y2hldXINCj4gRGlzdGluZ3Vp c2hlZCBFbmdpbmVlcg0KPiBDb3Jwb3JhdGUgRGV2ZWxvcG1lbnQNCj4gZmxlZmF1Y2hAY2lzY28u Y29tDQo+IFBob25lOiArMzMgNDkgNzIzIDI2MTkNCj4gTW9iaWxlOiArMzMgNiAxOSA5OCA1MCA5 MA0KPiANCj4gDQo+IA0KPiANCj4gCUNpc2NvIFN5c3RlbXMgRnJhbmNlDQo+IEdyZWVuc2lkZQ0K PiA0MDAgQXZlIGRlIFJvdW1hbmlsbGUNCj4gMDY0MTAgU29waGlhIEFudGlwb2xpcw0KPiBGcmFu Y2UNCj4gQ2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2NvLmNvbT4NCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+ICBUaGluayBiZWZvcmUgeW91IHByaW50Lg0KPiANCj4gVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlDQo+IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlDQo+IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50DQo+IChvciBhdXRob3Jp emVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5DQo+IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3Nh Z2UuDQo+IA0KPiBDaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlp dMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZQ0KPiBEZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMg WmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxlcyBNb3VsaW5lYXV4LA0KPiBBdSBj YXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50ZXJyZSwgRGlyZWN0ZXVy IGRlIGxhDQo+IHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25lLg0KPiANCj4gRm9y IGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCj4gaHR0cDovL3d3dy5jaXNjby5j b20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQo+IA0KPiAN Cg0K From flefauch@cisco.com Mon Feb 7 00:59:25 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C413A6CF1 for ; Mon, 7 Feb 2011 00:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.062 X-Spam-Level: X-Spam-Status: No, score=-8.062 tagged_above=-999 required=5 tests=[AWL=-2.538, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmuuYQN1hVXc for ; Mon, 7 Feb 2011 00:59:22 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 748303A6CFA for ; Mon, 7 Feb 2011 00:59:20 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg, green.gif : 11041, 87 Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Feb 2011 08:59:23 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p178xKrO023108; Mon, 7 Feb 2011 08:59:20 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-133-934419046 From: Francois Le Faucheur In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> Date: Mon, 7 Feb 2011 09:59:58 +0100 Message-Id: <230BC412-AADC-45DF-A14D-C29706B9C9FE@cisco.com> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:59:25 -0000 --Apple-Mail-133-934419046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Emile, On 7 Feb 2011, at 09:28, = wrote: > Hi Francois, >=20 > CDNI interfaces must support loop detection even when there is only 2 = CDNs interconnected. It is true that the CDNI solution needs to support loop prevention even = when there is only 2 CDNs. The solution (and thus what is supported by CDNI APIs) could potentially = be simpler with only 2 CDNs, but the requirement holds in any case. > Hence this req is tied nor to the number of CDNs of the CDNi chain nor = to its nature. >=20 > So imo support for loop detection is a generic MUST that applies to = each CDNi APIs.=20 >=20 > I suggest inserting this req directly in the header of the section 3 = of the req draft.=20 That makes sense (as a requirement on the "CDNI Solution", which may be = later translated into possibly more specific requirements on individual = APIs). Thanks Francois >=20 > Regards > Emile >=20 >=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de >> Francois Le Faucheur >> Envoy=E9 : jeudi 3 f=E9vrier 2011 11:29 >> =C0 : philip.eardley@bt.com >> Cc : mvittal@cisco.com; cdni@ietf.org; Yiu_Lee@Cable.Comcast.com >> Objet : Re: [CDNi] Limit nb of redirects & loop sRe: CDNI = Requirements I-D >>=20 >> Hi Phil, >>=20 >> On 3 Feb 2011, at 11:18, wrote: >>=20 >>=20 >> Cascaded CDNs would be nice. >>=20 >> Cascading is missing from the logging section - where it seems = hard. >> 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. >>=20 >>=20 >> There are requirements in the Security section that relate to that: >>=20 >> " >> R71 The CDNI solution MUST be able to ensure that for any given >> request redirected to a Downstream CDN, the chain of CDN >> Delegation (leading to that request being served by that CDN) >> can be established with non-repudiation. >>=20 >> 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. >> " >>=20 >> This is meant to apply also to the Logging API. >> Is that sufficient to capture the topic or do you want to see a = specific >> requirement under the "Logging API" section? >>=20 >>=20 >>=20 >> This is quite challenging, especially if one allows any = flexibility >> over what is reported, format of reports, security methods, real-time >> reports, etc. >>=20 >>=20 >>=20 >> Agree that cascading should be mentioned as a generic = requirement - >> and we treat it at the same requirements level for all the APIs = (whether >> that's: MUST in initial scope, SHOULD, or beyond initial scope). >>=20 >> Personally think there is quite a lot "within initial scope" in = the >> requirements draft, and cascading might be deferrable if it adds >> significant work to standardising the APIs - as most of the value of = CDN >> interconnect seems to come from the "one hop" case ie: >> CSP -> Upstream CDN -> Downstream CDN -> UA >>=20 >>=20 >>=20 >> I take this as a "B" Vote. >>=20 >> Thanks >>=20 >> Francois >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf >> Of Francois Le Faucheur >> Sent: 02 February 2011 10:45 >> To: David R Oran >> Cc: cdni@ietf.org; Viveganandhan Mahesh; Yiu Lee >> Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI >> Requirements I-D >>=20 >> Dave and all, >>=20 >> On 2 Feb 2011, at 01:53, David R Oran wrote: >>=20 >>=20 >>=20 >>=20 >> On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote: >>=20 >>=20 >>=20 >> Francois, >>=20 >>=20 >>=20 >> On 1 Feb 2011, at 19:00, Francois Le Faucheur = wrote: >>=20 >>=20 >> This discussion drifted from (i) the = ability to >> limit the number of CDN redirections (for the sake of avoiding = degradation >> of user experience) into a discussion on (ii) preventing loops in = request >> touting and other information exchange. >>=20 >>=20 >>=20 >>=20 >> That's my fault because I wasn't distinguishing = between >> loop detection of CDN redirections and other types of loop detection. >>=20 >>=20 >>=20 >> (i) is addressed in: >>=20 >>=20 >> " >>=20 >>=20 >> R34 The CDNI Request-Routing API SHOULD = support >> optional enforcement >>=20 >>=20 >> of a limit on the number of = successive CDN >> redirections for a >>=20 >>=20 >> given request. >>=20 >>=20 >> " >>=20 >>=20 >>=20 >> (ii) is currently addressed in : >>=20 >>=20 >>=20 >> R32 The CDNI Request-Routing API SHOULD = support >> request loop >>=20 >>=20 >> detection and prevention (e.g. = Prevent >> request looping in a >>=20 >>=20 >> situation where CDN1 redirects to = CDN2 that >> redirects to CDN3 >>=20 >>=20 >> that would redirect to CDN1). >>=20 >>=20 >>=20 >> R33 The CDNI Request-Routing loop = prevention >> mechanism SHOULD allow >>=20 >>=20 >> routing of the request (as opposed = to the >> request loop being >>=20 >>=20 >> simply interrupted without routing = the >> request). >>=20 >>=20 >>=20 >> (as well as R39 and R40 for longer term) >>=20 >>=20 >>=20 >> R55 If cascaded CDNs are supported by = the CDNI >> solution, the CDNI >>=20 >>=20 >> Metadata API MUST prevent looping of = CDNI >> Metadata distribution >>=20 >>=20 >> across CDNs. >>=20 >>=20 >>=20 >> Do you guys still think something is = missing? >>=20 >>=20 >> Can you suggest something to cover = missing bits? >>=20 >>=20 >>=20 >>=20 >> For CDNI Request Routing the above is fine. What = I'm >> saying is I think loop detection also applies to the control API and = may >> be useful in the other APIs. >>=20 >>=20 >>=20 >> I'd therefore suggest making loop detection a = general >> requirement (SHOULD) and any more specific requirements (e.g. R33) = under >> the specific API they apply to. >>=20 >>=20 >>=20 >> I think the requirement is stronger: CDNs need to agree = on a >> common mechanism for loop detection; >>=20 >>=20 >>=20 >> I agree it is a MUST (as along as "cascaded CDNs" are = supported). >> In the Requirements I-D it was presented: >> * as a "MUST" for longer term >> * as a "SHOULD" for shorter term, because support of cascaded = CDNs >> itself is only listed as a SHOULD for the shorter term (on the = grounds >> that not supporting it may potentially allow definition of a simpler >> solution faster) >>=20 >> I think we could either: >>=20 >> *A*: >> * agree right now that the shorter term solution (ie within = initial >> charter scope) MUST support cascaded CDNs >> * include a MUST requirement for loop prevention in the Generic >> Reqts section and possibly in each API specific section (Control, = Request- >> Routing, Metadata) >>=20 >> *B: >> * defer the decision about support of cascaded CDNs in shorter = term >> (ie within initial charter scope) to further discussions >> * include a "conditional" MUST (ie "if cascaded CDNs are >> supported,...") in the Generic Reqts section and possibly in each API >> specific section (Control, Request-Routing, Metadata) >>=20 >> I would vote for *A* because: >> * we wouldn't want to go for a shorter term solution that cannot = be >> easily extended to support cascaded CDNs >> * there are short term use cases for cascaded CDNs. >>=20 >> other voters? >>=20 >> Thanks >>=20 >> Francois >>=20 >>=20 >>=20 >> otherwise you can get multiplicative loop diameters and >> effectively not have useful loop detection when the non-looping paths = are >> long. This is routing; we know what happens when you do loop detect = with >> thing like count-to-infinity. >>=20 >>=20 >>=20 >> Incidently, my favorite loop detection scheme was = invented by >> Knuth all the way back in volume 2. It has the nice property of = detecting >> loops in constant memory and with an upper bound of traversing the = loop 2 >> times, for all loop diameters. Look it up - it's called the "even-odd >> iteration counting". >>=20 >>=20 >>=20 >> DaveO. >>=20 >>=20 >>=20 >>=20 >> Thanks >>=20 >>=20 >> Ben >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >>=20 >> CDNi mailing list >>=20 >>=20 >> CDNi@ietf.org >>=20 >>=20 >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Francois Le Faucheur >> Distinguished Engineer >> Corporate Development >> flefauch@cisco.com >> Phone: +33 49 723 2619 >> Mobile: +33 6 19 98 50 90 >>=20 >>=20 >>=20 >>=20 >> Cisco Systems France >> Greenside >> 400 Ave de Roumanille >> 06410 Sophia Antipolis >> France >> Cisco.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Think before you print. >>=20 >> 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. >>=20 >> Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille >> Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les = Moulineaux, >> Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la >> publication: Jean-Luc Michel Givone. >>=20 >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com 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 =20 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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 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 --Apple-Mail-133-934419046 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-134-934419046 --Apple-Mail-134-934419046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Emile,


Hi = Francois,

CDNI interfaces must support loop detection even when = there is only 2 CDNs interconnected. =

It is true that the CDNI solution = needs to support loop prevention even when there is only 2 = CDNs.
The solution (and thus what is supported by CDNI APIs) = could potentially be simpler with only 2 CDNs, but the requirement holds = in any case.

Hence this req is = tied nor to the number of CDNs of the CDNi chain nor to its = nature.

So imo support for loop detection is a generic MUST that = applies to each CDNi APIs.

I suggest inserting this req directly = in the header of the section 3 of the req draft. =

That makes sense (as a = requirement on the "CDNI Solution", which may be later translated into = possibly more specific requirements on individual = APIs).

Thanks

Francois

Regards
Emile


-----Message d'origine-----
De : cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] De la part de
Francois Le Faucheur
Envoy=E9 : jeudi 3 f=E9vrier 2011 = 11:29
=C0 : philip.eardley@bt.com
Cc : mvittal@cisco.com; cdni@ietf.org; Yiu_Lee@Cable.Comcast.com
Objet : Re: [CDNi] Limit nb = of redirects & loop sRe: CDNI Requirements = I-D

Hi Phil,

On 3 Feb 2011, = at 11:18, <philip.eardley@bt.com> = wrote:


Cascaded = CDNs would be nice.

Cascading = is missing from the logging section - where it seems = hard.
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.


There are = requirements in the Security section that relate to = that:

"
=   R71  The CDNI solution MUST be able to ensure that for = any given
=        request redirected to a = Downstream CDN, the chain of CDN
       Delegation = (leading to that request being served by that = CDN)
=        can be established with = non-repudiation.

=   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.
"

This is meant = to apply also to the Logging API.
Is that sufficient to capture the topic or do you want to = see a specific
requirement = under the "Logging API" section?



This is = quite challenging, especially if one allows any = flexibility
over what is = reported, format of reports, security methods, = real-time
reports, = etc.



Agree = that cascading should be mentioned as a generic requirement = -
and we treat it at the same = requirements level for all the APIs (whether
that's: MUST in initial scope, SHOULD, or beyond initial = scope).

= Personally think there is quite a lot "within initial scope" in = the
requirements draft, and = cascading might be deferrable if it adds
significant work to standardising the APIs - as most of = the value of CDN
interconnect = seems to come from the "one hop" case ie:
= CSP -> Upstream CDN -> Downstream CDN -> = UA



I take this as = a "B" Vote.

Thanks

Francois




= -----Original Message-----
= From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf
Of Francois Le Faucheur
= Sent: 02 February 2011 10:45
= To: David R Oran
Cc: cdni@ietf.org; Viveganandhan Mahesh; = Yiu Lee
Subject: = Re: [CDNi] Limit nb of redirects & loop sRe: = CDNI
Requirements = I-D

= Dave and all,

On 2 Feb = 2011, at 01:53, David R Oran wrote:




On Feb 1, = 2011, at 2:25 PM, Ben Niven-Jenkins wrote:



= Francois,



On 1 Feb = 2011, at 19:00, Francois Le Faucheur wrote:


This = discussion drifted from (i) the ability to
limit the number of CDN redirections (for the sake of = avoiding degradation
of user = experience) into a discussion on (ii) preventing loops in = request
touting and other = information exchange.




That's my = fault because I wasn't distinguishing = between
loop detection of CDN = redirections and other types of loop = detection.



(i) is = addressed in:


= "


R34 =  The CDNI Request-Routing API SHOULD = support
optional = enforcement


=    of a limit on the number of successive = CDN
redirections for = a


=    given request.


= "



(ii) is = currently addressed in :



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).



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).



(as well = as R39 and R40 for longer term)



R55 =  If cascaded CDNs are supported by the = CDNI
solution, the = CDNI


=    Metadata API MUST prevent looping of = CDNI
Metadata = distribution


=    across CDNs.



Do you = guys still think something is missing?


Can you = suggest something to cover missing bits?




For CDNI = Request Routing the above is fine. What I'm
saying is I think loop detection also applies to the = control API and may
be useful = in the other APIs.



I'd = therefore suggest making loop detection a = general
requirement (SHOULD) = and any more specific requirements (e.g. R33) = under
the specific API they = apply to.



I think = the requirement is stronger: CDNs need to agree on = a
common mechanism for loop = detection;



I agree = it is a MUST (as along as "cascaded CDNs" are = supported).
In the = Requirements I-D it was presented:
= * as a "MUST" for longer term
= * as a "SHOULD" for shorter term, because support of cascaded = CDNs
itself is only listed as = a SHOULD for the shorter term (on the = grounds
that not supporting it = may potentially allow definition of a = simpler
solution = faster)

I think = we could either:

= *A*:
* agree = right now that the shorter term solution (ie within = initial
charter scope) MUST = support cascaded CDNs
* include = a MUST requirement for loop prevention in the = Generic
Reqts section and = possibly in each API specific section (Control, = Request-
Routing, = Metadata)

= *B:
* defer = the decision about support of cascaded CDNs in shorter = term
(ie within initial = charter scope) to further discussions
= * include a "conditional" MUST (ie "if cascaded CDNs = are
supported,...") in the = Generic Reqts section and possibly in each = API
specific section (Control, = Request-Routing, Metadata)

I would = vote for *A* because:
* we = wouldn't want to go for a shorter term solution that cannot = be
easily extended to support = cascaded CDNs
* there = are short term use cases for cascaded CDNs.

other = voters?

= Thanks

= Francois



otherwise = you can get multiplicative loop diameters = and
effectively not have = useful loop detection when the non-looping paths = are
long. This is routing; we = know what happens when you do loop detect = with
thing like = count-to-infinity.



= Incidently, my favorite loop detection scheme was invented = by
Knuth all the way back in = volume 2. It has the nice property of = detecting
loops in constant = memory and with an upper bound of traversing the loop = 2
times, for all loop = diameters. Look it up - it's called the = "even-odd
iteration = counting".



= DaveO.




= Thanks


= Ben




= _______________________________________________


CDNi = mailing list


CDNi@ietf.org


https://www.ietf.org/m= ailman/listinfo/cdni




= _______________________________________________
CDNi mailing = list
CDNi@ietf.org
= https://www.ietf.org/m= ailman/listinfo/cdni






Francois Le = Faucheur
Distinguished = Engineer
Corporate = Development
flefauch@cisco.com
=
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 <http://www.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=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille
Desmoulins =96 Imm = Atlantis Zac Forum Seine Ilot 7 92130 Issy les = Moulineaux,
Au capital de = 91.470 =80, 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






Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

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

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-134-934419046 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-134-934419046-- --Apple-Mail-133-934419046-- From ben@niven-jenkins.co.uk Mon Feb 7 02:56:08 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27873A6DA0 for ; Mon, 7 Feb 2011 02:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C+Y9k+gQajG for ; Mon, 7 Feb 2011 02:56:07 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 0BCD93A6BDD for ; Mon, 7 Feb 2011 02:56:06 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-144-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PmOlL-0000A6-UU; Mon, 07 Feb 2011 10:56:09 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 7 Feb 2011 10:56:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF73AB3-B934-424B-ABCC-2B25048DE0FC@niven-jenkins.co.uk> References: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on CDNI Requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 10:56:08 -0000 Philip, Some comments inline. On 3 Feb 2011, at 14:58, = wrote: > It isn=92t exactly clear what MUST, SHOULD and MAY mean in a = requirements doc. We assume something like: > MUST =96 the protocol will have to do this > SHOULD =96 the WG will very likely do this. Further discussion is = needed, either about whether it definitely is needed &/or about whether = it=92s too tricky for the protocol to achieve during the phase covered = by the initial charter. > MAY =96 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=92t do this, unless it happens to be naturally included = within something else. When I have been involved in documenting requirements in the routing = area (e.g. RFC5654) the approach I have taken is that the requirements = are for describing the behaviour of the protocol mechanisms and = procedures and are not requirements on the WG as such. Work in the WG is = driven by the what WG participants are prepared to undertake. = Implementations may not implement all requirements.=20 Therefore IMO the requirements translate roughly to: MUST - protocol solution specifications must include support for this as = it is a key requirement for the solution to work/be deployable/be = acceptable to users of the solution. SHOULD - A strong recommendation to include in protocol solution = specifications that should only be omitted with good justification e.g. = solution is only addressing a subset of use cases. MAY - optional in protocol solutions but some participants felt it was = important to have it articulated explicitly rather than assuming readers = will infer it implicitly. =20 > =20 > R2 > MUST not =3D> MUST NOT > =20 > R4 The CDNI solution MUST support delivery to the user agent based > on HTTP [ RFC 3040 [RFC2616]]. > =20 > R5 The CDNI solution MUST support acquisition across CDNs based on > HTTP [ RFC 3040 [RFC2616]]. > =20 > R6 The CDNI solution MAY support delivery to the user agent based = on > other protocols than HTTP. > =20 > R7 The CDNI solution MAY support acquisition across CDNs based on > other protocols than HTTP. > =20 > R4 =96 R7 all seem out of scope, since they=92re about content = acquisition > =20 IMO specifying how to actually deliver/acquire using HTTP is out of = scope, but it is useful to include these as general requirements as = there will be HTTP specific metadata that needs to be supported. I read = these as meaning "you better support HTTP delivery and define the = associated metadata etc. later on we'll likely want other protocols too = so don't focus your solution too narrowly but don't get obsessed with = how to encode RTMP/RTSP/etc related metadata in the initial solution" > 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.). > =20 > R8 would fit better in the Request Routing section. topology is not just related to request routing. E.g. metadata discovery = resulting from a surrogate receiving a request from a UA for content it = has not delivered before, support for reporting logs/events where the = inter-CDN topology may not be a tree etc. > don=92t 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. Also, it seems more = logical to keep the requirement here (within CDNI Control API) than move = it to the Request Routing API. I know it's not directly related to your comment, but personally I think = we shouldn't get too hung up on pre-positioning of content. We do need = to support it and therefore ensure we do not build initial solutions = that preclude it but pre-positioning is something I'd put in the = category of "customers always ask for it in RFPs and then rarely use it" = as its applicability is generally limited because once you start = supporting multiple content catalogues from multiple CSPs it becomes = very difficult to drive optimum efficiency from the CDN with = pre-positioning because the arrival rate of requests for specific = content and the spread of requests for different content is so dynamic.=20= I think we need to be conscious that there is a difference between: 1) A CSP wanting to "pre-position" content into the CDN storage platform = because the CSP does not want to operate their own origin server = infrastructure 2) A CSP wants the control to "pre-position" content to specific CDN = regions or surrogates, etc. (1) is a definite requirement on CDNs today and doesn't place any = additional requirements on a CDNI solution IMO whereas (2) does. My = comments above relate to (2). > 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). > =20 > 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. > =20 > We don=92t really understand why these requirements have been split = like this =96 I didn't author these requirements but they reflect the way CDNs are = typically deployed and DNS Vs HTTP-based request routing is done today. = E.g. small objects (think website acceleration) is typically done via = DNS based redirection whereas large object (think large file download) = is often done using HTTP redirection. > suggest rearrange as: > R28 =96 MUST support http-based and DNS-based request routing > R29 =96 MUST support both small & large objects and caching vs = not-cached=20 > Not sure if R29 needs to be said explicitly? I think we do need to explicitly mention both small & large objects as = the requirements they place on the CDN differ. I'd posit that if you = were to take a CDN product from a vendor that had only considered large = object delivery in its design and tried to use it for website caching of = small objects its performance would be pretty dire. > R28 may be worth discussing, as this might appear directly in the = proposed charter. Do people believe=20 > - The proposed WG needs to support both http-based and DNS-based = request routing Yes. I could possibly accept a staging of supporting one first and the = other later if it's felt the initial amount of work is too much. IMO = though the amount of difference between the two solutions at the CDNI = solution level is not that great. > - The proposed WG does NOT do any others Never say never but as a starting point I think DNS & HTTP are = sufficient to cover all the stated requirements. > We think both these points are ok. > =20 > R30 & R31 > ... The CDNI Request-Routing =20 > architecture MUST support recursive request routing. > ... The CDNI > Request-Routing architecture MUST support iterative request > routing. > =20 > There is a lot of =93definition=94 text (defining Recursive & = Iterative) that could be removed with a good definition in another = draft. There is a =93starter for 10=94 proposed definition in the Use = cases draft. http://tools.ietf.org/html/draft-bertrand-cdni-use-cases . = then we could have=20 Good point. I think a clear definition of recursive Vs iterative will = help us avoid a lot of confusion in the long run as new people try to = understand the differences between some of the possible deployment = models. I'm fairly easy about which document such a definition goes in. > Rx: The CDNI Request-Routing architecture MUST support recursive = request routing and iterative request routing. > =20 > 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=92s address. = Whereas in the Recursive case the UA sends the request to CDN-A, & CDN-A = replies with the surrogate=92s address (in the meantime CDN-A sends a = request to CDN-B which replies to CDN-A with the surrogate=92s address). = Note that the text in R30 seems to describe the iterative case, & R31 = the recursive one. I like this as a clear description of the differences. > 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. I will try and come up with some proposed text this week (based on some = of the text that was in your e-mail) which I will share on the list and = if we can form a consensus around it we can include it in the next = revision of the problem statement. Regards Ben From abegen@cisco.com Mon Feb 7 08:46:58 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C503A6E08 for ; Mon, 7 Feb 2011 08:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XleW8D26+4uJ for ; Mon, 7 Feb 2011 08:46:57 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 072AE3A6D6E for ; Mon, 7 Feb 2011 08:46:57 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEuxT02rRN+K/2dsb2JhbAClMnOfFZp7gxCCSgSEeooh Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 07 Feb 2011 16:47:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p17Gl1U5021748; Mon, 7 Feb 2011 16:47:01 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 08:47:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 08:46:57 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for 3GPP and MPEG portions Thread-Index: AcvG5EigeZvayDUpRLCfGyaMu/dIYgAAkVFA From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 07 Feb 2011 16:47:01.0472 (UTC) FILETIME=[A47E7600:01CBC6E6] Subject: [CDNi] Proposed text for 3GPP and MPEG portions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:46:58 -0000 Hi everyone, The current problem statement draft talks about other related = standardization activities. 6.1.2 mentions 3GPP. Following up my = conversation with Francois, he asked me to provide a bit more details on = the developments in 3GPP as well as MPEG. With Francois' input, I think the following text would be good to = incorporate in the draft. It proposes some changes in 6.1.2 and adds a = new section (preferably right after 6.1.2) for MPEG. Also note that = 3GPP's method is called 3GP-DASH and MPEG's version is called MPEG DASH. = The text should be updated throughout the draft appropriately. Below is = also the revised list of references. -acbegen 6.1.2. 3GPP 3GPP is the first organization that released a specification related to = adaptive streaming over HTTP. 3GPP Release 9 was published in March = 2010, and the SA4 Working Group is currently in the process of = bug-fixing this specification taking into account experience from the = first implementations. In addition, 3GPP is preparing an extended = version for Release 10, which is scheduled to be published later in = 2011. This release will include a number of clarifications, offer = improvements and add new features. [3GP-DASH] is defined as a general framework independent of the data = encapsulation format. It has support for fast initial startup and = seeking, adaptive bitrate switching, re-use of HTTP origin and cache = servers, re-use of existing media playout engines, on-demand, live and = time-shifted delivery. It specifies syntax and semantics of Media = Presentation Description (MPD), format of segments and delivery protocol = for segments. It does not specify content provisioning, client behavior = or transport of MPD. The content retrieved by a client using 3GP-DASH adaptive streaming = could be obtained from a CDN but this is not discussed or specified in = the 3GPP specifications as it is transparent to 3GP-DASH operations. = Similarly, it is expected that=20 3GP-DASH can be used transparently from the CDNs as a delivery protocol = (between the delivering CDN surrogate and the User Agent) in a CDN = Interconnect environment. 3GP-DASH could also be a candidate for content = acquisition between CDNs in a CDN Interconnect environment. 6.1.3 MPEG On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) Ad Hoc = Group has adopted the 3GPP Release 9 as a baseline specification and = started running several evaluation experiments to evaluate the submitted = proposals. The DASH Ad Hoc Group is working on standardizing the = manifest file, delivery format, conversion from/to existing file formats = and the use of MPEG2 Transport Streams as a media format. The MPEG DASH = specification could also be a candidate for delivery to the user agent = and for content acquisition between CDNs in a CDN Interconnect = environment. The Draft International Standard (DIS) version [MPEG-DASH] = should be publicly available at = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B in early = February. In the 95th MPEG meeting in January 2011, the DASH Ad Hoc Group has = decided to start a new evaluation experiment called "CDN-EE". The goals = are to understand the requirements for MPEG DASH to better support = CDN-based delivery, and to provide a guidelines document for CDN = operators to better support MPEG DASH streaming services. The ongoing = work is still very preliminary and does not currently target looking = into CDN Interconnect issues. [3GP-DASH] "Transparent end-to-end Packet-switched Streaming Service (PSS); = Progressive Download and Dynamic Adaptive Streaming over HTTP = (3GP-DASH)" http://www.3gpp.org/ftp/Specs/html-info/26247.htm=20 [MPEG-DASH] =93Information technology =97 MPEG systems technologies =97 = Part 6: Dynamic adaptive streaming over HTTP (DASH),=94 (DIS version), = February 2011 http://mpeg.chiariglione.org/working_documents.htm#MPEG-B=20 From ben@niven-jenkins.co.uk Mon Feb 7 13:51:49 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF963A6A48 for ; Mon, 7 Feb 2011 13:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD-vaDGxaKaE for ; Mon, 7 Feb 2011 13:51:46 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 7621F3A69AE for ; Mon, 7 Feb 2011 13:51:46 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PmYzt-0005aJ-P4; Mon, 07 Feb 2011 21:51:50 +0000 References: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Message-Id: <000CB231-D904-4791-B659-4305E4221CC5@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Mon, 7 Feb 2011 21:51:47 +0000 To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org, cdni@ietf.org Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:51:49 -0000 Ali, Thanks for proposing some improved text. If no-one objects we'll = incorporate your proposal in the next version of the problem statement. Ben On 7 Feb 2011, at 16:46, Ali C. Begen (abegen) wrote: > Hi everyone, >=20 > The current problem statement draft talks about other related = standardization activities. 6.1.2 mentions 3GPP. Following up my = conversation with Francois, he asked me to provide a bit more details on = the developments in 3GPP as well as MPEG. >=20 > With Francois' input, I think the following text would be good to = incorporate in the draft. It proposes some changes in 6.1.2 and adds a = new section (preferably right after 6.1.2) for MPEG. Also note that = 3GPP's method is called 3GP-DASH and MPEG's version is called MPEG DASH. = The text should be updated throughout the draft appropriately. Below is = also the revised list of references. >=20 > -acbegen >=20 >=20 >=20 > 6.1.2. 3GPP >=20 > 3GPP is the first organization that released a specification related = to adaptive streaming over HTTP. 3GPP Release 9 was published in March = 2010, and the SA4 Working Group is currently in the process of = bug-fixing this specification taking into account experience from the = first implementations. In addition, 3GPP is preparing an extended = version for Release 10, which is scheduled to be published later in = 2011. This release will include a number of clarifications, offer = improvements and add new features. >=20 > [3GP-DASH] is defined as a general framework independent of the data = encapsulation format. It has support for fast initial startup and = seeking, adaptive bitrate switching, re-use of HTTP origin and cache = servers, re-use of existing media playout engines, on-demand, live and = time-shifted delivery. It specifies syntax and semantics of Media = Presentation Description (MPD), format of segments and delivery protocol = for segments. It does not specify content provisioning, client behavior = or transport of MPD. >=20 > The content retrieved by a client using 3GP-DASH adaptive streaming = could be obtained from a CDN but this is not discussed or specified in = the 3GPP specifications as it is transparent to 3GP-DASH operations. = Similarly, it is expected that=20 > 3GP-DASH can be used transparently from the CDNs as a delivery = protocol (between the delivering CDN surrogate and the User Agent) in a = CDN Interconnect environment. 3GP-DASH could also be a candidate for = content acquisition between CDNs in a CDN Interconnect environment. >=20 > 6.1.3 MPEG >=20 > On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) Ad = Hoc Group has adopted the 3GPP Release 9 as a baseline specification and = started running several evaluation experiments to evaluate the submitted = proposals. The DASH Ad Hoc Group is working on standardizing the = manifest file, delivery format, conversion from/to existing file formats = and the use of MPEG2 Transport Streams as a media format. The MPEG DASH = specification could also be a candidate for delivery to the user agent = and for content acquisition between CDNs in a CDN Interconnect = environment. The Draft International Standard (DIS) version [MPEG-DASH] = should be publicly available at = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B in early = February. >=20 > In the 95th MPEG meeting in January 2011, the DASH Ad Hoc Group has = decided to start a new evaluation experiment called "CDN-EE". The goals = are to understand the requirements for MPEG DASH to better support = CDN-based delivery, and to provide a guidelines document for CDN = operators to better support MPEG DASH streaming services. The ongoing = work is still very preliminary and does not currently target looking = into CDN Interconnect issues. >=20 > [3GP-DASH] > "Transparent end-to-end Packet-switched Streaming Service (PSS); = Progressive Download and Dynamic Adaptive Streaming over HTTP = (3GP-DASH)" http://www.3gpp.org/ftp/Specs/html-info/26247.htm=20 >=20 > [MPEG-DASH] =93Information technology =97 MPEG systems technologies =97 = Part 6: Dynamic adaptive streaming over HTTP (DASH),=94 (DIS version), = February 2011 http://mpeg.chiariglione.org/working_documents.htm#MPEG-B=20= > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Feb 8 08:55:54 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3318B3A67A5 for ; Tue, 8 Feb 2011 08:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwvmjyHanf0j for ; Tue, 8 Feb 2011 08:55:53 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 2C0C73A679F for ; Tue, 8 Feb 2011 08:55:53 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-144-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pmqr9-0005tR-AS for cdni@ietf.org; Tue, 08 Feb 2011 16:55:59 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 16:55:59 +0000 Message-Id: <43441C04-B435-445F-B457-79C901A7C337@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Thoughts on Naming of Data Objects within CDNI X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:55:54 -0000 Colleagues, Following a couple of private comments and an offline discussion with = Francois I've written down some thoughts on naming (i.e. referencing) of = the data types within a CDNI solution in order to attempt to demonstrate = that although a CDNI solution will require definition & use of multiple = different types of data object when it comes to naming (or referencing) = data objects they can be fairly easily categorised and the number of = categories required is much smaller than the number of different data = types within the solution. You can access the draft here: http://tools.ietf.org/html/draft-jenkins-cdni-names-00 Comments are welcomed as always. Regards Ben On 08/02/2011 16:44, "IETF I-D Submission Tool" = wrote: A new version of I-D, draft-jenkins-cdni-names-00.txt has been = successfully submitted by Ben Niven-Jenkins and posted to the IETF = repository. Filename: draft-jenkins-cdni-names Revision: 00 Title: Thoughts on Naming and Referencing of Data Objects within = Content Distribution Network Interconnection (CDNI) solutions Creation_date: 2011-02-08 WG ID: Independent Submission Number_of_pages: 7 Abstract: As part of the development of protocols and solutions for CDNI it will be necessary to agree on common mechanisms for how to identify and name the data objects that are to be interchanged between interconnected CDNs, as well as how to describe which policy should be used when doing so. This document presents some thoughts on the naming and referencing of data types/objects within a CDNI solution. = =20 The IETF Secretariat. From yekui.wang@huawei.com Wed Feb 9 04:30:57 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F6E3A6945 for ; Wed, 9 Feb 2011 04:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sSiOEwNRHNg for ; Wed, 9 Feb 2011 04:30:55 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id ADC0E3A6984 for ; Wed, 9 Feb 2011 04:30:55 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGC00BUOO3SGX@usaga02-in.huawei.com> for cdni@ietf.org; Wed, 09 Feb 2011 04:31:04 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGC00FXZO3RLE@usaga02-in.huawei.com> for cdni@ietf.org; Wed, 09 Feb 2011 04:31:04 -0800 (PST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Feb 2011 04:30:59 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 09 Feb 2011 04:31:03 -0800 Date: Wed, 09 Feb 2011 12:31:02 +0000 From: Wangyekui In-reply-to: <000CB231-D904-4791-B659-4305E4221CC5@niven-jenkins.co.uk> X-Originating-IP: [10.47.136.43] To: Benjamin Niven-Jenkins , "Ali C. Begen (abegen)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [CDNi] Proposed text for 3GPP and MPEG portions Thread-index: AcvG5EigeZvayDUpRLCfGyaMu/dIYgAAkVFAABtt8IAAP0XWgA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EVcZ GvIW Ki8l MlPb UY4D V9gS XZxq ZhKs b7xA fQfN fYrN gXfY ngNL rKPC r2kl u8ya; 4; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA7AGIAZQBuAEAAbgBpAHYAZQBuAC0AagBlAG4AawBpAG4AcwAuAGMAbwAuAHUAawA7AGMAZABuAGkAQABpAGUAdABmAC4AbwByAGcAOwBkAHIAYQBmAHQALQBqAGUAbgBrAGkAbgBzAC0AYwBkAG4AaQAtAHAAcgBvAGIAbABlAG0ALQBzAHQAYQB0AGUAbQBlAG4AdABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8DC93472-0765-4452-B1B8-B2524A85C3B1}; eQBlAGsAdQBpAC4AdwBhAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 09 Feb 2011 12:30:51 GMT; UgBFADoAIABbAEMARABOAGkAXQAgAFAAcgBvAHAAbwBzAGUAZAAgAHQAZQB4AHQAIABmAG8AcgAgADMARwBQAFAAIABhAG4AZAAgAE0AUABFAEcAIABwAG8AcgB0AGkAbwBuAHMA x-cr-puzzleid: {8DC93472-0765-4452-B1B8-B2524A85C3B1} References: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> <000CB231-D904-4791-B659-4305E4221CC5@niven-jenkins.co.uk> Cc: "draft-jenkins-cdni-problem-statement@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:30:57 -0000 Good text from Ali! I have made some small changes, just trying to better reflect the 3GPP and = MPEG situations. For the 3GPP text (6.1.2), I have only touched the first p= aragraph. For the MPEG text (6.1.3), main changes are also in paragraph 1, = in paragraph 2 I only made a very minor change of "Ad Hoc Group" to "ad-hoc= group", to be consistent with my changes in paragraph 1. Please review (particularly Ali to confirm whether the changes are OK with = you). BR, YK Ye-Kui Wang Media Netowrking Lab Core Network Product Line Huawei Technologies 400 Crossing Blvd, 2nd Floor Bridgewater, NJ=A008807, USA 6.1.2. 3GPP 3GPP is the first organization that released a specification related to ada= ptive streaming over HTTP. 3GPP Release 9 specification on adaptive HTTP st= reaming was published in March 2010, and there have been some bug fixes on = this specification since the publication. In addition, 3GPP is preparing an= extended version for Release 10, which is scheduled to be published later = in 2011. This release will include a number of clarifications, improvements= and new features. [3GP-DASH] is defined as a general framework independent of the data encaps= ulation format. It has support for fast initial startup and seeking, adapti= ve bitrate switching, re-use of HTTP origin and cache servers, re-use of ex= isting media playout engines, on-demand, live and time-shifted delivery. It= specifies syntax and semantics of Media Presentation Description (MPD), fo= rmat of segments and delivery protocol for segments. It does not specify co= ntent provisioning, client behavior or transport of MPD. The content retrieved by a client using 3GP-DASH adaptive streaming could b= e obtained from a CDN but this is not discussed or specified in the 3GPP sp= ecifications as it is transparent to 3GP-DASH operations. Similarly, it is = expected that 3GP-DASH can be used transparently from the CDNs as a deliver= y protocol (between the delivering CDN surrogate and the User Agent) in a C= DN Interconnect environment. 3GP-DASH could also be a candidate for content= acquisition between CDNs in a CDN Interconnect environment. 6.1.3 MPEG On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) ad-hoc gr= oup adopted the 3GPP Release 9 as a starting point and has made some improv= ements and extensions. Similarly as 3GPP SA4, the MPEG DASH ad-hoc group ha= s been working on standardizing the manifest file and the delivery format. = Additionally, the MPEG DASH ad-hoc group has also been working on the use o= f MPEG-2 Transport Streams as a media format, conversion from/to existing f= ile formats, common encryption, and so on. The MPEG DASH specification coul= d also be a candidate for delivery to the user agent and for content acquis= ition between CDNs in a CDN Interconnect environment. The Draft Internation= al Standard (DIS) version [MPEG-DASH] should be publicly available at http:= //mpeg.chiariglione.org/working_documents.htm#MPEG-B in early February. In the 95th MPEG meeting in January 2011, the DASH ad-hoc group has decided= to start a new evaluation experiment called "CDN-EE". The goals are to und= erstand the requirements for MPEG DASH to better support CDN-based delivery= , and to provide a guidelines document for CDN operators to better support = MPEG DASH streaming services. The ongoing work is still very preliminary an= d does not currently target looking into CDN Interconnect issues. [3GP-DASH] "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressiv= e Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)" http://www.= 3gpp.org/ftp/Specs/html-info/26247.htm=20 [MPEG-DASH] "Information technology - MPEG systems technologies - Part 6: D= ynamic adaptive streaming over HTTP (DASH)," (DIS version), February 2011 h= ttp://mpeg.chiariglione.org/working_documents.htm#MPEG-B -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= jamin Niven-Jenkins Sent: Monday, February 07, 2011 4:52 PM To: Ali C. Begen (abegen) Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org; cdni@ietf.org Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions Ali, Thanks for proposing some improved text. If no-one objects we'll incorporat= e your proposal in the next version of the problem statement. Ben On 7 Feb 2011, at 16:46, Ali C. Begen (abegen) wrote: > Hi everyone, >=20 > The current problem statement draft talks about other related standardiza= tion activities. 6.1.2 mentions 3GPP. Following up my conversation with Fra= ncois, he asked me to provide a bit more details on the developments in 3GP= P as well as MPEG. >=20 > With Francois' input, I think the following text would be good to incorpo= rate in the draft. It proposes some changes in 6.1.2 and adds a new section= (preferably right after 6.1.2) for MPEG. Also note that 3GPP's method is c= alled 3GP-DASH and MPEG's version is called MPEG DASH. The text should be u= pdated throughout the draft appropriately. Below is also the revised list o= f references. >=20 > -acbegen >=20 >=20 >=20 > 6.1.2. 3GPP >=20 > 3GPP is the first organization that released a specification related to a= daptive streaming over HTTP. 3GPP Release 9 was published in March 2010, an= d the SA4 Working Group is currently in the process of bug-fixing this spec= ification taking into account experience from the first implementations. In= addition, 3GPP is preparing an extended version for Release 10, which is s= cheduled to be published later in 2011. This release will include a number = of clarifications, offer improvements and add new features. >=20 > [3GP-DASH] is defined as a general framework independent of the data enca= psulation format. It has support for fast initial startup and seeking, adap= tive bitrate switching, re-use of HTTP origin and cache servers, re-use of = existing media playout engines, on-demand, live and time-shifted delivery. = It specifies syntax and semantics of Media Presentation Description (MPD), = format of segments and delivery protocol for segments. It does not specify = content provisioning, client behavior or transport of MPD. >=20 > The content retrieved by a client using 3GP-DASH adaptive streaming could= be obtained from a CDN but this is not discussed or specified in the 3GPP = specifications as it is transparent to 3GP-DASH operations. Similarly, it i= s expected that=20 > 3GP-DASH can be used transparently from the CDNs as a delivery protocol (= between the delivering CDN surrogate and the User Agent) in a CDN Interconn= ect environment. 3GP-DASH could also be a candidate for content acquisition= between CDNs in a CDN Interconnect environment. >=20 > 6.1.3 MPEG >=20 > On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) Ad Hoc = Group has adopted the 3GPP Release 9 as a baseline specification and starte= d running several evaluation experiments to evaluate the submitted proposal= s. The DASH Ad Hoc Group is working on standardizing the manifest file, del= ivery format, conversion from/to existing file formats and the use of MPEG2= Transport Streams as a media format. The MPEG DASH specification could als= o be a candidate for delivery to the user agent and for content acquisition= between CDNs in a CDN Interconnect environment. The Draft International St= andard (DIS) version [MPEG-DASH] should be publicly available at http://mpe= g.chiariglione.org/working_documents.htm#MPEG-B in early February. >=20 > In the 95th MPEG meeting in January 2011, the DASH Ad Hoc Group has decid= ed to start a new evaluation experiment called "CDN-EE". The goals are to u= nderstand the requirements for MPEG DASH to better support CDN-based delive= ry, and to provide a guidelines document for CDN operators to better suppor= t MPEG DASH streaming services. The ongoing work is still very preliminary = and does not currently target looking into CDN Interconnect issues. >=20 > [3GP-DASH] > "Transparent end-to-end Packet-switched Streaming Service (PSS); Progress= ive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)" http://ww= w.3gpp.org/ftp/Specs/html-info/26247.htm=20 >=20 > [MPEG-DASH] "Information technology - MPEG systems technologies - Part 6:= Dynamic adaptive streaming over HTTP (DASH)," (DIS version), February 2011= http://mpeg.chiariglione.org/working_documents.htm#MPEG-B=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From yekui.wang@huawei.com Wed Feb 9 04:38:32 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AAF3A69B1 for ; Wed, 9 Feb 2011 04:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMa-62F1BW1f for ; Wed, 9 Feb 2011 04:38:30 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6D31C3A6967 for ; Wed, 9 Feb 2011 04:38:30 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGC00BO5OGFGX@usaga02-in.huawei.com> for cdni@ietf.org; Wed, 09 Feb 2011 04:38:39 -0800 (PST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGC00FAIOGFLE@usaga02-in.huawei.com> for cdni@ietf.org; Wed, 09 Feb 2011 04:38:39 -0800 (PST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Feb 2011 04:38:40 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 09 Feb 2011 04:38:38 -0800 Date: Wed, 09 Feb 2011 12:38:37 +0000 From: Wangyekui X-Originating-IP: [10.47.136.43] To: Benjamin Niven-Jenkins , "Ali C. Begen (abegen)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: CableLabs RE: [CDNi] Proposed text for 3GPP and MPEG portions Thread-index: AcvG5EigeZvayDUpRLCfGyaMu/dIYgAAkVFAABtt8IAAP0XWgAABIs5A X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ey6R IZ2i I/Jz U3ZW VSfQ Vssk WyGP XoqW byh2 c/6L ejIl eyPB fSTg fiwy m3bo paMS; 4; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA7AGIAZQBuAEAAbgBpAHYAZQBuAC0AagBlAG4AawBpAG4AcwAuAGMAbwAuAHUAawA7AGMAZABuAGkAQABpAGUAdABmAC4AbwByAGcAOwBkAHIAYQBmAHQALQBqAGUAbgBrAGkAbgBzAC0AYwBkAG4AaQAtAHAAcgBvAGIAbABlAG0ALQBzAHQAYQB0AGUAbQBlAG4AdABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {2469BDC9-3DD8-4AB6-B153-E06FAB45DFF7}; eQBlAGsAdQBpAC4AdwBhAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 09 Feb 2011 12:38:28 GMT; QwBhAGIAbABlAEwAYQBiAHMAIABSAEUAOgAgAFsAQwBEAE4AaQBdACAAUAByAG8AcABvAHMAZQBkACAAdABlAHgAdAAgAGYAbwByACAAMwBHAFAAUAAgAGEAbgBkACAATQBQAEUARwAgAHAAbwByAHQAaQBvAG4AcwA= x-cr-puzzleid: {2469BDC9-3DD8-4AB6-B153-E06FAB45DFF7} References: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> <000CB231-D904-4791-B659-4305E4221CC5@niven-jenkins.co.uk> Cc: "draft-jenkins-cdni-problem-statement@tools.ietf.org" , "cdni@ietf.org" Subject: [CDNi] CableLabs RE: Proposed text for 3GPP and MPEG portions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:38:32 -0000 BTW, all instances of "Cable Labs" in the problem statement document should= be changed to "CableLabs", I think. BR, YK -----Original Message----- From: Wangyekui=20 Sent: Wednesday, February 09, 2011 7:31 AM To: 'Benjamin Niven-Jenkins'; Ali C. Begen (abegen) Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org; cdni@ietf.org Subject: RE: [CDNi] Proposed text for 3GPP and MPEG portions Good text from Ali! I have made some small changes, just trying to better reflect the 3GPP and = MPEG situations. For the 3GPP text (6.1.2), I have only touched the first p= aragraph. For the MPEG text (6.1.3), main changes are also in paragraph 1, = in paragraph 2 I only made a very minor change of "Ad Hoc Group" to "ad-hoc= group", to be consistent with my changes in paragraph 1. Please review (particularly Ali to confirm whether the changes are OK with = you). BR, YK Ye-Kui Wang Media Netowrking Lab Core Network Product Line Huawei Technologies 400 Crossing Blvd, 2nd Floor Bridgewater, NJ=A008807, USA 6.1.2. 3GPP 3GPP is the first organization that released a specification related to ada= ptive streaming over HTTP. 3GPP Release 9 specification on adaptive HTTP st= reaming was published in March 2010, and there have been some bug fixes on = this specification since the publication. In addition, 3GPP is preparing an= extended version for Release 10, which is scheduled to be published later = in 2011. This release will include a number of clarifications, improvements= and new features. [3GP-DASH] is defined as a general framework independent of the data encaps= ulation format. It has support for fast initial startup and seeking, adapti= ve bitrate switching, re-use of HTTP origin and cache servers, re-use of ex= isting media playout engines, on-demand, live and time-shifted delivery. It= specifies syntax and semantics of Media Presentation Description (MPD), fo= rmat of segments and delivery protocol for segments. It does not specify co= ntent provisioning, client behavior or transport of MPD. The content retrieved by a client using 3GP-DASH adaptive streaming could b= e obtained from a CDN but this is not discussed or specified in the 3GPP sp= ecifications as it is transparent to 3GP-DASH operations. Similarly, it is = expected that 3GP-DASH can be used transparently from the CDNs as a deliver= y protocol (between the delivering CDN surrogate and the User Agent) in a C= DN Interconnect environment. 3GP-DASH could also be a candidate for content= acquisition between CDNs in a CDN Interconnect environment. 6.1.3 MPEG On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) ad-hoc gr= oup adopted the 3GPP Release 9 as a starting point and has made some improv= ements and extensions. Similarly as 3GPP SA4, the MPEG DASH ad-hoc group ha= s been working on standardizing the manifest file and the delivery format. = Additionally, the MPEG DASH ad-hoc group has also been working on the use o= f MPEG-2 Transport Streams as a media format, conversion from/to existing f= ile formats, common encryption, and so on. The MPEG DASH specification coul= d also be a candidate for delivery to the user agent and for content acquis= ition between CDNs in a CDN Interconnect environment. The Draft Internation= al Standard (DIS) version [MPEG-DASH] should be publicly available at http:= //mpeg.chiariglione.org/working_documents.htm#MPEG-B in early February. In the 95th MPEG meeting in January 2011, the DASH ad-hoc group has decided= to start a new evaluation experiment called "CDN-EE". The goals are to und= erstand the requirements for MPEG DASH to better support CDN-based delivery= , and to provide a guidelines document for CDN operators to better support = MPEG DASH streaming services. The ongoing work is still very preliminary an= d does not currently target looking into CDN Interconnect issues. [3GP-DASH] "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressiv= e Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)" http://www.= 3gpp.org/ftp/Specs/html-info/26247.htm=20 [MPEG-DASH] "Information technology - MPEG systems technologies - Part 6: D= ynamic adaptive streaming over HTTP (DASH)," (DIS version), February 2011 h= ttp://mpeg.chiariglione.org/working_documents.htm#MPEG-B -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= jamin Niven-Jenkins Sent: Monday, February 07, 2011 4:52 PM To: Ali C. Begen (abegen) Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org; cdni@ietf.org Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions Ali, Thanks for proposing some improved text. If no-one objects we'll incorporat= e your proposal in the next version of the problem statement. Ben On 7 Feb 2011, at 16:46, Ali C. Begen (abegen) wrote: > Hi everyone, >=20 > The current problem statement draft talks about other related standardiza= tion activities. 6.1.2 mentions 3GPP. Following up my conversation with Fra= ncois, he asked me to provide a bit more details on the developments in 3GP= P as well as MPEG. >=20 > With Francois' input, I think the following text would be good to incorpo= rate in the draft. It proposes some changes in 6.1.2 and adds a new section= (preferably right after 6.1.2) for MPEG. Also note that 3GPP's method is c= alled 3GP-DASH and MPEG's version is called MPEG DASH. The text should be u= pdated throughout the draft appropriately. Below is also the revised list o= f references. >=20 > -acbegen >=20 >=20 >=20 > 6.1.2. 3GPP >=20 > 3GPP is the first organization that released a specification related to a= daptive streaming over HTTP. 3GPP Release 9 was published in March 2010, an= d the SA4 Working Group is currently in the process of bug-fixing this spec= ification taking into account experience from the first implementations. In= addition, 3GPP is preparing an extended version for Release 10, which is s= cheduled to be published later in 2011. This release will include a number = of clarifications, offer improvements and add new features. >=20 > [3GP-DASH] is defined as a general framework independent of the data enca= psulation format. It has support for fast initial startup and seeking, adap= tive bitrate switching, re-use of HTTP origin and cache servers, re-use of = existing media playout engines, on-demand, live and time-shifted delivery. = It specifies syntax and semantics of Media Presentation Description (MPD), = format of segments and delivery protocol for segments. It does not specify = content provisioning, client behavior or transport of MPD. >=20 > The content retrieved by a client using 3GP-DASH adaptive streaming could= be obtained from a CDN but this is not discussed or specified in the 3GPP = specifications as it is transparent to 3GP-DASH operations. Similarly, it i= s expected that=20 > 3GP-DASH can be used transparently from the CDNs as a delivery protocol (= between the delivering CDN surrogate and the User Agent) in a CDN Interconn= ect environment. 3GP-DASH could also be a candidate for content acquisition= between CDNs in a CDN Interconnect environment. >=20 > 6.1.3 MPEG >=20 > On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) Ad Hoc = Group has adopted the 3GPP Release 9 as a baseline specification and starte= d running several evaluation experiments to evaluate the submitted proposal= s. The DASH Ad Hoc Group is working on standardizing the manifest file, del= ivery format, conversion from/to existing file formats and the use of MPEG2= Transport Streams as a media format. The MPEG DASH specification could als= o be a candidate for delivery to the user agent and for content acquisition= between CDNs in a CDN Interconnect environment. The Draft International St= andard (DIS) version [MPEG-DASH] should be publicly available at http://mpe= g.chiariglione.org/working_documents.htm#MPEG-B in early February. >=20 > In the 95th MPEG meeting in January 2011, the DASH Ad Hoc Group has decid= ed to start a new evaluation experiment called "CDN-EE". The goals are to u= nderstand the requirements for MPEG DASH to better support CDN-based delive= ry, and to provide a guidelines document for CDN operators to better suppor= t MPEG DASH streaming services. The ongoing work is still very preliminary = and does not currently target looking into CDN Interconnect issues. >=20 > [3GP-DASH] > "Transparent end-to-end Packet-switched Streaming Service (PSS); Progress= ive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)" http://ww= w.3gpp.org/ftp/Specs/html-info/26247.htm=20 >=20 > [MPEG-DASH] "Information technology - MPEG systems technologies - Part 6:= Dynamic adaptive streaming over HTTP (DASH)," (DIS version), February 2011= http://mpeg.chiariglione.org/working_documents.htm#MPEG-B=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From abegen@cisco.com Wed Feb 9 06:15:37 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9C73A69D4 for ; Wed, 9 Feb 2011 06:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d335mLBE62NB for ; Wed, 9 Feb 2011 06:15:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 650F13A69C0 for ; Wed, 9 Feb 2011 06:15:34 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BADIwUk2rR7Hu/2dsb2JhbACWaY5bc6B3mw2DEIJMBIR/iik Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2011 14:15:44 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p19EFhWE005744; Wed, 9 Feb 2011 14:15:43 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 06:15:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 06:14:46 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E41AD81@xmb-sjc-215.amer.cisco.com> In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Proposed text for 3GPP and MPEG portions Thread-Index: AcvG5EigeZvayDUpRLCfGyaMu/dIYgAAkVFAABtt8IAAP0XWgAAEcwSg References: <04CAD96D4C5A3D48B1919248A8FE0D540E41A5B7@xmb-sjc-215.amer.cisco.com> <000CB231-D904-4791-B659-4305E4221CC5@niven-jenkins.co.uk> A From: "Ali C. Begen (abegen)" To: "Wangyekui" , "Benjamin Niven-Jenkins" X-OriginalArrivalTime: 09 Feb 2011 14:15:44.0051 (UTC) FILETIME=[D6C17030:01CBC863] Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org, cdni@ietf.org Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:15:37 -0000 Looks good to me. -acbegen > -----Original Message----- > From: Wangyekui [mailto:yekui.wang@huawei.com] > Sent: Wednesday, February 09, 2011 7:31 AM > To: Benjamin Niven-Jenkins; Ali C. Begen (abegen) > Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org; cdni@ietf.org > Subject: RE: [CDNi] Proposed text for 3GPP and MPEG portions >=20 > Good text from Ali! >=20 > I have made some small changes, just trying to better reflect the 3GPP = and MPEG situations. For the 3GPP text (6.1.2), I have > only touched the first paragraph. For the MPEG text (6.1.3), main = changes are also in paragraph 1, in paragraph 2 I only > made a very minor change of "Ad Hoc Group" to "ad-hoc group", to be = consistent with my changes in paragraph 1. >=20 > Please review (particularly Ali to confirm whether the changes are OK = with you). >=20 > BR, YK >=20 > Ye-Kui Wang > Media Netowrking Lab > Core Network Product Line > Huawei Technologies > 400 Crossing Blvd, 2nd Floor > Bridgewater, NJ=A008807, USA >=20 >=20 > 6.1.2. 3GPP >=20 > 3GPP is the first organization that released a specification related = to adaptive streaming over HTTP. 3GPP Release 9 > specification on adaptive HTTP streaming was published in March 2010, = and there have been some bug fixes on this > specification since the publication. In addition, 3GPP is preparing an = extended version for Release 10, which is scheduled to > be published later in 2011. This release will include a number of = clarifications, improvements and new features. >=20 > [3GP-DASH] is defined as a general framework independent of the data = encapsulation format. It has support for fast initial > startup and seeking, adaptive bitrate switching, re-use of HTTP origin = and cache servers, re-use of existing media playout > engines, on-demand, live and time-shifted delivery. It specifies = syntax and semantics of Media Presentation Description > (MPD), format of segments and delivery protocol for segments. It does = not specify content provisioning, client behavior or > transport of MPD. >=20 > The content retrieved by a client using 3GP-DASH adaptive streaming = could be obtained from a CDN but this is not discussed > or specified in the 3GPP specifications as it is transparent to = 3GP-DASH operations. Similarly, it is expected that 3GP-DASH > can be used transparently from the CDNs as a delivery protocol = (between the delivering CDN surrogate and the User Agent) > in a CDN Interconnect environment. 3GP-DASH could also be a candidate = for content acquisition between CDNs in a CDN > Interconnect environment. >=20 > 6.1.3 MPEG >=20 > On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) = ad-hoc group adopted the 3GPP Release 9 as a > starting point and has made some improvements and extensions. = Similarly as 3GPP SA4, the MPEG DASH ad-hoc group has > been working on standardizing the manifest file and the delivery = format. Additionally, the MPEG DASH ad-hoc group has also > been working on the use of MPEG-2 Transport Streams as a media format, = conversion from/to existing file formats, common > encryption, and so on. The MPEG DASH specification could also be a = candidate for delivery to the user agent and for content > acquisition between CDNs in a CDN Interconnect environment. The Draft = International Standard (DIS) version [MPEG-DASH] > should be publicly available at = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B in early = February. >=20 > In the 95th MPEG meeting in January 2011, the DASH ad-hoc group has = decided to start a new evaluation experiment called > "CDN-EE". The goals are to understand the requirements for MPEG DASH = to better support CDN-based delivery, and to > provide a guidelines document for CDN operators to better support MPEG = DASH streaming services. The ongoing work is still > very preliminary and does not currently target looking into CDN = Interconnect issues. >=20 > [3GP-DASH] > "Transparent end-to-end Packet-switched Streaming Service (PSS); = Progressive Download and Dynamic Adaptive Streaming > over HTTP (3GP-DASH)" = http://www.3gpp.org/ftp/Specs/html-info/26247.htm >=20 > [MPEG-DASH] "Information technology - MPEG systems technologies - Part = 6: Dynamic adaptive streaming over HTTP > (DASH)," (DIS version), February 2011 = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B >=20 >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Benjamin Niven-Jenkins > Sent: Monday, February 07, 2011 4:52 PM > To: Ali C. Begen (abegen) > Cc: draft-jenkins-cdni-problem-statement@tools.ietf.org; cdni@ietf.org > Subject: Re: [CDNi] Proposed text for 3GPP and MPEG portions >=20 > Ali, >=20 > Thanks for proposing some improved text. If no-one objects we'll = incorporate your proposal in the next version of the > problem statement. >=20 > Ben >=20 > On 7 Feb 2011, at 16:46, Ali C. Begen (abegen) wrote: >=20 > > Hi everyone, > > > > The current problem statement draft talks about other related = standardization activities. 6.1.2 mentions 3GPP. Following up > my conversation with Francois, he asked me to provide a bit more = details on the developments in 3GPP as well as MPEG. > > > > With Francois' input, I think the following text would be good to = incorporate in the draft. It proposes some changes in 6.1.2 > and adds a new section (preferably right after 6.1.2) for MPEG. Also = note that 3GPP's method is called 3GP-DASH and > MPEG's version is called MPEG DASH. The text should be updated = throughout the draft appropriately. Below is also the > revised list of references. > > > > -acbegen > > > > > > > > 6.1.2. 3GPP > > > > 3GPP is the first organization that released a specification related = to adaptive streaming over HTTP. 3GPP Release 9 was > published in March 2010, and the SA4 Working Group is currently in the = process of bug-fixing this specification taking into > account experience from the first implementations. In addition, 3GPP = is preparing an extended version for Release 10, which > is scheduled to be published later in 2011. This release will include = a number of clarifications, offer improvements and add > new features. > > > > [3GP-DASH] is defined as a general framework independent of the data = encapsulation format. It has support for fast initial > startup and seeking, adaptive bitrate switching, re-use of HTTP origin = and cache servers, re-use of existing media playout > engines, on-demand, live and time-shifted delivery. It specifies = syntax and semantics of Media Presentation Description > (MPD), format of segments and delivery protocol for segments. It does = not specify content provisioning, client behavior or > transport of MPD. > > > > The content retrieved by a client using 3GP-DASH adaptive streaming = could be obtained from a CDN but this is not > discussed or specified in the 3GPP specifications as it is transparent = to 3GP-DASH operations. Similarly, it is expected that > > 3GP-DASH can be used transparently from the CDNs as a delivery = protocol (between the delivering CDN surrogate and the > User Agent) in a CDN Interconnect environment. 3GP-DASH could also be = a candidate for content acquisition between CDNs > in a CDN Interconnect environment. > > > > 6.1.3 MPEG > > > > On the MPEG side, the Dynamic Adaptive Streaming over HTTP (DASH) Ad = Hoc Group has adopted the 3GPP Release 9 as a > baseline specification and started running several evaluation = experiments to evaluate the submitted proposals. The DASH Ad > Hoc Group is working on standardizing the manifest file, delivery = format, conversion from/to existing file formats and the use > of MPEG2 Transport Streams as a media format. The MPEG DASH = specification could also be a candidate for delivery to the > user agent and for content acquisition between CDNs in a CDN = Interconnect environment. The Draft International Standard > (DIS) version [MPEG-DASH] should be publicly available at = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B in > early February. > > > > In the 95th MPEG meeting in January 2011, the DASH Ad Hoc Group has = decided to start a new evaluation experiment > called "CDN-EE". The goals are to understand the requirements for MPEG = DASH to better support CDN-based delivery, and to > provide a guidelines document for CDN operators to better support MPEG = DASH streaming services. The ongoing work is still > very preliminary and does not currently target looking into CDN = Interconnect issues. > > > > [3GP-DASH] > > "Transparent end-to-end Packet-switched Streaming Service (PSS); = Progressive Download and Dynamic Adaptive Streaming > over HTTP (3GP-DASH)" = http://www.3gpp.org/ftp/Specs/html-info/26247.htm > > > > [MPEG-DASH] "Information technology - MPEG systems technologies - = Part 6: Dynamic adaptive streaming over HTTP > (DASH)," (DIS version), February 2011 = http://mpeg.chiariglione.org/working_documents.htm#MPEG-B > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From philip.eardley@bt.com Fri Feb 11 05:59:03 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8DF3A69BD for ; Fri, 11 Feb 2011 05:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.126 X-Spam-Level: X-Spam-Status: No, score=-101.126 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jp6+0nKGrPd for ; Fri, 11 Feb 2011 05:59:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 0183E3A6964 for ; Fri, 11 Feb 2011 05:59:00 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 11 Feb 2011 13:59:15 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.67]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 11 Feb 2011 13:59:14 +0000 From: To: , Date: Fri, 11 Feb 2011 13:59:14 +0000 Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AcvDjSBTYhM2IaB0QTKHQvcN8YOeQADDDahwANX9PAA= Message-ID: <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 13:59:03 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBlbWlsZS5zdGVwaGFuQG9yYW5n ZS1mdGdyb3VwLmNvbSBbbWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLWZ0Z3JvdXAuY29tXSAN ClNlbnQ6IDA3IEZlYnJ1YXJ5IDIwMTEgMDg6MjkNClRvOiBmbGVmYXVjaEBjaXNjby5jb207IEVh cmRsZXksUEwsUGhpbGlwLERFUzggUg0KQ2M6IG12aXR0YWxAY2lzY28uY29tOyBjZG5pQGlldGYu b3JnOyBZaXVfTGVlQENhYmxlLkNvbWNhc3QuY29tDQpTdWJqZWN0OiBSRTogW0NETmldIExvb3Ag ZGV0ZWN0aW9uIHJlcXVpcmVtZW50DQoNCkhpIEZyYW5jb2lzLA0KDQpDRE5JIGludGVyZmFjZXMg bXVzdCBzdXBwb3J0IGxvb3AgZGV0ZWN0aW9uIGV2ZW4gd2hlbiB0aGVyZSBpcyBvbmx5IDIgQ0RO cyBpbnRlcmNvbm5lY3RlZC4gSGVuY2UgdGhpcyByZXEgaXMgdGllZCBub3IgdG8gdGhlIG51bWJl ciBvZiBDRE5zIG9mIHRoZSBDRE5pIGNoYWluIG5vciB0byBpdHMgbmF0dXJlLg0KDQpTbyBpbW8g c3VwcG9ydCBmb3IgbG9vcCBkZXRlY3Rpb24gaXMgYSBnZW5lcmljIE1VU1QgdGhhdCBhcHBsaWVz IHRvIGVhY2ggQ0ROaSBBUElzLiANCg0KW3BoaWxdIHdlbGwsIGluIHRoZSBjYXNlIHdpdGggb25s eSAyIENETnMgaW50ZXJjb25uZWN0ZWQsIHNvbHZpbmcgbG9vcCBkZXRlY3Rpb24gaXMgdHJpdmlh bDsgaWYgdGhlcmUgaXMgYSBjaGFpbiB0aGVuIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRo ZSBpc3N1ZXMgYXJlIHRyaXZpYWwuIFRoaXMgaXMgbm90IGp1c3QgYWJvdXQgbG9vcCBkZXRlY3Rp b24gLSBmb3IgaW5zdGFuY2UsIGZvciB0aGUgbG9nZ2luZyBBUEksIGRvIHlvdSBuZWVkIGEgY29t bW9uIGFncmVlbWVudCBhbG9uZyB0aGUgY2hhaW4gYWJvdXQgbG9nZ2luZyBmb3JtYXQsIHNlY3Vy aXR5LCB3aGF0ICJyZWFsIHRpbWUiIG1lYW5zLCBldGM/IEVnLCBpZiBBICYgQiBhZ3JlZSBvbmUg Zm9ybWF0IGFuZCBCICYgQyBhZ3JlZSBhIGRpZmZlcmVudCBmb3JtYXQsIHRoZW4gZG8geW91IG5l ZWQgdG8gdHJhbnNsYXRlIGl0Pw0KSWYgdGhlICJjaGFpbiBpc3N1ZXMiIGFyZSB0cmlja3kgdG8g c29sdmUsIHRoZW4gc3RhcnRpbmcgd2l0aCB0aGUgYXNzdW1wdGlvbiBvZiBubyBjaGFpbiB3b3Vs ZCBtYWtlIHRoZSBzY29wZSBtb3JlIG1hbmFnZWFibGUuIE9mIGNvdXJzZSwgaWYgdGhlICJjaGFp biBpc3N1ZXMiIGFyZSBlYXN5IHRvIHNvbHZlIHRoZW4gdGhlIHNjb3BlIGlzIHN0aWxsIG1hbmFn ZWFibGUuIA0KUGhpbC8NCg0KDQpJIHN1Z2dlc3QgaW5zZXJ0aW5nIHRoaXMgcmVxIGRpcmVjdGx5 IGluIHRoZSBoZWFkZXIgb2YgdGhlIHNlY3Rpb24gMyBvZiB0aGUgcmVxIGRyYWZ0LiANCg0KDQpS ZWdhcmRzDQpFbWlsZQ0KDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6 IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZQ0KPiBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPiBFbnZvecOpwqA6IGpldWRpIDMg ZsOpdnJpZXIgMjAxMSAxMToyOQ0KPiDDgMKgOiBwaGlsaXAuZWFyZGxleUBidC5jb20NCj4gQ2PC oDogbXZpdHRhbEBjaXNjby5jb207IGNkbmlAaWV0Zi5vcmc7IFlpdV9MZWVAQ2FibGUuQ29tY2Fz dC5jb20NCj4gT2JqZXTCoDogUmU6IFtDRE5pXSBMaW1pdCBuYiBvZiByZWRpcmVjdHMgJiBsb29w IHNSZTogQ0ROSSBSZXF1aXJlbWVudHMgSS1EDQo+IA0KPiBIaSBQaGlsLA0KPiANCj4gT24gMyBG ZWIgMjAxMSwgYXQgMTE6MTgsIDxwaGlsaXAuZWFyZGxleUBidC5jb20+IHdyb3RlOg0KPiANCj4g DQo+IAlDYXNjYWRlZCBDRE5zIHdvdWxkIGJlIG5pY2UuDQo+IA0KPiAJQ2FzY2FkaW5nIGlzIG1p c3NpbmcgZnJvbSB0aGUgbG9nZ2luZyBzZWN0aW9uIC0gd2hlcmUgaXQgc2VlbXMgaGFyZC4NCj4g dGhlIGxvZ2dpbmcgcmVjb3JkIG5lZWRzIHRvIGluY2x1ZGUgKGFnZ3JlZ2F0ZWQpIGluZm8gd2hl cmUgY29udGVudCBoYXMNCj4gYmVlbiBkZWxpdmVyZWQgdG8gYSBVQSBieSBhIENETiBmdXJ0aGVy IGRvd24gYSBjYXNjYWRlIG9mIENETnMuDQo+IA0KPiANCj4gVGhlcmUgYXJlIHJlcXVpcmVtZW50 cyBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbiB0aGF0IHJlbGF0ZSB0byB0aGF0Og0KPiANCj4gIg0K PiAgICBSNzEgIFRoZSBDRE5JIHNvbHV0aW9uIE1VU1QgYmUgYWJsZSB0byBlbnN1cmUgdGhhdCBm b3IgYW55IGdpdmVuDQo+ICAgICAgICAgcmVxdWVzdCByZWRpcmVjdGVkIHRvIGEgRG93bnN0cmVh bSBDRE4sIHRoZSBjaGFpbiBvZiBDRE4NCj4gICAgICAgICBEZWxlZ2F0aW9uIChsZWFkaW5nIHRv IHRoYXQgcmVxdWVzdCBiZWluZyBzZXJ2ZWQgYnkgdGhhdCBDRE4pDQo+ICAgICAgICAgY2FuIGJl IGVzdGFibGlzaGVkIHdpdGggbm9uLXJlcHVkaWF0aW9uLg0KPiANCj4gICAgUjcyICBUaGUgQ0RO SSBzb2x1dGlvbiBNVVNUIGJlIGFibGUgdG8gZW5zdXJlIHRoYXQgdGhlIERvd25zdHJlYW0gQ0RO DQo+ICAgICAgICAgY2Fubm90IHNwb29mIGEgdHJhbnNhY3Rpb24gbG9nIGF0dGVtcHRpbmcgdG8g YXBwZWFyIGFzIGlmIGl0DQo+ICAgICAgICAgY29ycmVzcG9uZHMgdG8gYSByZXF1ZXN0IHJlZGly ZWN0ZWQgYnkgYSBnaXZlbiBVcHN0cmVhbSBDRE4gd2hlbg0KPiAgICAgICAgIHRoYXQgcmVxdWVz dCBoYXMgbm90IGJlZW4gcmVkaXJlY3RlZCBieSB0aGlzIFVwc3RyZWFtIENETi4NCj4gIg0KPiAN Cj4gVGhpcyBpcyBtZWFudCB0byBhcHBseSBhbHNvIHRvIHRoZSBMb2dnaW5nIEFQSS4NCj4gSXMg dGhhdCBzdWZmaWNpZW50IHRvIGNhcHR1cmUgdGhlIHRvcGljIG9yIGRvIHlvdSB3YW50IHRvIHNl ZSBhIHNwZWNpZmljDQo+IHJlcXVpcmVtZW50IHVuZGVyIHRoZSAiTG9nZ2luZyBBUEkiIHNlY3Rp b24/DQo+IA0KPiANCj4gDQo+IAlUaGlzIGlzIHF1aXRlIGNoYWxsZW5naW5nLCBlc3BlY2lhbGx5 IGlmIG9uZSBhbGxvd3MgYW55IGZsZXhpYmlsaXR5DQo+IG92ZXIgd2hhdCBpcyByZXBvcnRlZCwg Zm9ybWF0IG9mIHJlcG9ydHMsIHNlY3VyaXR5IG1ldGhvZHMsIHJlYWwtdGltZQ0KPiByZXBvcnRz LCBldGMuDQo+IA0KPiANCj4gDQo+IAlBZ3JlZSB0aGF0IGNhc2NhZGluZyBzaG91bGQgYmUgbWVu dGlvbmVkIGFzIGEgZ2VuZXJpYyByZXF1aXJlbWVudCAtDQo+IGFuZCB3ZSB0cmVhdCBpdCBhdCB0 aGUgc2FtZSByZXF1aXJlbWVudHMgbGV2ZWwgZm9yIGFsbCB0aGUgQVBJcyAod2hldGhlcg0KPiB0 aGF0J3M6IE1VU1QgaW4gaW5pdGlhbCBzY29wZSwgU0hPVUxELCBvciBiZXlvbmQgaW5pdGlhbCBz Y29wZSkuDQo+IA0KPiAJUGVyc29uYWxseSB0aGluayB0aGVyZSBpcyBxdWl0ZSBhIGxvdCAid2l0 aGluIGluaXRpYWwgc2NvcGUiIGluIHRoZQ0KPiByZXF1aXJlbWVudHMgZHJhZnQsIGFuZCBjYXNj YWRpbmcgbWlnaHQgYmUgZGVmZXJyYWJsZSBpZiBpdCBhZGRzDQo+IHNpZ25pZmljYW50IHdvcmsg dG8gc3RhbmRhcmRpc2luZyB0aGUgQVBJcyAtIGFzIG1vc3Qgb2YgdGhlIHZhbHVlIG9mIENETg0K PiBpbnRlcmNvbm5lY3Qgc2VlbXMgdG8gY29tZSBmcm9tIHRoZSAib25lIGhvcCIgY2FzZSBpZToN Cj4gCUNTUCAtPiBVcHN0cmVhbSBDRE4gLT4gRG93bnN0cmVhbSBDRE4gLT4gVUENCj4gDQo+IA0K PiANCj4gSSB0YWtlIHRoaXMgYXMgYSAiQiIgVm90ZS4NCj4gDQo+IFRoYW5rcw0KPiANCj4gRnJh bmNvaXMNCj4gDQo+IA0KPiANCj4gDQo+IAktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAJ RnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYNCj4gT2YgRnJhbmNvaXMgTGUgRmF1Y2hldXINCj4gCVNlbnQ6IDAyIEZlYnJ1 YXJ5IDIwMTEgMTA6NDUNCj4gCVRvOiBEYXZpZCBSIE9yYW4NCj4gCUNjOiBjZG5pQGlldGYub3Jn OyBWaXZlZ2FuYW5kaGFuIE1haGVzaDsgWWl1IExlZQ0KPiAJU3ViamVjdDogUmU6IFtDRE5pXSBM aW1pdCBuYiBvZiByZWRpcmVjdHMgJiBsb29wIHNSZTogQ0ROSQ0KPiBSZXF1aXJlbWVudHMgSS1E DQo+IA0KPiAJRGF2ZSBhbmQgYWxsLA0KPiANCj4gCU9uIDIgRmViIDIwMTEsIGF0IDAxOjUzLCBE YXZpZCBSIE9yYW4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IA0KPiAJCU9uIEZlYiAxLCAyMDExLCBh dCAyOjI1IFBNLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToNCj4gDQo+IA0KPiANCj4gCQkJRnJh bmNvaXMsDQo+IA0KPiANCj4gDQo+IAkJCU9uIDEgRmViIDIwMTEsIGF0IDE5OjAwLCBGcmFuY29p cyBMZSBGYXVjaGV1ciB3cm90ZToNCj4gDQo+IA0KPiAJCQkJVGhpcyBkaXNjdXNzaW9uIGRyaWZ0 ZWQgZnJvbSAoaSkgdGhlIGFiaWxpdHkgdG8NCj4gbGltaXQgdGhlIG51bWJlciBvZiBDRE4gcmVk aXJlY3Rpb25zIChmb3IgdGhlIHNha2Ugb2YgYXZvaWRpbmcgZGVncmFkYXRpb24NCj4gb2YgdXNl ciBleHBlcmllbmNlKSBpbnRvIGEgZGlzY3Vzc2lvbiBvbiAoaWkpIHByZXZlbnRpbmcgbG9vcHMg aW4gcmVxdWVzdA0KPiB0b3V0aW5nIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBleGNoYW5nZS4NCj4g DQo+IA0KPiANCj4gDQo+IAkJCVRoYXQncyBteSBmYXVsdCBiZWNhdXNlIEkgd2Fzbid0IGRpc3Rp bmd1aXNoaW5nIGJldHdlZW4NCj4gbG9vcCBkZXRlY3Rpb24gb2YgQ0ROIHJlZGlyZWN0aW9ucyBh bmQgb3RoZXIgdHlwZXMgb2YgbG9vcCBkZXRlY3Rpb24uDQo+IA0KPiANCj4gDQo+IAkJCQkoaSkg aXMgYWRkcmVzc2VkIGluOg0KPiANCj4gDQo+IAkJCQkiDQo+IA0KPiANCj4gCQkJCVIzNCAgVGhl IENETkkgUmVxdWVzdC1Sb3V0aW5nIEFQSSBTSE9VTEQgc3VwcG9ydA0KPiBvcHRpb25hbCBlbmZv cmNlbWVudA0KPiANCj4gDQo+IAkJCQkgICAgb2YgYSBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1 Y2Nlc3NpdmUgQ0RODQo+IHJlZGlyZWN0aW9ucyBmb3IgYQ0KPiANCj4gDQo+IAkJCQkgICAgZ2l2 ZW4gcmVxdWVzdC4NCj4gDQo+IA0KPiAJCQkJIg0KPiANCj4gDQo+IA0KPiAJCQkJKGlpKSBpcyBj dXJyZW50bHkgYWRkcmVzc2VkIGluIDoNCj4gDQo+IA0KPiANCj4gCQkJCVIzMiAgVGhlIENETkkg UmVxdWVzdC1Sb3V0aW5nIEFQSSBTSE9VTEQgc3VwcG9ydA0KPiByZXF1ZXN0IGxvb3ANCj4gDQo+ IA0KPiAJCQkJICAgIGRldGVjdGlvbiBhbmQgcHJldmVudGlvbiAoZS5nLiAgUHJldmVudA0KPiBy ZXF1ZXN0IGxvb3BpbmcgaW4gYQ0KPiANCj4gDQo+IAkJCQkgICAgc2l0dWF0aW9uIHdoZXJlIENE TjEgcmVkaXJlY3RzIHRvIENETjIgdGhhdA0KPiByZWRpcmVjdHMgdG8gQ0ROMw0KPiANCj4gDQo+ IAkJCQkgICAgdGhhdCB3b3VsZCByZWRpcmVjdCB0byBDRE4xKS4NCj4gDQo+IA0KPiANCj4gCQkJ CVIzMyAgVGhlIENETkkgUmVxdWVzdC1Sb3V0aW5nIGxvb3AgcHJldmVudGlvbg0KPiBtZWNoYW5p c20gU0hPVUxEIGFsbG93DQo+IA0KPiANCj4gCQkJCSAgICByb3V0aW5nIG9mIHRoZSByZXF1ZXN0 IChhcyBvcHBvc2VkIHRvIHRoZQ0KPiByZXF1ZXN0IGxvb3AgYmVpbmcNCj4gDQo+IA0KPiAJCQkJ ICAgIHNpbXBseSBpbnRlcnJ1cHRlZCB3aXRob3V0IHJvdXRpbmcgdGhlDQo+IHJlcXVlc3QpLg0K PiANCj4gDQo+IA0KPiAJCQkJKGFzIHdlbGwgYXMgUjM5IGFuZCBSNDAgZm9yIGxvbmdlciB0ZXJt KQ0KPiANCj4gDQo+IA0KPiAJCQkJUjU1ICBJZiBjYXNjYWRlZCBDRE5zIGFyZSBzdXBwb3J0ZWQg YnkgdGhlIENETkkNCj4gc29sdXRpb24sIHRoZSBDRE5JDQo+IA0KPiANCj4gCQkJCSAgICBNZXRh ZGF0YSBBUEkgTVVTVCBwcmV2ZW50IGxvb3Bpbmcgb2YgQ0ROSQ0KPiBNZXRhZGF0YSBkaXN0cmli dXRpb24NCj4gDQo+IA0KPiAJCQkJICAgIGFjcm9zcyBDRE5zLg0KPiANCj4gDQo+IA0KPiAJCQkJ RG8geW91IGd1eXMgc3RpbGwgdGhpbmsgc29tZXRoaW5nIGlzIG1pc3Npbmc/DQo+IA0KPiANCj4g CQkJCUNhbiB5b3Ugc3VnZ2VzdCBzb21ldGhpbmcgdG8gY292ZXIgbWlzc2luZyBiaXRzPw0KPiAN Cj4gDQo+IA0KPiANCj4gCQkJRm9yIENETkkgUmVxdWVzdCBSb3V0aW5nIHRoZSBhYm92ZSBpcyBm aW5lLiBXaGF0IEknbQ0KPiBzYXlpbmcgaXMgSSB0aGluayBsb29wIGRldGVjdGlvbiBhbHNvIGFw cGxpZXMgdG8gdGhlIGNvbnRyb2wgQVBJIGFuZCBtYXkNCj4gYmUgdXNlZnVsIGluIHRoZSBvdGhl ciBBUElzLg0KPiANCj4gDQo+IA0KPiAJCQlJJ2QgdGhlcmVmb3JlIHN1Z2dlc3QgbWFraW5nIGxv b3AgZGV0ZWN0aW9uIGEgZ2VuZXJhbA0KPiByZXF1aXJlbWVudCAoU0hPVUxEKSBhbmQgYW55IG1v cmUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIChlLmcuIFIzMykgdW5kZXINCj4gdGhlIHNwZWNpZmlj IEFQSSB0aGV5IGFwcGx5IHRvLg0KPiANCj4gDQo+IA0KPiAJCUkgdGhpbmsgdGhlIHJlcXVpcmVt ZW50IGlzIHN0cm9uZ2VyOiBDRE5zIG5lZWQgdG8gYWdyZWUgb24gYQ0KPiBjb21tb24gbWVjaGFu aXNtIGZvciBsb29wIGRldGVjdGlvbjsNCj4gDQo+IA0KPiANCj4gCUkgYWdyZWUgaXQgaXMgYSBN VVNUIChhcyBhbG9uZyBhcyAiY2FzY2FkZWQgQ0ROcyIgYXJlIHN1cHBvcnRlZCkuDQo+IAlJbiB0 aGUgUmVxdWlyZW1lbnRzIEktRCBpdCB3YXMgcHJlc2VudGVkOg0KPiAJKiBhcyBhICJNVVNUIiBm b3IgbG9uZ2VyIHRlcm0NCj4gCSogYXMgYSAiU0hPVUxEIiBmb3Igc2hvcnRlciB0ZXJtLCBiZWNh dXNlIHN1cHBvcnQgb2YgY2FzY2FkZWQgQ0ROcw0KPiBpdHNlbGYgaXMgb25seSBsaXN0ZWQgYXMg YSBTSE9VTEQgZm9yIHRoZSBzaG9ydGVyIHRlcm0gKG9uIHRoZSBncm91bmRzDQo+IHRoYXQgbm90 IHN1cHBvcnRpbmcgaXQgbWF5IHBvdGVudGlhbGx5IGFsbG93IGRlZmluaXRpb24gb2YgYSBzaW1w bGVyDQo+IHNvbHV0aW9uIGZhc3RlcikNCj4gDQo+IAlJIHRoaW5rIHdlIGNvdWxkIGVpdGhlcjoN Cj4gDQo+IAkqQSo6DQo+IAkqIGFncmVlIHJpZ2h0IG5vdyB0aGF0IHRoZSBzaG9ydGVyIHRlcm0g c29sdXRpb24gKGllIHdpdGhpbiBpbml0aWFsDQo+IGNoYXJ0ZXIgc2NvcGUpIE1VU1Qgc3VwcG9y dCBjYXNjYWRlZCBDRE5zDQo+IAkqIGluY2x1ZGUgYSBNVVNUIHJlcXVpcmVtZW50IGZvciBsb29w IHByZXZlbnRpb24gaW4gdGhlIEdlbmVyaWMNCj4gUmVxdHMgc2VjdGlvbiBhbmQgcG9zc2libHkg aW4gZWFjaCBBUEkgc3BlY2lmaWMgc2VjdGlvbiAoQ29udHJvbCwgUmVxdWVzdC0NCj4gUm91dGlu ZywgTWV0YWRhdGEpDQo+IA0KPiAJKkI6DQo+IAkqIGRlZmVyIHRoZSBkZWNpc2lvbiBhYm91dCBz dXBwb3J0IG9mIGNhc2NhZGVkIENETnMgaW4gc2hvcnRlciB0ZXJtDQo+IChpZSB3aXRoaW4gaW5p dGlhbCBjaGFydGVyIHNjb3BlKSB0byBmdXJ0aGVyIGRpc2N1c3Npb25zDQo+IAkqIGluY2x1ZGUg YSAiY29uZGl0aW9uYWwiIE1VU1QgKGllICJpZiBjYXNjYWRlZCBDRE5zIGFyZQ0KPiBzdXBwb3J0 ZWQsLi4uIikgaW4gdGhlIEdlbmVyaWMgUmVxdHMgc2VjdGlvbiBhbmQgcG9zc2libHkgaW4gZWFj aCBBUEkNCj4gc3BlY2lmaWMgc2VjdGlvbiAoQ29udHJvbCwgUmVxdWVzdC1Sb3V0aW5nLCBNZXRh ZGF0YSkNCj4gDQo+IAlJIHdvdWxkIHZvdGUgZm9yICpBKiBiZWNhdXNlOg0KPiAJKiB3ZSB3b3Vs ZG4ndCB3YW50IHRvIGdvIGZvciBhIHNob3J0ZXIgdGVybSBzb2x1dGlvbiB0aGF0IGNhbm5vdCBi ZQ0KPiBlYXNpbHkgZXh0ZW5kZWQgdG8gc3VwcG9ydCBjYXNjYWRlZCBDRE5zDQo+IAkqIHRoZXJl IGFyZSBzaG9ydCB0ZXJtIHVzZSBjYXNlcyBmb3IgY2FzY2FkZWQgQ0ROcy4NCj4gDQo+IAlvdGhl ciB2b3RlcnM/DQo+IA0KPiAJVGhhbmtzDQo+IA0KPiAJRnJhbmNvaXMNCj4gDQo+IA0KPiANCj4g CQlvdGhlcndpc2UgeW91IGNhbiBnZXQgbXVsdGlwbGljYXRpdmUgbG9vcCBkaWFtZXRlcnMgYW5k DQo+IGVmZmVjdGl2ZWx5IG5vdCBoYXZlIHVzZWZ1bCBsb29wIGRldGVjdGlvbiB3aGVuIHRoZSBu b24tbG9vcGluZyBwYXRocyBhcmUNCj4gbG9uZy4gVGhpcyBpcyByb3V0aW5nOyB3ZSBrbm93IHdo YXQgaGFwcGVucyB3aGVuIHlvdSBkbyBsb29wIGRldGVjdCB3aXRoDQo+IHRoaW5nIGxpa2UgY291 bnQtdG8taW5maW5pdHkuDQo+IA0KPiANCj4gDQo+IAkJSW5jaWRlbnRseSwgbXkgZmF2b3JpdGUg bG9vcCBkZXRlY3Rpb24gc2NoZW1lIHdhcyBpbnZlbnRlZCBieQ0KPiBLbnV0aCBhbGwgdGhlIHdh eSBiYWNrIGluIHZvbHVtZSAyLiBJdCBoYXMgdGhlIG5pY2UgcHJvcGVydHkgb2YgZGV0ZWN0aW5n DQo+IGxvb3BzIGluIGNvbnN0YW50IG1lbW9yeSBhbmQgd2l0aCBhbiB1cHBlciBib3VuZCBvZiB0 cmF2ZXJzaW5nIHRoZSBsb29wIDINCj4gdGltZXMsIGZvciBhbGwgbG9vcCBkaWFtZXRlcnMuIExv b2sgaXQgdXAgLSBpdCdzIGNhbGxlZCB0aGUgImV2ZW4tb2RkDQo+IGl0ZXJhdGlvbiBjb3VudGlu ZyIuDQo+IA0KPiANCj4gDQo+IAkJRGF2ZU8uDQo+IA0KPiANCj4gDQo+IA0KPiAJCQlUaGFua3MN Cj4gDQo+IA0KPiAJCQlCZW4NCj4gDQo+IA0KPiANCj4gDQo+IAkJCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiANCj4gCQkJQ0ROaSBtYWlsaW5n IGxpc3QNCj4gDQo+IA0KPiAJCQlDRE5pQGlldGYub3JnDQo+IA0KPiANCj4gCQkJaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+IA0KPiANCj4gDQo+IA0KPiAJX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gCUNETmkgbWFp bGluZyBsaXN0DQo+IAlDRE5pQGlldGYub3JnDQo+IAlodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NkbmkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRnJhbmNvaXMgTGUg RmF1Y2hldXINCj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcg0KPiBDb3Jwb3JhdGUgRGV2ZWxvcG1l bnQNCj4gZmxlZmF1Y2hAY2lzY28uY29tDQo+IFBob25lOiArMzMgNDkgNzIzIDI2MTkNCj4gTW9i aWxlOiArMzMgNiAxOSA5OCA1MCA5MA0KPiANCj4gDQo+IA0KPiANCj4gCUNpc2NvIFN5c3RlbXMg RnJhbmNlDQo+IEdyZWVuc2lkZQ0KPiA0MDAgQXZlIGRlIFJvdW1hbmlsbGUNCj4gMDY0MTAgU29w aGlhIEFudGlwb2xpcw0KPiBGcmFuY2UNCj4gQ2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2NvLmNv bT4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICBUaGluayBiZWZvcmUgeW91IHByaW50 Lg0KPiANCj4gVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVn ZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlDQo+IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlDQo+IGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50DQo+IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5DQo+IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQo+IA0KPiBDaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29j acOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZQ0KPiBEZXNtb3Vs aW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxl cyBNb3VsaW5lYXV4LA0KPiBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJD UyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhDQo+IHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNo ZWwgR2l2b25lLg0KPiANCj4gRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoN Cj4gaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2Ny aS9pbmRleC5odG1sDQo+IA0KPiANCg0K From emile.stephan@orange-ftgroup.com Fri Feb 11 07:23:08 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B783A6A19 for ; Fri, 11 Feb 2011 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.409 X-Spam-Level: X-Spam-Status: No, score=-99.409 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9brAFynyqi0W for ; Fri, 11 Feb 2011 07:23:07 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 5A9E53A6AF1 for ; Fri, 11 Feb 2011 07:23:06 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C2F1FC4008; Fri, 11 Feb 2011 16:23:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4AAFCFC4005; Fri, 11 Feb 2011 16:23:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 16:23:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 11 Feb 2011 16:23:16 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AcvDjSBTYhM2IaB0QTKHQvcN8YOeQADDDahwANX9PAAAAcLlwA== References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 11 Feb 2011 15:23:20.0222 (UTC) FILETIME=[9D3F83E0:01CBC9FF] Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:23:08 -0000 SGkgUGhpbCwNCg0KU2VlIGJlbG93DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbSBbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNv bV0NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxMSBmw6l2cmllciAyMDExIDE0OjU5DQo+IMOAwqA6 IFNURVBIQU4gRW1pbGUgUkQtQ09SRS1MQU47IGZsZWZhdWNoQGNpc2NvLmNvbQ0KPiBDY8KgOiBt dml0dGFsQGNpc2NvLmNvbTsgY2RuaUBpZXRmLm9yZzsgWWl1X0xlZUBDYWJsZS5Db21jYXN0LmNv bQ0KPiBPYmpldMKgOiBSRTogW0NETmldIExvb3AgZGV0ZWN0aW9uIHJlcXVpcmVtZW50DQo+IA0K PiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVtaWxlLnN0ZXBo YW5Ab3JhbmdlLWZ0Z3JvdXAuY29tIFttYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UtDQo+IGZ0 Z3JvdXAuY29tXQ0KPiBTZW50OiAwNyBGZWJydWFyeSAyMDExIDA4OjI5DQo+IFRvOiBmbGVmYXVj aEBjaXNjby5jb207IEVhcmRsZXksUEwsUGhpbGlwLERFUzggUg0KPiBDYzogbXZpdHRhbEBjaXNj by5jb207IGNkbmlAaWV0Zi5vcmc7IFlpdV9MZWVAQ2FibGUuQ29tY2FzdC5jb20NCj4gU3ViamVj dDogUkU6IFtDRE5pXSBMb29wIGRldGVjdGlvbiByZXF1aXJlbWVudA0KPiANCj4gSGkgRnJhbmNv aXMsDQo+IA0KPiBDRE5JIGludGVyZmFjZXMgbXVzdCBzdXBwb3J0IGxvb3AgZGV0ZWN0aW9uIGV2 ZW4gd2hlbiB0aGVyZSBpcyBvbmx5IDIgQ0ROcw0KPiBpbnRlcmNvbm5lY3RlZC4gSGVuY2UgdGhp cyByZXEgaXMgdGllZCBub3IgdG8gdGhlIG51bWJlciBvZiBDRE5zIG9mIHRoZQ0KPiBDRE5pIGNo YWluIG5vciB0byBpdHMgbmF0dXJlLg0KPiANCj4gU28gaW1vIHN1cHBvcnQgZm9yIGxvb3AgZGV0 ZWN0aW9uIGlzIGEgZ2VuZXJpYyBNVVNUIHRoYXQgYXBwbGllcyB0byBlYWNoDQo+IENETmkgQVBJ cy4NCj4gDQo+IFtwaGlsXSB3ZWxsLCBpbiB0aGUgY2FzZSB3aXRoIG9ubHkgMiBDRE5zIGludGVy Y29ubmVjdGVkLCBzb2x2aW5nIGxvb3ANCj4gZGV0ZWN0aW9uIGlzIHRyaXZpYWw7IGlmIHRoZXJl IGlzIGEgY2hhaW4gdGhlbiBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdA0KPiB0aGUgaXNzdWVz IGFyZSB0cml2aWFsLiANCg0KSU1PIHRoZSBjaGVjayBpcyBpZGVudGljYWwgaW4gYm90aCBjYXNl czogYSBDRE4gbXVzdCBjaGVjayB0aGF0IGl0IGlzIG5vdCB0cnlpbmcgdG8gcHJvdmlkZSBhIHNl cnZpY2UgdGhhdCBpdCBhc2tlZCBmb3IuDQoNCkRvIHdlIGRlZmluZWQgJ2NoYWluJyA/DQoNClJl Z2FyZHMNCmVtaWxlIA0KDQoNClRoaXMgaXMgbm90IGp1c3QgYWJvdXQgbG9vcCBkZXRlY3Rpb24g LSBmb3INCj4gaW5zdGFuY2UsIGZvciB0aGUgbG9nZ2luZyBBUEksIGRvIHlvdSBuZWVkIGEgY29t bW9uIGFncmVlbWVudCBhbG9uZyB0aGUNCj4gY2hhaW4gYWJvdXQgbG9nZ2luZyBmb3JtYXQsIHNl Y3VyaXR5LCB3aGF0ICJyZWFsIHRpbWUiIG1lYW5zLCBldGM/IEVnLCBpZg0KPiBBICYgQiBhZ3Jl ZSBvbmUgZm9ybWF0IGFuZCBCICYgQyBhZ3JlZSBhIGRpZmZlcmVudCBmb3JtYXQsIHRoZW4gZG8g eW91DQo+IG5lZWQgdG8gdHJhbnNsYXRlIGl0Pw0KPiBJZiB0aGUgImNoYWluIGlzc3VlcyIgYXJl IHRyaWNreSB0byBzb2x2ZSwgdGhlbiBzdGFydGluZyB3aXRoIHRoZQ0KPiBhc3N1bXB0aW9uIG9m IG5vIGNoYWluIHdvdWxkIG1ha2UgdGhlIHNjb3BlIG1vcmUgbWFuYWdlYWJsZS4gT2YgY291cnNl LCBpZg0KPiB0aGUgImNoYWluIGlzc3VlcyIgYXJlIGVhc3kgdG8gc29sdmUgdGhlbiB0aGUgc2Nv cGUgaXMgc3RpbGwgbWFuYWdlYWJsZS4NCj4gUGhpbC8NCj4gDQo+IA0KPiBJIHN1Z2dlc3QgaW5z ZXJ0aW5nIHRoaXMgcmVxIGRpcmVjdGx5IGluIHRoZSBoZWFkZXIgb2YgdGhlIHNlY3Rpb24gMyBv Zg0KPiB0aGUgcmVxIGRyYWZ0Lg0KPiANCj4gDQo+IFJlZ2FyZHMNCj4gRW1pbGUNCj4gDQo+IA0K PiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IGNkbmktYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiA+ IEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+ID4gRW52b3nDqcKgOiBqZXVkaSAzIGbDqXZyaWVyIDIw MTEgMTE6MjkNCj4gPiDDgMKgOiBwaGlsaXAuZWFyZGxleUBidC5jb20NCj4gPiBDY8KgOiBtdml0 dGFsQGNpc2NvLmNvbTsgY2RuaUBpZXRmLm9yZzsgWWl1X0xlZUBDYWJsZS5Db21jYXN0LmNvbQ0K PiA+IE9iamV0wqA6IFJlOiBbQ0ROaV0gTGltaXQgbmIgb2YgcmVkaXJlY3RzICYgbG9vcCBzUmU6 IENETkkgUmVxdWlyZW1lbnRzDQo+IEktRA0KPiA+DQo+ID4gSGkgUGhpbCwNCj4gPg0KPiA+IE9u IDMgRmViIDIwMTEsIGF0IDExOjE4LCA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPiB3cm90ZToNCj4g Pg0KPiA+DQo+ID4gCUNhc2NhZGVkIENETnMgd291bGQgYmUgbmljZS4NCj4gPg0KPiA+IAlDYXNj YWRpbmcgaXMgbWlzc2luZyBmcm9tIHRoZSBsb2dnaW5nIHNlY3Rpb24gLSB3aGVyZSBpdCBzZWVt cyBoYXJkLg0KPiA+IHRoZSBsb2dnaW5nIHJlY29yZCBuZWVkcyB0byBpbmNsdWRlIChhZ2dyZWdh dGVkKSBpbmZvIHdoZXJlIGNvbnRlbnQgaGFzDQo+ID4gYmVlbiBkZWxpdmVyZWQgdG8gYSBVQSBi eSBhIENETiBmdXJ0aGVyIGRvd24gYSBjYXNjYWRlIG9mIENETnMuDQo+ID4NCj4gPg0KPiA+IFRo ZXJlIGFyZSByZXF1aXJlbWVudHMgaW4gdGhlIFNlY3VyaXR5IHNlY3Rpb24gdGhhdCByZWxhdGUg dG8gdGhhdDoNCj4gPg0KPiA+ICINCj4gPiAgICBSNzEgIFRoZSBDRE5JIHNvbHV0aW9uIE1VU1Qg YmUgYWJsZSB0byBlbnN1cmUgdGhhdCBmb3IgYW55IGdpdmVuDQo+ID4gICAgICAgICByZXF1ZXN0 IHJlZGlyZWN0ZWQgdG8gYSBEb3duc3RyZWFtIENETiwgdGhlIGNoYWluIG9mIENETg0KPiA+ICAg ICAgICAgRGVsZWdhdGlvbiAobGVhZGluZyB0byB0aGF0IHJlcXVlc3QgYmVpbmcgc2VydmVkIGJ5 IHRoYXQgQ0ROKQ0KPiA+ICAgICAgICAgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGggbm9uLXJlcHVk aWF0aW9uLg0KPiA+DQo+ID4gICAgUjcyICBUaGUgQ0ROSSBzb2x1dGlvbiBNVVNUIGJlIGFibGUg dG8gZW5zdXJlIHRoYXQgdGhlIERvd25zdHJlYW0gQ0RODQo+ID4gICAgICAgICBjYW5ub3Qgc3Bv b2YgYSB0cmFuc2FjdGlvbiBsb2cgYXR0ZW1wdGluZyB0byBhcHBlYXIgYXMgaWYgaXQNCj4gPiAg ICAgICAgIGNvcnJlc3BvbmRzIHRvIGEgcmVxdWVzdCByZWRpcmVjdGVkIGJ5IGEgZ2l2ZW4gVXBz dHJlYW0gQ0ROIHdoZW4NCj4gPiAgICAgICAgIHRoYXQgcmVxdWVzdCBoYXMgbm90IGJlZW4gcmVk aXJlY3RlZCBieSB0aGlzIFVwc3RyZWFtIENETi4NCj4gPiAiDQo+ID4NCj4gPiBUaGlzIGlzIG1l YW50IHRvIGFwcGx5IGFsc28gdG8gdGhlIExvZ2dpbmcgQVBJLg0KPiA+IElzIHRoYXQgc3VmZmlj aWVudCB0byBjYXB0dXJlIHRoZSB0b3BpYyBvciBkbyB5b3Ugd2FudCB0byBzZWUgYSBzcGVjaWZp Yw0KPiA+IHJlcXVpcmVtZW50IHVuZGVyIHRoZSAiTG9nZ2luZyBBUEkiIHNlY3Rpb24/DQo+ID4N Cj4gPg0KPiA+DQo+ID4gCVRoaXMgaXMgcXVpdGUgY2hhbGxlbmdpbmcsIGVzcGVjaWFsbHkgaWYg b25lIGFsbG93cyBhbnkgZmxleGliaWxpdHkNCj4gPiBvdmVyIHdoYXQgaXMgcmVwb3J0ZWQsIGZv cm1hdCBvZiByZXBvcnRzLCBzZWN1cml0eSBtZXRob2RzLCByZWFsLXRpbWUNCj4gPiByZXBvcnRz LCBldGMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gCUFncmVlIHRoYXQgY2FzY2FkaW5nIHNob3VsZCBi ZSBtZW50aW9uZWQgYXMgYSBnZW5lcmljIHJlcXVpcmVtZW50IC0NCj4gPiBhbmQgd2UgdHJlYXQg aXQgYXQgdGhlIHNhbWUgcmVxdWlyZW1lbnRzIGxldmVsIGZvciBhbGwgdGhlIEFQSXMgKHdoZXRo ZXINCj4gPiB0aGF0J3M6IE1VU1QgaW4gaW5pdGlhbCBzY29wZSwgU0hPVUxELCBvciBiZXlvbmQg aW5pdGlhbCBzY29wZSkuDQo+ID4NCj4gPiAJUGVyc29uYWxseSB0aGluayB0aGVyZSBpcyBxdWl0 ZSBhIGxvdCAid2l0aGluIGluaXRpYWwgc2NvcGUiIGluIHRoZQ0KPiA+IHJlcXVpcmVtZW50cyBk cmFmdCwgYW5kIGNhc2NhZGluZyBtaWdodCBiZSBkZWZlcnJhYmxlIGlmIGl0IGFkZHMNCj4gPiBz aWduaWZpY2FudCB3b3JrIHRvIHN0YW5kYXJkaXNpbmcgdGhlIEFQSXMgLSBhcyBtb3N0IG9mIHRo ZSB2YWx1ZSBvZiBDRE4NCj4gPiBpbnRlcmNvbm5lY3Qgc2VlbXMgdG8gY29tZSBmcm9tIHRoZSAi b25lIGhvcCIgY2FzZSBpZToNCj4gPiAJQ1NQIC0+IFVwc3RyZWFtIENETiAtPiBEb3duc3RyZWFt IENETiAtPiBVQQ0KPiA+DQo+ID4NCj4gPg0KPiA+IEkgdGFrZSB0aGlzIGFzIGEgIkIiIFZvdGUu DQo+ID4NCj4gPiBUaGFua3MNCj4gPg0KPiA+IEZyYW5jb2lzDQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAJRnJvbTogY2RuaS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBP ZiBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPiA+IAlTZW50OiAwMiBGZWJydWFyeSAyMDExIDEwOjQ1 DQo+ID4gCVRvOiBEYXZpZCBSIE9yYW4NCj4gPiAJQ2M6IGNkbmlAaWV0Zi5vcmc7IFZpdmVnYW5h bmRoYW4gTWFoZXNoOyBZaXUgTGVlDQo+ID4gCVN1YmplY3Q6IFJlOiBbQ0ROaV0gTGltaXQgbmIg b2YgcmVkaXJlY3RzICYgbG9vcCBzUmU6IENETkkNCj4gPiBSZXF1aXJlbWVudHMgSS1EDQo+ID4N Cj4gPiAJRGF2ZSBhbmQgYWxsLA0KPiA+DQo+ID4gCU9uIDIgRmViIDIwMTEsIGF0IDAxOjUzLCBE YXZpZCBSIE9yYW4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAJCU9uIEZlYiAxLCAy MDExLCBhdCAyOjI1IFBNLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToNCj4gPg0KPiA+DQo+ID4N Cj4gPiAJCQlGcmFuY29pcywNCj4gPg0KPiA+DQo+ID4NCj4gPiAJCQlPbiAxIEZlYiAyMDExLCBh dCAxOTowMCwgRnJhbmNvaXMgTGUgRmF1Y2hldXIgd3JvdGU6DQo+ID4NCj4gPg0KPiA+IAkJCQlU aGlzIGRpc2N1c3Npb24gZHJpZnRlZCBmcm9tIChpKSB0aGUgYWJpbGl0eSB0bw0KPiA+IGxpbWl0 IHRoZSBudW1iZXIgb2YgQ0ROIHJlZGlyZWN0aW9ucyAoZm9yIHRoZSBzYWtlIG9mIGF2b2lkaW5n DQo+IGRlZ3JhZGF0aW9uDQo+ID4gb2YgdXNlciBleHBlcmllbmNlKSBpbnRvIGEgZGlzY3Vzc2lv biBvbiAoaWkpIHByZXZlbnRpbmcgbG9vcHMgaW4NCj4gcmVxdWVzdA0KPiA+IHRvdXRpbmcgYW5k IG90aGVyIGluZm9ybWF0aW9uIGV4Y2hhbmdlLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gCQkJ VGhhdCdzIG15IGZhdWx0IGJlY2F1c2UgSSB3YXNuJ3QgZGlzdGluZ3Vpc2hpbmcgYmV0d2Vlbg0K PiA+IGxvb3AgZGV0ZWN0aW9uIG9mIENETiByZWRpcmVjdGlvbnMgYW5kIG90aGVyIHR5cGVzIG9m IGxvb3AgZGV0ZWN0aW9uLg0KPiA+DQo+ID4NCj4gPg0KPiA+IAkJCQkoaSkgaXMgYWRkcmVzc2Vk IGluOg0KPiA+DQo+ID4NCj4gPiAJCQkJIg0KPiA+DQo+ID4NCj4gPiAJCQkJUjM0ICBUaGUgQ0RO SSBSZXF1ZXN0LVJvdXRpbmcgQVBJIFNIT1VMRCBzdXBwb3J0DQo+ID4gb3B0aW9uYWwgZW5mb3Jj ZW1lbnQNCj4gPg0KPiA+DQo+ID4gCQkJCSAgICBvZiBhIGxpbWl0IG9uIHRoZSBudW1iZXIgb2Yg c3VjY2Vzc2l2ZSBDRE4NCj4gPiByZWRpcmVjdGlvbnMgZm9yIGENCj4gPg0KPiA+DQo+ID4gCQkJ CSAgICBnaXZlbiByZXF1ZXN0Lg0KPiA+DQo+ID4NCj4gPiAJCQkJIg0KPiA+DQo+ID4NCj4gPg0K PiA+IAkJCQkoaWkpIGlzIGN1cnJlbnRseSBhZGRyZXNzZWQgaW4gOg0KPiA+DQo+ID4NCj4gPg0K PiA+IAkJCQlSMzIgIFRoZSBDRE5JIFJlcXVlc3QtUm91dGluZyBBUEkgU0hPVUxEIHN1cHBvcnQN Cj4gPiByZXF1ZXN0IGxvb3ANCj4gPg0KPiA+DQo+ID4gCQkJCSAgICBkZXRlY3Rpb24gYW5kIHBy ZXZlbnRpb24gKGUuZy4gIFByZXZlbnQNCj4gPiByZXF1ZXN0IGxvb3BpbmcgaW4gYQ0KPiA+DQo+ ID4NCj4gPiAJCQkJICAgIHNpdHVhdGlvbiB3aGVyZSBDRE4xIHJlZGlyZWN0cyB0byBDRE4yIHRo YXQNCj4gPiByZWRpcmVjdHMgdG8gQ0ROMw0KPiA+DQo+ID4NCj4gPiAJCQkJICAgIHRoYXQgd291 bGQgcmVkaXJlY3QgdG8gQ0ROMSkuDQo+ID4NCj4gPg0KPiA+DQo+ID4gCQkJCVIzMyAgVGhlIENE TkkgUmVxdWVzdC1Sb3V0aW5nIGxvb3AgcHJldmVudGlvbg0KPiA+IG1lY2hhbmlzbSBTSE9VTEQg YWxsb3cNCj4gPg0KPiA+DQo+ID4gCQkJCSAgICByb3V0aW5nIG9mIHRoZSByZXF1ZXN0IChhcyBv cHBvc2VkIHRvIHRoZQ0KPiA+IHJlcXVlc3QgbG9vcCBiZWluZw0KPiA+DQo+ID4NCj4gPiAJCQkJ ICAgIHNpbXBseSBpbnRlcnJ1cHRlZCB3aXRob3V0IHJvdXRpbmcgdGhlDQo+ID4gcmVxdWVzdCku DQo+ID4NCj4gPg0KPiA+DQo+ID4gCQkJCShhcyB3ZWxsIGFzIFIzOSBhbmQgUjQwIGZvciBsb25n ZXIgdGVybSkNCj4gPg0KPiA+DQo+ID4NCj4gPiAJCQkJUjU1ICBJZiBjYXNjYWRlZCBDRE5zIGFy ZSBzdXBwb3J0ZWQgYnkgdGhlIENETkkNCj4gPiBzb2x1dGlvbiwgdGhlIENETkkNCj4gPg0KPiA+ DQo+ID4gCQkJCSAgICBNZXRhZGF0YSBBUEkgTVVTVCBwcmV2ZW50IGxvb3Bpbmcgb2YgQ0ROSQ0K PiA+IE1ldGFkYXRhIGRpc3RyaWJ1dGlvbg0KPiA+DQo+ID4NCj4gPiAJCQkJICAgIGFjcm9zcyBD RE5zLg0KPiA+DQo+ID4NCj4gPg0KPiA+IAkJCQlEbyB5b3UgZ3V5cyBzdGlsbCB0aGluayBzb21l dGhpbmcgaXMgbWlzc2luZz8NCj4gPg0KPiA+DQo+ID4gCQkJCUNhbiB5b3Ugc3VnZ2VzdCBzb21l dGhpbmcgdG8gY292ZXIgbWlzc2luZyBiaXRzPw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gCQkJ Rm9yIENETkkgUmVxdWVzdCBSb3V0aW5nIHRoZSBhYm92ZSBpcyBmaW5lLiBXaGF0IEknbQ0KPiA+ IHNheWluZyBpcyBJIHRoaW5rIGxvb3AgZGV0ZWN0aW9uIGFsc28gYXBwbGllcyB0byB0aGUgY29u dHJvbCBBUEkgYW5kIG1heQ0KPiA+IGJlIHVzZWZ1bCBpbiB0aGUgb3RoZXIgQVBJcy4NCj4gPg0K PiA+DQo+ID4NCj4gPiAJCQlJJ2QgdGhlcmVmb3JlIHN1Z2dlc3QgbWFraW5nIGxvb3AgZGV0ZWN0 aW9uIGEgZ2VuZXJhbA0KPiA+IHJlcXVpcmVtZW50IChTSE9VTEQpIGFuZCBhbnkgbW9yZSBzcGVj aWZpYyByZXF1aXJlbWVudHMgKGUuZy4gUjMzKSB1bmRlcg0KPiA+IHRoZSBzcGVjaWZpYyBBUEkg dGhleSBhcHBseSB0by4NCj4gPg0KPiA+DQo+ID4NCj4gPiAJCUkgdGhpbmsgdGhlIHJlcXVpcmVt ZW50IGlzIHN0cm9uZ2VyOiBDRE5zIG5lZWQgdG8gYWdyZWUgb24gYQ0KPiA+IGNvbW1vbiBtZWNo YW5pc20gZm9yIGxvb3AgZGV0ZWN0aW9uOw0KPiA+DQo+ID4NCj4gPg0KPiA+IAlJIGFncmVlIGl0 IGlzIGEgTVVTVCAoYXMgYWxvbmcgYXMgImNhc2NhZGVkIENETnMiIGFyZSBzdXBwb3J0ZWQpLg0K PiA+IAlJbiB0aGUgUmVxdWlyZW1lbnRzIEktRCBpdCB3YXMgcHJlc2VudGVkOg0KPiA+IAkqIGFz IGEgIk1VU1QiIGZvciBsb25nZXIgdGVybQ0KPiA+IAkqIGFzIGEgIlNIT1VMRCIgZm9yIHNob3J0 ZXIgdGVybSwgYmVjYXVzZSBzdXBwb3J0IG9mIGNhc2NhZGVkIENETnMNCj4gPiBpdHNlbGYgaXMg b25seSBsaXN0ZWQgYXMgYSBTSE9VTEQgZm9yIHRoZSBzaG9ydGVyIHRlcm0gKG9uIHRoZSBncm91 bmRzDQo+ID4gdGhhdCBub3Qgc3VwcG9ydGluZyBpdCBtYXkgcG90ZW50aWFsbHkgYWxsb3cgZGVm aW5pdGlvbiBvZiBhIHNpbXBsZXINCj4gPiBzb2x1dGlvbiBmYXN0ZXIpDQo+ID4NCj4gPiAJSSB0 aGluayB3ZSBjb3VsZCBlaXRoZXI6DQo+ID4NCj4gPiAJKkEqOg0KPiA+IAkqIGFncmVlIHJpZ2h0 IG5vdyB0aGF0IHRoZSBzaG9ydGVyIHRlcm0gc29sdXRpb24gKGllIHdpdGhpbiBpbml0aWFsDQo+ ID4gY2hhcnRlciBzY29wZSkgTVVTVCBzdXBwb3J0IGNhc2NhZGVkIENETnMNCj4gPiAJKiBpbmNs dWRlIGEgTVVTVCByZXF1aXJlbWVudCBmb3IgbG9vcCBwcmV2ZW50aW9uIGluIHRoZSBHZW5lcmlj DQo+ID4gUmVxdHMgc2VjdGlvbiBhbmQgcG9zc2libHkgaW4gZWFjaCBBUEkgc3BlY2lmaWMgc2Vj dGlvbiAoQ29udHJvbCwNCj4gUmVxdWVzdC0NCj4gPiBSb3V0aW5nLCBNZXRhZGF0YSkNCj4gPg0K PiA+IAkqQjoNCj4gPiAJKiBkZWZlciB0aGUgZGVjaXNpb24gYWJvdXQgc3VwcG9ydCBvZiBjYXNj YWRlZCBDRE5zIGluIHNob3J0ZXIgdGVybQ0KPiA+IChpZSB3aXRoaW4gaW5pdGlhbCBjaGFydGVy IHNjb3BlKSB0byBmdXJ0aGVyIGRpc2N1c3Npb25zDQo+ID4gCSogaW5jbHVkZSBhICJjb25kaXRp b25hbCIgTVVTVCAoaWUgImlmIGNhc2NhZGVkIENETnMgYXJlDQo+ID4gc3VwcG9ydGVkLC4uLiIp IGluIHRoZSBHZW5lcmljIFJlcXRzIHNlY3Rpb24gYW5kIHBvc3NpYmx5IGluIGVhY2ggQVBJDQo+ ID4gc3BlY2lmaWMgc2VjdGlvbiAoQ29udHJvbCwgUmVxdWVzdC1Sb3V0aW5nLCBNZXRhZGF0YSkN Cj4gPg0KPiA+IAlJIHdvdWxkIHZvdGUgZm9yICpBKiBiZWNhdXNlOg0KPiA+IAkqIHdlIHdvdWxk bid0IHdhbnQgdG8gZ28gZm9yIGEgc2hvcnRlciB0ZXJtIHNvbHV0aW9uIHRoYXQgY2Fubm90IGJl DQo+ID4gZWFzaWx5IGV4dGVuZGVkIHRvIHN1cHBvcnQgY2FzY2FkZWQgQ0ROcw0KPiA+IAkqIHRo ZXJlIGFyZSBzaG9ydCB0ZXJtIHVzZSBjYXNlcyBmb3IgY2FzY2FkZWQgQ0ROcy4NCj4gPg0KPiA+ IAlvdGhlciB2b3RlcnM/DQo+ID4NCj4gPiAJVGhhbmtzDQo+ID4NCj4gPiAJRnJhbmNvaXMNCj4g Pg0KPiA+DQo+ID4NCj4gPiAJCW90aGVyd2lzZSB5b3UgY2FuIGdldCBtdWx0aXBsaWNhdGl2ZSBs b29wIGRpYW1ldGVycyBhbmQNCj4gPiBlZmZlY3RpdmVseSBub3QgaGF2ZSB1c2VmdWwgbG9vcCBk ZXRlY3Rpb24gd2hlbiB0aGUgbm9uLWxvb3BpbmcgcGF0aHMNCj4gYXJlDQo+ID4gbG9uZy4gVGhp cyBpcyByb3V0aW5nOyB3ZSBrbm93IHdoYXQgaGFwcGVucyB3aGVuIHlvdSBkbyBsb29wIGRldGVj dCB3aXRoDQo+ID4gdGhpbmcgbGlrZSBjb3VudC10by1pbmZpbml0eS4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAJCUluY2lkZW50bHksIG15IGZhdm9yaXRlIGxvb3AgZGV0ZWN0aW9uIHNjaGVtZSB3YXMg aW52ZW50ZWQgYnkNCj4gPiBLbnV0aCBhbGwgdGhlIHdheSBiYWNrIGluIHZvbHVtZSAyLiBJdCBo YXMgdGhlIG5pY2UgcHJvcGVydHkgb2YNCj4gZGV0ZWN0aW5nDQo+ID4gbG9vcHMgaW4gY29uc3Rh bnQgbWVtb3J5IGFuZCB3aXRoIGFuIHVwcGVyIGJvdW5kIG9mIHRyYXZlcnNpbmcgdGhlIGxvb3AN Cj4gMg0KPiA+IHRpbWVzLCBmb3IgYWxsIGxvb3AgZGlhbWV0ZXJzLiBMb29rIGl0IHVwIC0gaXQn cyBjYWxsZWQgdGhlICJldmVuLW9kZA0KPiA+IGl0ZXJhdGlvbiBjb3VudGluZyIuDQo+ID4NCj4g Pg0KPiA+DQo+ID4gCQlEYXZlTy4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IAkJCVRoYW5rcw0K PiA+DQo+ID4NCj4gPiAJCQlCZW4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IAkJCV9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPg0KPiA+IAkJ CUNETmkgbWFpbGluZyBsaXN0DQo+ID4NCj4gPg0KPiA+IAkJCUNETmlAaWV0Zi5vcmcNCj4gPg0K PiA+DQo+ID4gCQkJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiAJQ0ROaSBtYWlsaW5nIGxpc3QNCj4gPiAJQ0ROaUBpZXRmLm9y Zw0KPiA+IAlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPiA+IERp c3Rpbmd1aXNoZWQgRW5naW5lZXINCj4gPiBDb3Jwb3JhdGUgRGV2ZWxvcG1lbnQNCj4gPiBmbGVm YXVjaEBjaXNjby5jb20NCj4gPiBQaG9uZTogKzMzIDQ5IDcyMyAyNjE5DQo+ID4gTW9iaWxlOiAr MzMgNiAxOSA5OCA1MCA5MA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gCUNpc2NvIFN5c3RlbXMg RnJhbmNlDQo+ID4gR3JlZW5zaWRlDQo+ID4gNDAwIEF2ZSBkZSBSb3VtYW5pbGxlDQo+ID4gMDY0 MTAgU29waGlhIEFudGlwb2xpcw0KPiA+IEZyYW5jZQ0KPiA+IENpc2NvLmNvbSA8aHR0cDovL3d3 dy5jaXNjby5jb20+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgVGhp bmsgYmVmb3JlIHlvdSBwcmludC4NCj4gPg0KPiA+IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KPiA+IHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBv cg0KPiBkaXNjbG9zdXJlDQo+ID4gYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQNCj4gPiAob3IgYXV0aG9yaXplZCB0 byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlcg0K PiBieQ0KPiA+IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3Nh Z2UuDQo+ID4NCj4gPiBDaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNh YmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZQ0KPiA+IERlc21vdWxpbnMg4oCTIEltbSBBdGxh bnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzDQo+IE1vdWxpbmVhdXgs DQo+ID4gQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUs IERpcmVjdGV1ciBkZSBsYQ0KPiA+IHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25l Lg0KPiA+DQo+ID4gRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCj4gPiBo dHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2lu ZGV4Lmh0bWwNCj4gPg0KPiA+DQoNCg== From philip.eardley@bt.com Fri Feb 11 07:49:39 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E297F3A68D4 for ; Fri, 11 Feb 2011 07:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.586 X-Spam-Level: X-Spam-Status: No, score=-101.586 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAZRId7pvEOb for ; Fri, 11 Feb 2011 07:49:38 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id D22B63A691E for ; Fri, 11 Feb 2011 07:49:37 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 11 Feb 2011 15:49:51 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.67]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 11 Feb 2011 15:49:51 +0000 From: To: , Date: Fri, 11 Feb 2011 15:49:50 +0000 Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AcvDjSBTYhM2IaB0QTKHQvcN8YOeQADDDahwANX9PAAAAcLlwAACowhQ Message-ID: <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:49:39 -0000 Li4NCj4gW3BoaWxdIHdlbGwsIGluIHRoZSBjYXNlIHdpdGggb25seSAyIENETnMgaW50ZXJjb25u ZWN0ZWQsIHNvbHZpbmcgbG9vcA0KPiBkZXRlY3Rpb24gaXMgdHJpdmlhbDsgaWYgdGhlcmUgaXMg YSBjaGFpbiB0aGVuIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0DQo+IHRoZSBpc3N1ZXMgYXJl IHRyaXZpYWwuIA0KDQpJTU8gdGhlIGNoZWNrIGlzIGlkZW50aWNhbCBpbiBib3RoIGNhc2VzOiBh IENETiBtdXN0IGNoZWNrIHRoYXQgaXQgaXMgbm90IHRyeWluZyB0byBwcm92aWRlIGEgc2Vydmlj ZSB0aGF0IGl0IGFza2VkIGZvci4NCg0KW3BoaWxdIGlmIHRoZSBjaGFpbiBvZiBDRE5zIGlzOg0K QSAtIEIgLSBDIC0gRCAtIEINCkRldGVjdGluZyB0aGUgbG9vcCBpcyBub3QgKGkgdGhpbmspIGFz IGVhc3kgYXMgaXMgaW4gdGhlIGNhc2U6DQpBIC0gQiAtIEENCg0KRG8gd2UgZGVmaW5lZCAnY2hh aW4nID8NCltwaGlsXSBub3QgYXMgZmFyIGFzIGkga25vdyAtIHByb2JhYmx5IG5vdCB0aGUgYmVz dCB0ZXJtDQo= From saverio.mascolo@gmail.com Fri Feb 11 08:05:23 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1203A688F for ; Fri, 11 Feb 2011 08:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q187ujpFSoal for ; Fri, 11 Feb 2011 08:05:20 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 17C6C3A67DA for ; Fri, 11 Feb 2011 08:05:19 -0800 (PST) Received: by bwz12 with SMTP id 12so3650006bwz.31 for ; Fri, 11 Feb 2011 08:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=g49QNoNPhSotH7EKETxY0pjdcC0GTV971U1j7uwmAT0=; b=tQ+CcGIWkeRrBm0dlX0IgBb9PxRshrX9s18g9EsJBixaHleTEf0LBkCzpOhqlyEp8J ULvUtPjGseDkC9QoDYnFT5P1Qv4Iay5+no43UNRZ+c+AcfyOCwQZgZk1q7T4DYidmunv TIuieJoxapWofzyWRbWHJ+zluMJLzND2G/hJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sdm95g6Cw381A1Mu9zcHlQQHtXt7NsBZPR2ZUQ7SefjPPFxO2GzY0QbBtm5460YEOg dMZKDtarJu4aSBhkkKKGKOSiJPwhdF5Ne/832rcBAq5iG6pkly/TO5CZr225zrIsTPrL RCuRCIsOib6l9dQPKBNNFlYtKWL9gUVRNP9h0= Received: by 10.204.33.70 with SMTP id g6mr9959475bkd.177.1297440334461; Fri, 11 Feb 2011 08:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.104.19 with HTTP; Fri, 11 Feb 2011 08:05:14 -0800 (PST) In-Reply-To: <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk> <4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com> <9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> From: Saverio Mascolo Date: Fri, 11 Feb 2011 17:05:14 +0100 Message-ID: To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=00032555e47e40bc8d049c03dea2 Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@cable.comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:05:23 -0000 --00032555e47e40bc8d049c03dea2 Content-Type: text/plain; charset=ISO-8859-1 i am new here...but old with graphs...what about using digraphs? On Fri, Feb 11, 2011 at 4:49 PM, wrote: > .. > > [phil] well, in the case with only 2 CDNs interconnected, solving loop > > detection is trivial; if there is a chain then it is not clear to me that > > the issues are trivial. > > IMO the check is identical in both cases: a CDN must check that it is not > trying to provide a service that it asked for. > > [phil] if the chain of CDNs is: > A - B - C - D - B > Detecting the loop is not (i think) as easy as is in the case: > A - B - A > > Do we defined 'chain' ? > [phil] not as far as i know - probably not the best term > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > -- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. --00032555e47e40bc8d049c03dea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i am new here...but old with graphs...what about using digraphs?

On Fri, Feb 11, 2011 at 4:49 PM, <philip.eardley@bt.com>= wrote:
..
> [phil] well, in the case with only 2 CDNs interconnected, solving loop=
> detection is trivial; if there is a chain then it is not clear to me t= hat
> the issues are trivial.

IMO the check is identical in both cases: a CDN must check that it is not t= rying to provide a service that it asked for.

[phil] if the chain of CDNs is:
A - B - C - D - B
Detecting the loop is not (i think) as easy as is in the case:
A - B - A

Do we defined 'chain' ?
[phil] not as far as i know - probably not the best term
_________________________________________= ______
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni



--
Prof. Saver= io Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico = di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. = +39 080 5963410
email:mascolo@poliba.it=A0
http://c3lab.poliba.it

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0This message may contain confidential = and/or legally privileged information.
=A0 If you are not the intended recipient of the message, please destroy it= .
=A0Any unauthorized dissemination, distribution, or copying of the mat= erial in
=A0this message, and any attachments to the message, is strictl= y forbidden.
--00032555e47e40bc8d049c03dea2-- From oran@cisco.com Sat Feb 12 06:43:34 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7AF3A696B for ; Sat, 12 Feb 2011 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJDwRhS1WlNl for ; Sat, 12 Feb 2011 06:43:33 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B35003A697B for ; Sat, 12 Feb 2011 06:43:33 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: PGP.sig : 193 X-IronPort-AV: E=Sophos;i="4.60,461,1291593600"; d="sig'?scan'208";a="262121078" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2011 14:43:51 +0000 Received: from sjc-vpnasa-788.cisco.com (sjc-vpnasa-788.cisco.com [10.21.107.19]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1CEhJ2A027888; Sat, 12 Feb 2011 14:43:50 GMT Received: from [127.0.0.1] by sjc-vpnasa-788.cisco.com (PGP Universal service); Sat, 12 Feb 2011 09:43:51 -0500 X-PGP-Universal: processed; by sjc-vpnasa-788.cisco.com on Sat, 12 Feb 2011 09:43:51 -0500 Mime-Version: 1.0 (Apple Message framework v1082) From: David R Oran In-Reply-To: <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> Date: Sat, 12 Feb 2011 09:43:13 -0500 Message-Id: <9E0EDBFE-EA2E-4373-8099-E8A87FA7B07C@cisco.com> References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_1214741F_318CE561_A201FA00_DB2B7A76"; protocol="application/pgp-signature"; micalg="pgp-sha1" Cc: cdni@ietf.org, mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 14:43:34 -0000 --PGP_Universal_1214741F_318CE561_A201FA00_DB2B7A76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Feb 11, 2011, at 10:49 AM, wrote: > .. >> [phil] well, in the case with only 2 CDNs interconnected, solving = loop >> detection is trivial; if there is a chain then it is not clear to me = that >> the issues are trivial.=20 >=20 > IMO the check is identical in both cases: a CDN must check that it is = not trying to provide a service that it asked for. >=20 I don't think it's quite that straightforward semantically - having been = through the subtleties of spirals in SIP I'm not convinced it's easy to = ascertain whether you are being asked to provide a service that you have = outstanding. This is especially tricky if you have a distributed = implementation of hat looks like a single CDN node to the outside world. = On the other hand, checking for a request loop is easier than checking = for a service loop, because the latter is mechanical and does not have = to "back map" to the semantic level of figuring out what the service = being requested is/was. > [phil] if the chain of CDNs is: > A - B - C - D - B > Detecting the loop is not (i think) as easy as is in the case: > A - B - A >=20 Depends on the algorithm. For most of the algorithms using only local = state (as opposed to putting state in the messages, like a hop count), = the complexity of what A has to do in your second example is in fact no = simpler than what B has to do in your first. For hop count algorithms, = the diameter of the loop is of course irrelevant. > Do we defined 'chain' ? > [phil] not as far as i know - probably not the best term Well, the request pattern could just as easily be a tree or some other = graph, no? Is there some prohibition against forking requests, or did I = miss that in the draft? > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --PGP_Universal_1214741F_318CE561_A201FA00_DB2B7A76 Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.0.3 (Build 1) iQA/AwUBTVacno1mhLZU3SrmEQIwEgCgnjEvtOFJqcTPE0vZK7+La3ZXURUAn2zH YiWSpyjANmwYHoMsCdMA8I9c =t8vq -----END PGP SIGNATURE----- --PGP_Universal_1214741F_318CE561_A201FA00_DB2B7A76-- From flefauch@cisco.com Mon Feb 14 01:12:14 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7123A6C87 for ; Mon, 14 Feb 2011 01:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.33 X-Spam-Level: X-Spam-Status: No, score=-9.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3tnFwK9Qb2M for ; Mon, 14 Feb 2011 01:12:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0BC713A6C7D for ; Mon, 14 Feb 2011 01:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3937; q=dns/txt; s=amsiport01001; t=1297674756; x=1298884356; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vjGOF20Mliie8KzofIssVPmMeYnpFmn0YNkP0Tg+IZU=; b=Er5O3ho6m++Ex5N+nRq6/XUiMXBaFpZpIyoxV2UC67eCckFC+6m9/wSK 0ZKGCiBEuANr98hXsfc2162AsYVVdjQWgyIygYyiAtxiYZxdtlhkus2FW O6NYX0nzMOhOkQsczY3yFQZFecgAj1hSQ77mkDGJtrhtNzola4FdAK8AG 4=; X-IronPort-AV: E=Sophos;i="4.60,468,1291593600"; d="scan'208";a="76184022" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 09:12:34 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1E9CWqS024333; Mon, 14 Feb 2011 09:12:32 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <9E0EDBFE-EA2E-4373-8099-E8A87FA7B07C@cisco.com> Date: Mon, 14 Feb 2011 10:13:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86DE0C78-237E-44C8-91F6-13A8CD0BD1A9@niven-jenkins.co.uk><4FCF673E-885A-42A4-8581-5801D3345FC6@cisco.com><9510D26531EF184D9017DF24659BB87F327819EFFA@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017967C2@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F327910867E@EMV65-UKRD.domain1.systemhost.net> <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> <9510D26531EF184D9017DF24659BB87F3279108822@EMV65-UKRD.domain1.systemhost.net> <9E0EDBFE-EA2E-4373-8099-E8A87FA7B07C@cisco.com> To: David R Oran X-Mailer: Apple Mail (2.1082) Cc: mvittal@cisco.com, Yiu_Lee@Cable.Comcast.com, cdni@ietf.org Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 09:12:14 -0000 Folks, On 12 Feb 2011, at 15:43, David R Oran wrote: >=20 > On Feb 11, 2011, at 10:49 AM, wrote: >=20 >> .. >>> [phil] well, in the case with only 2 CDNs interconnected, solving = loop >>> detection is trivial; if there is a chain then it is not clear to me = that >>> the issues are trivial.=20 >>=20 >> IMO the check is identical in both cases: a CDN must check that it is = not trying to provide a service that it asked for. >>=20 > I don't think it's quite that straightforward semantically - having = been through the subtleties of spirals in SIP I'm not convinced it's = easy to ascertain whether you are being asked to provide a service that = you have outstanding. This is especially tricky if you have a = distributed implementation of hat looks like a single CDN node to the = outside world. On the other hand, checking for a request loop is easier = than checking for a service loop, because the latter is mechanical and = does not have to "back map" to the semantic level of figuring out what = the service being requested is/was. >=20 >> [phil] if the chain of CDNs is: >> A - B - C - D - B >> Detecting the loop is not (i think) as easy as is in the case: >> A - B - A >>=20 > Depends on the algorithm. For most of the algorithms using only local = state (as opposed to putting state in the messages, like a hop count), = the complexity of what A has to do in your second example is in fact no = simpler than what B has to do in your first. For hop count algorithms, = the diameter of the loop is of course irrelevant. >=20 >> Do we defined 'chain' ? >> [phil] not as far as i know - probably not the best term > Well, the request pattern could just as easily be a tree or some other = graph, no? Is there some prohibition against forking requests, or did I = miss that in the draft? The I-D currently states than any topology of interconnected CDNs SHOULD = be supported: " 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.). " The I-D currently refers to "cascaded CDNs" as the scenario where a CDN = to which a request is redirected, in turn will redirect the request to = another CDN: " R8 The CDNI solution SHOULD support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels. " The I-D currently refers to the "chain of CDNs" in the context of a = given request. ie for a given request, that request has been routed over = a chain of CDNs (CDN1-->CDN2-->CDN3). Again, this is only relative to a = particular request: " R71 The CDNI solution MUST be able to ensure that for any given request redirected to a Downstream CDN, the chain of CDN Delegation (leading to that request being served by that CDN) can be established with non-repudiation. " Focusing on the "Requirements I-D", I propose that, for now, we: * move the MUST requirement for loop prevention in the generic = section * keep the SHOULD requirements for support of cascaded CDNs = (over arbitrary interconnected CDN topologies) in the generic section As potential solutions are discussed and better understood, the group = can make a decision on whether "cascaded CDNs" are supported or not in = initial scope and, given that fact how to perform loop prevention = (noting Dave's point above that depending on how loop prevention is = performed, its complexity may or may not depend on support of cascaded = CDNs). Additional discussions on potential solutions are welcome, but I'd like = to have a base proposal for the Requirement I-D. Francois >=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From yiu_lee@cable.comcast.com Mon Feb 14 10:58:52 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683D63A6A15 for ; Mon, 14 Feb 2011 10:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.315 X-Spam-Level: X-Spam-Status: No, score=-100.315 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBFqcIzP+Ayn for ; Mon, 14 Feb 2011 10:58:50 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 750413A6D9B for ; Mon, 14 Feb 2011 10:58:50 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.25780881; Mon, 14 Feb 2011 12:10:33 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Mon, 14 Feb 2011 13:59:07 -0500 From: "Lee, Yiu" To: "emile.stephan@orange-ftgroup.com" , "philip.eardley@bt.com" , "flefauch@cisco.com" Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AQHLzHlBW4guApVZokWlFRWkKhF7VQ== Date: Mon, 14 Feb 2011 18:59:07 +0000 Message-ID: In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4FC7@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" , "mvittal@cisco.com" Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:58:52 -0000 SGkgUGhpbCwgRW1pbGUgYW5kIGFsbCwNCg0KSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhhdCB0aGVy ZSBpcyBhIHJlcXVpcmVtZW50IHRvIHByZXZlbnQgbG9vcGluZy4gSXQgaXMNCmFzIGltcG9ydGFu dCB0byBwcmV2ZW50IGxvb3BpbmcgYXQgMS1sZXZlbCBkZWVwIG9yIG11bHRpcGxlLWxldmVsIGRl ZXAuIFdlDQphbHNvIGFncmVlIHRoYXQgdGhlIFJvdXRpbmcgUmVxdWVzdCBBUEkgc2hvdWxkIGFs c28gaW5kaWNhdGUgdGhlIG1heCBsZXZlbA0Kb2YgZGVsZWdhdGlvbiBzaG91bGQgYWxsb3cuIFRo ZXNlIGFyZSBhbGwgY2FwdHVyZWQgaW4gdGhlIFJFUS1JRC4gSWYgdGhleQ0KYXJlIG5vdCBjbGVh ciwgd2UgYXJlIHdlbGNvbWUgdG8gYW55IGlucHV0IHRvIGltcHJvdmUgdGhlIFJFUS1JRC4NCg0K UGVyaGFwcyBpdCBtYXkgYmUgdG9vIGVhcmx5IHRvIHNwZWFrIG9mIHNvbHV0aW9uLCBidXQgSSB3 b3VsZCBsb3ZlIHRvIGhlYXINCnBlb3BsZSBmbG93aW5nIGlkZWFzIGluIHRoZSBsaXN0IDotKQ0K DQpDaGVlcnMsDQpZaXUNCg0KDQpPbiAyLzExLzExIDEwOjIzIEFNLCAiZW1pbGUuc3RlcGhhbkBv cmFuZ2UtZnRncm91cC5jb20iDQo8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UtZnRncm91cC5jb20+IHdy b3RlOg0KDQo+SGkgUGhpbCwNCj4NCj5TZWUgYmVsb3cNCj4NCj4+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPj4gRGUgOiBwaGlsaXAuZWFyZGxleUBidC5jb20gW21haWx0bzpwaGlsaXAu ZWFyZGxleUBidC5jb21dDQo+PiBFbnZvecOpIDogdmVuZHJlZGkgMTEgZsOpdnJpZXIgMjAxMSAx NDo1OQ0KPj4gw4AgOiBTVEVQSEFOIEVtaWxlIFJELUNPUkUtTEFOOyBmbGVmYXVjaEBjaXNjby5j b20NCj4+IENjIDogbXZpdHRhbEBjaXNjby5jb207IGNkbmlAaWV0Zi5vcmc7IFlpdV9MZWVAQ2Fi bGUuQ29tY2FzdC5jb20NCj4+IE9iamV0IDogUkU6IFtDRE5pXSBMb29wIGRldGVjdGlvbiByZXF1 aXJlbWVudA0KPj4gDQo+PiANCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLWZ0Z3JvdXAuY29tIFttYWlsdG86ZW1pbGUuc3Rl cGhhbkBvcmFuZ2UtDQo+PiBmdGdyb3VwLmNvbV0NCj4+IFNlbnQ6IDA3IEZlYnJ1YXJ5IDIwMTEg MDg6MjkNCj4+IFRvOiBmbGVmYXVjaEBjaXNjby5jb207IEVhcmRsZXksUEwsUGhpbGlwLERFUzgg Ug0KPj4gQ2M6IG12aXR0YWxAY2lzY28uY29tOyBjZG5pQGlldGYub3JnOyBZaXVfTGVlQENhYmxl LkNvbWNhc3QuY29tDQo+PiBTdWJqZWN0OiBSRTogW0NETmldIExvb3AgZGV0ZWN0aW9uIHJlcXVp cmVtZW50DQo+PiANCj4+IEhpIEZyYW5jb2lzLA0KPj4gDQo+PiBDRE5JIGludGVyZmFjZXMgbXVz dCBzdXBwb3J0IGxvb3AgZGV0ZWN0aW9uIGV2ZW4gd2hlbiB0aGVyZSBpcyBvbmx5IDINCj4+Q0RO cw0KPj4gaW50ZXJjb25uZWN0ZWQuIEhlbmNlIHRoaXMgcmVxIGlzIHRpZWQgbm9yIHRvIHRoZSBu dW1iZXIgb2YgQ0ROcyBvZiB0aGUNCj4+IENETmkgY2hhaW4gbm9yIHRvIGl0cyBuYXR1cmUuDQo+ PiANCj4+IFNvIGltbyBzdXBwb3J0IGZvciBsb29wIGRldGVjdGlvbiBpcyBhIGdlbmVyaWMgTVVT VCB0aGF0IGFwcGxpZXMgdG8gZWFjaA0KPj4gQ0ROaSBBUElzLg0KPj4gDQo+PiBbcGhpbF0gd2Vs bCwgaW4gdGhlIGNhc2Ugd2l0aCBvbmx5IDIgQ0ROcyBpbnRlcmNvbm5lY3RlZCwgc29sdmluZyBs b29wDQo+PiBkZXRlY3Rpb24gaXMgdHJpdmlhbDsgaWYgdGhlcmUgaXMgYSBjaGFpbiB0aGVuIGl0 IGlzIG5vdCBjbGVhciB0byBtZQ0KPj50aGF0DQo+PiB0aGUgaXNzdWVzIGFyZSB0cml2aWFsLg0K Pg0KPklNTyB0aGUgY2hlY2sgaXMgaWRlbnRpY2FsIGluIGJvdGggY2FzZXM6IGEgQ0ROIG11c3Qg Y2hlY2sgdGhhdCBpdCBpcyBub3QNCj50cnlpbmcgdG8gcHJvdmlkZSBhIHNlcnZpY2UgdGhhdCBp dCBhc2tlZCBmb3IuDQo+DQo+RG8gd2UgZGVmaW5lZCAnY2hhaW4nID8NCj4NCj5SZWdhcmRzDQo+ ZW1pbGUgDQo+DQo+DQo+VGhpcyBpcyBub3QganVzdCBhYm91dCBsb29wIGRldGVjdGlvbiAtIGZv cg0KPj4gaW5zdGFuY2UsIGZvciB0aGUgbG9nZ2luZyBBUEksIGRvIHlvdSBuZWVkIGEgY29tbW9u IGFncmVlbWVudCBhbG9uZyB0aGUNCj4+IGNoYWluIGFib3V0IGxvZ2dpbmcgZm9ybWF0LCBzZWN1 cml0eSwgd2hhdCAicmVhbCB0aW1lIiBtZWFucywgZXRjPyBFZywNCj4+aWYNCj4+IEEgJiBCIGFn cmVlIG9uZSBmb3JtYXQgYW5kIEIgJiBDIGFncmVlIGEgZGlmZmVyZW50IGZvcm1hdCwgdGhlbiBk byB5b3UNCj4+IG5lZWQgdG8gdHJhbnNsYXRlIGl0Pw0KPj4gSWYgdGhlICJjaGFpbiBpc3N1ZXMi IGFyZSB0cmlja3kgdG8gc29sdmUsIHRoZW4gc3RhcnRpbmcgd2l0aCB0aGUNCj4+IGFzc3VtcHRp b24gb2Ygbm8gY2hhaW4gd291bGQgbWFrZSB0aGUgc2NvcGUgbW9yZSBtYW5hZ2VhYmxlLiBPZiBj b3Vyc2UsDQo+PmlmDQo+PiB0aGUgImNoYWluIGlzc3VlcyIgYXJlIGVhc3kgdG8gc29sdmUgdGhl biB0aGUgc2NvcGUgaXMgc3RpbGwgbWFuYWdlYWJsZS4NCj4+IFBoaWwvDQo+PiANCj4+IA0KPj4g SSBzdWdnZXN0IGluc2VydGluZyB0aGlzIHJlcSBkaXJlY3RseSBpbiB0aGUgaGVhZGVyIG9mIHRo ZSBzZWN0aW9uIDMgb2YNCj4+IHRoZSByZXEgZHJhZnQuDQo+PiANCj4+IA0KPj4gUmVnYXJkcw0K Pj4gRW1pbGUNCj4+IA0KPj4gDQo+PiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4g PiBEZSA6IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydA0KPj5kZQ0KPj4gPiBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPj4gPiBFbnZv ecOpIDogamV1ZGkgMyBmw6l2cmllciAyMDExIDExOjI5DQo+PiA+IMOAIDogcGhpbGlwLmVhcmRs ZXlAYnQuY29tDQo+PiA+IENjIDogbXZpdHRhbEBjaXNjby5jb207IGNkbmlAaWV0Zi5vcmc7IFlp dV9MZWVAQ2FibGUuQ29tY2FzdC5jb20NCj4+ID4gT2JqZXQgOiBSZTogW0NETmldIExpbWl0IG5i IG9mIHJlZGlyZWN0cyAmIGxvb3Agc1JlOiBDRE5JIFJlcXVpcmVtZW50cw0KPj4gSS1EDQo+PiA+ DQo+PiA+IEhpIFBoaWwsDQo+PiA+DQo+PiA+IE9uIDMgRmViIDIwMTEsIGF0IDExOjE4LCA8cGhp bGlwLmVhcmRsZXlAYnQuY29tPiB3cm90ZToNCj4+ID4NCj4+ID4NCj4+ID4gICAgIENhc2NhZGVk IENETnMgd291bGQgYmUgbmljZS4NCj4+ID4NCj4+ID4gICAgIENhc2NhZGluZyBpcyBtaXNzaW5n IGZyb20gdGhlIGxvZ2dpbmcgc2VjdGlvbiAtIHdoZXJlIGl0IHNlZW1zDQo+PmhhcmQuDQo+PiA+ IHRoZSBsb2dnaW5nIHJlY29yZCBuZWVkcyB0byBpbmNsdWRlIChhZ2dyZWdhdGVkKSBpbmZvIHdo ZXJlIGNvbnRlbnQNCj4+aGFzDQo+PiA+IGJlZW4gZGVsaXZlcmVkIHRvIGEgVUEgYnkgYSBDRE4g ZnVydGhlciBkb3duIGEgY2FzY2FkZSBvZiBDRE5zLg0KPj4gPg0KPj4gPg0KPj4gPiBUaGVyZSBh cmUgcmVxdWlyZW1lbnRzIGluIHRoZSBTZWN1cml0eSBzZWN0aW9uIHRoYXQgcmVsYXRlIHRvIHRo YXQ6DQo+PiA+DQo+PiA+ICINCj4+ID4gICAgUjcxICBUaGUgQ0ROSSBzb2x1dGlvbiBNVVNUIGJl IGFibGUgdG8gZW5zdXJlIHRoYXQgZm9yIGFueSBnaXZlbg0KPj4gPiAgICAgICAgIHJlcXVlc3Qg cmVkaXJlY3RlZCB0byBhIERvd25zdHJlYW0gQ0ROLCB0aGUgY2hhaW4gb2YgQ0RODQo+PiA+ICAg ICAgICAgRGVsZWdhdGlvbiAobGVhZGluZyB0byB0aGF0IHJlcXVlc3QgYmVpbmcgc2VydmVkIGJ5 IHRoYXQgQ0ROKQ0KPj4gPiAgICAgICAgIGNhbiBiZSBlc3RhYmxpc2hlZCB3aXRoIG5vbi1yZXB1 ZGlhdGlvbi4NCj4+ID4NCj4+ID4gICAgUjcyICBUaGUgQ0ROSSBzb2x1dGlvbiBNVVNUIGJlIGFi bGUgdG8gZW5zdXJlIHRoYXQgdGhlIERvd25zdHJlYW0NCj4+Q0RODQo+PiA+ICAgICAgICAgY2Fu bm90IHNwb29mIGEgdHJhbnNhY3Rpb24gbG9nIGF0dGVtcHRpbmcgdG8gYXBwZWFyIGFzIGlmIGl0 DQo+PiA+ICAgICAgICAgY29ycmVzcG9uZHMgdG8gYSByZXF1ZXN0IHJlZGlyZWN0ZWQgYnkgYSBn aXZlbiBVcHN0cmVhbSBDRE4NCj4+d2hlbg0KPj4gPiAgICAgICAgIHRoYXQgcmVxdWVzdCBoYXMg bm90IGJlZW4gcmVkaXJlY3RlZCBieSB0aGlzIFVwc3RyZWFtIENETi4NCj4+ID4gIg0KPj4gPg0K Pj4gPiBUaGlzIGlzIG1lYW50IHRvIGFwcGx5IGFsc28gdG8gdGhlIExvZ2dpbmcgQVBJLg0KPj4g PiBJcyB0aGF0IHN1ZmZpY2llbnQgdG8gY2FwdHVyZSB0aGUgdG9waWMgb3IgZG8geW91IHdhbnQg dG8gc2VlIGENCj4+c3BlY2lmaWMNCj4+ID4gcmVxdWlyZW1lbnQgdW5kZXIgdGhlICJMb2dnaW5n IEFQSSIgc2VjdGlvbj8NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgIFRoaXMgaXMgcXVpdGUg Y2hhbGxlbmdpbmcsIGVzcGVjaWFsbHkgaWYgb25lIGFsbG93cyBhbnkNCj4+ZmxleGliaWxpdHkN Cj4+ID4gb3ZlciB3aGF0IGlzIHJlcG9ydGVkLCBmb3JtYXQgb2YgcmVwb3J0cywgc2VjdXJpdHkg bWV0aG9kcywgcmVhbC10aW1lDQo+PiA+IHJlcG9ydHMsIGV0Yy4NCj4+ID4NCj4+ID4NCj4+ID4N Cj4+ID4gICAgIEFncmVlIHRoYXQgY2FzY2FkaW5nIHNob3VsZCBiZSBtZW50aW9uZWQgYXMgYSBn ZW5lcmljIHJlcXVpcmVtZW50DQo+Pi0NCj4+ID4gYW5kIHdlIHRyZWF0IGl0IGF0IHRoZSBzYW1l IHJlcXVpcmVtZW50cyBsZXZlbCBmb3IgYWxsIHRoZSBBUElzDQo+Pih3aGV0aGVyDQo+PiA+IHRo YXQnczogTVVTVCBpbiBpbml0aWFsIHNjb3BlLCBTSE9VTEQsIG9yIGJleW9uZCBpbml0aWFsIHNj b3BlKS4NCj4+ID4NCj4+ID4gICAgIFBlcnNvbmFsbHkgdGhpbmsgdGhlcmUgaXMgcXVpdGUgYSBs b3QgIndpdGhpbiBpbml0aWFsIHNjb3BlIiBpbg0KPj50aGUNCj4+ID4gcmVxdWlyZW1lbnRzIGRy YWZ0LCBhbmQgY2FzY2FkaW5nIG1pZ2h0IGJlIGRlZmVycmFibGUgaWYgaXQgYWRkcw0KPj4gPiBz aWduaWZpY2FudCB3b3JrIHRvIHN0YW5kYXJkaXNpbmcgdGhlIEFQSXMgLSBhcyBtb3N0IG9mIHRo ZSB2YWx1ZSBvZg0KPj5DRE4NCj4+ID4gaW50ZXJjb25uZWN0IHNlZW1zIHRvIGNvbWUgZnJvbSB0 aGUgIm9uZSBob3AiIGNhc2UgaWU6DQo+PiA+ICAgICBDU1AgLT4gVXBzdHJlYW0gQ0ROIC0+IERv d25zdHJlYW0gQ0ROIC0+IFVBDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEkgdGFrZSB0aGlzIGFz IGEgIkIiIFZvdGUuDQo+PiA+DQo+PiA+IFRoYW5rcw0KPj4gPg0KPj4gPiBGcmFuY29pcw0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+ID4gICAgIEZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNl c0BpZXRmLm9yZ10gT24NCj4+QmVoYWxmDQo+PiA+IE9mIEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+ PiA+ICAgICBTZW50OiAwMiBGZWJydWFyeSAyMDExIDEwOjQ1DQo+PiA+ICAgICBUbzogRGF2aWQg UiBPcmFuDQo+PiA+ICAgICBDYzogY2RuaUBpZXRmLm9yZzsgVml2ZWdhbmFuZGhhbiBNYWhlc2g7 IFlpdSBMZWUNCj4+ID4gICAgIFN1YmplY3Q6IFJlOiBbQ0ROaV0gTGltaXQgbmIgb2YgcmVkaXJl Y3RzICYgbG9vcCBzUmU6IENETkkNCj4+ID4gUmVxdWlyZW1lbnRzIEktRA0KPj4gPg0KPj4gPiAg ICAgRGF2ZSBhbmQgYWxsLA0KPj4gPg0KPj4gPiAgICAgT24gMiBGZWIgMjAxMSwgYXQgMDE6NTMs IERhdmlkIFIgT3JhbiB3cm90ZToNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAg ICBPbiBGZWIgMSwgMjAxMSwgYXQgMjoyNSBQTSwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6DQo+ PiA+DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAgICAgIEZyYW5jb2lzLA0KPj4gPg0KPj4gPg0K Pj4gPg0KPj4gPiAgICAgICAgICAgICBPbiAxIEZlYiAyMDExLCBhdCAxOTowMCwgRnJhbmNvaXMg TGUgRmF1Y2hldXIgd3JvdGU6DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAgICAgICAgICBUaGlz IGRpc2N1c3Npb24gZHJpZnRlZCBmcm9tIChpKSB0aGUgYWJpbGl0eSB0bw0KPj4gPiBsaW1pdCB0 aGUgbnVtYmVyIG9mIENETiByZWRpcmVjdGlvbnMgKGZvciB0aGUgc2FrZSBvZiBhdm9pZGluZw0K Pj4gZGVncmFkYXRpb24NCj4+ID4gb2YgdXNlciBleHBlcmllbmNlKSBpbnRvIGEgZGlzY3Vzc2lv biBvbiAoaWkpIHByZXZlbnRpbmcgbG9vcHMgaW4NCj4+IHJlcXVlc3QNCj4+ID4gdG91dGluZyBh bmQgb3RoZXIgaW5mb3JtYXRpb24gZXhjaGFuZ2UuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+ PiA+ICAgICAgICAgICAgIFRoYXQncyBteSBmYXVsdCBiZWNhdXNlIEkgd2Fzbid0IGRpc3Rpbmd1 aXNoaW5nIGJldHdlZW4NCj4+ID4gbG9vcCBkZXRlY3Rpb24gb2YgQ0ROIHJlZGlyZWN0aW9ucyBh bmQgb3RoZXIgdHlwZXMgb2YgbG9vcCBkZXRlY3Rpb24uDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ ICAgICAgICAgICAgICAgICAoaSkgaXMgYWRkcmVzc2VkIGluOg0KPj4gPg0KPj4gPg0KPj4gPiAg ICAgICAgICAgICAgICAgIg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICAgICAgUjM0ICBU aGUgQ0ROSSBSZXF1ZXN0LVJvdXRpbmcgQVBJIFNIT1VMRCBzdXBwb3J0DQo+PiA+IG9wdGlvbmFs IGVuZm9yY2VtZW50DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAgICAgICAgICAgICAgb2YgYSBs aW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1Y2Nlc3NpdmUgQ0RODQo+PiA+IHJlZGlyZWN0aW9ucyBm b3IgYQ0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICAgICAgICAgIGdpdmVuIHJlcXVlc3Qu DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAgICAgICAgICAiDQo+PiA+DQo+PiA+DQo+PiA+DQo+ PiA+ICAgICAgICAgICAgICAgICAoaWkpIGlzIGN1cnJlbnRseSBhZGRyZXNzZWQgaW4gOg0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICAgICAgUjMyICBUaGUgQ0ROSSBSZXF1ZXN0 LVJvdXRpbmcgQVBJIFNIT1VMRCBzdXBwb3J0DQo+PiA+IHJlcXVlc3QgbG9vcA0KPj4gPg0KPj4g Pg0KPj4gPiAgICAgICAgICAgICAgICAgICAgIGRldGVjdGlvbiBhbmQgcHJldmVudGlvbiAoZS5n LiAgUHJldmVudA0KPj4gPiByZXF1ZXN0IGxvb3BpbmcgaW4gYQ0KPj4gPg0KPj4gPg0KPj4gPiAg ICAgICAgICAgICAgICAgICAgIHNpdHVhdGlvbiB3aGVyZSBDRE4xIHJlZGlyZWN0cyB0byBDRE4y IHRoYXQNCj4+ID4gcmVkaXJlY3RzIHRvIENETjMNCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICAg ICAgICAgICAgICB0aGF0IHdvdWxkIHJlZGlyZWN0IHRvIENETjEpLg0KPj4gPg0KPj4gPg0KPj4g Pg0KPj4gPiAgICAgICAgICAgICAgICAgUjMzICBUaGUgQ0ROSSBSZXF1ZXN0LVJvdXRpbmcgbG9v cCBwcmV2ZW50aW9uDQo+PiA+IG1lY2hhbmlzbSBTSE9VTEQgYWxsb3cNCj4+ID4NCj4+ID4NCj4+ ID4gICAgICAgICAgICAgICAgICAgICByb3V0aW5nIG9mIHRoZSByZXF1ZXN0IChhcyBvcHBvc2Vk IHRvIHRoZQ0KPj4gPiByZXF1ZXN0IGxvb3AgYmVpbmcNCj4+ID4NCj4+ID4NCj4+ID4gICAgICAg ICAgICAgICAgICAgICBzaW1wbHkgaW50ZXJydXB0ZWQgd2l0aG91dCByb3V0aW5nIHRoZQ0KPj4g PiByZXF1ZXN0KS4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICAgICAgICAgIChhcyB3 ZWxsIGFzIFIzOSBhbmQgUjQwIGZvciBsb25nZXIgdGVybSkNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4gICAgICAgICAgICAgICAgIFI1NSAgSWYgY2FzY2FkZWQgQ0ROcyBhcmUgc3VwcG9ydGVkIGJ5 IHRoZSBDRE5JDQo+PiA+IHNvbHV0aW9uLCB0aGUgQ0ROSQ0KPj4gPg0KPj4gPg0KPj4gPiAgICAg ICAgICAgICAgICAgICAgIE1ldGFkYXRhIEFQSSBNVVNUIHByZXZlbnQgbG9vcGluZyBvZiBDRE5J DQo+PiA+IE1ldGFkYXRhIGRpc3RyaWJ1dGlvbg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAg ICAgICAgICAgIGFjcm9zcyBDRE5zLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAg ICAgICAgRG8geW91IGd1eXMgc3RpbGwgdGhpbmsgc29tZXRoaW5nIGlzIG1pc3Npbmc/DQo+PiA+ DQo+PiA+DQo+PiA+ICAgICAgICAgICAgICAgICBDYW4geW91IHN1Z2dlc3Qgc29tZXRoaW5nIHRv IGNvdmVyIG1pc3NpbmcgYml0cz8NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAg ICAgICAgRm9yIENETkkgUmVxdWVzdCBSb3V0aW5nIHRoZSBhYm92ZSBpcyBmaW5lLiBXaGF0IEkn bQ0KPj4gPiBzYXlpbmcgaXMgSSB0aGluayBsb29wIGRldGVjdGlvbiBhbHNvIGFwcGxpZXMgdG8g dGhlIGNvbnRyb2wgQVBJIGFuZA0KPj5tYXkNCj4+ID4gYmUgdXNlZnVsIGluIHRoZSBvdGhlciBB UElzLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICBJJ2QgdGhlcmVmb3JlIHN1 Z2dlc3QgbWFraW5nIGxvb3AgZGV0ZWN0aW9uIGEgZ2VuZXJhbA0KPj4gPiByZXF1aXJlbWVudCAo U0hPVUxEKSBhbmQgYW55IG1vcmUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIChlLmcuIFIzMykNCj4+ dW5kZXINCj4+ID4gdGhlIHNwZWNpZmljIEFQSSB0aGV5IGFwcGx5IHRvLg0KPj4gPg0KPj4gPg0K Pj4gPg0KPj4gPiAgICAgICAgIEkgdGhpbmsgdGhlIHJlcXVpcmVtZW50IGlzIHN0cm9uZ2VyOiBD RE5zIG5lZWQgdG8gYWdyZWUgb24gYQ0KPj4gPiBjb21tb24gbWVjaGFuaXNtIGZvciBsb29wIGRl dGVjdGlvbjsNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgIEkgYWdyZWUgaXQgaXMgYSBNVVNU IChhcyBhbG9uZyBhcyAiY2FzY2FkZWQgQ0ROcyIgYXJlIHN1cHBvcnRlZCkuDQo+PiA+ICAgICBJ biB0aGUgUmVxdWlyZW1lbnRzIEktRCBpdCB3YXMgcHJlc2VudGVkOg0KPj4gPiAgICAgKiBhcyBh ICJNVVNUIiBmb3IgbG9uZ2VyIHRlcm0NCj4+ID4gICAgICogYXMgYSAiU0hPVUxEIiBmb3Igc2hv cnRlciB0ZXJtLCBiZWNhdXNlIHN1cHBvcnQgb2YgY2FzY2FkZWQgQ0ROcw0KPj4gPiBpdHNlbGYg aXMgb25seSBsaXN0ZWQgYXMgYSBTSE9VTEQgZm9yIHRoZSBzaG9ydGVyIHRlcm0gKG9uIHRoZSBn cm91bmRzDQo+PiA+IHRoYXQgbm90IHN1cHBvcnRpbmcgaXQgbWF5IHBvdGVudGlhbGx5IGFsbG93 IGRlZmluaXRpb24gb2YgYSBzaW1wbGVyDQo+PiA+IHNvbHV0aW9uIGZhc3RlcikNCj4+ID4NCj4+ ID4gICAgIEkgdGhpbmsgd2UgY291bGQgZWl0aGVyOg0KPj4gPg0KPj4gPiAgICAgKkEqOg0KPj4g PiAgICAgKiBhZ3JlZSByaWdodCBub3cgdGhhdCB0aGUgc2hvcnRlciB0ZXJtIHNvbHV0aW9uIChp ZSB3aXRoaW4NCj4+aW5pdGlhbA0KPj4gPiBjaGFydGVyIHNjb3BlKSBNVVNUIHN1cHBvcnQgY2Fz Y2FkZWQgQ0ROcw0KPj4gPiAgICAgKiBpbmNsdWRlIGEgTVVTVCByZXF1aXJlbWVudCBmb3IgbG9v cCBwcmV2ZW50aW9uIGluIHRoZSBHZW5lcmljDQo+PiA+IFJlcXRzIHNlY3Rpb24gYW5kIHBvc3Np Ymx5IGluIGVhY2ggQVBJIHNwZWNpZmljIHNlY3Rpb24gKENvbnRyb2wsDQo+PiBSZXF1ZXN0LQ0K Pj4gPiBSb3V0aW5nLCBNZXRhZGF0YSkNCj4+ID4NCj4+ID4gICAgICpCOg0KPj4gPiAgICAgKiBk ZWZlciB0aGUgZGVjaXNpb24gYWJvdXQgc3VwcG9ydCBvZiBjYXNjYWRlZCBDRE5zIGluIHNob3J0 ZXINCj4+dGVybQ0KPj4gPiAoaWUgd2l0aGluIGluaXRpYWwgY2hhcnRlciBzY29wZSkgdG8gZnVy dGhlciBkaXNjdXNzaW9ucw0KPj4gPiAgICAgKiBpbmNsdWRlIGEgImNvbmRpdGlvbmFsIiBNVVNU IChpZSAiaWYgY2FzY2FkZWQgQ0ROcyBhcmUNCj4+ID4gc3VwcG9ydGVkLC4uLiIpIGluIHRoZSBH ZW5lcmljIFJlcXRzIHNlY3Rpb24gYW5kIHBvc3NpYmx5IGluIGVhY2ggQVBJDQo+PiA+IHNwZWNp ZmljIHNlY3Rpb24gKENvbnRyb2wsIFJlcXVlc3QtUm91dGluZywgTWV0YWRhdGEpDQo+PiA+DQo+ PiA+ICAgICBJIHdvdWxkIHZvdGUgZm9yICpBKiBiZWNhdXNlOg0KPj4gPiAgICAgKiB3ZSB3b3Vs ZG4ndCB3YW50IHRvIGdvIGZvciBhIHNob3J0ZXIgdGVybSBzb2x1dGlvbiB0aGF0IGNhbm5vdA0K Pj5iZQ0KPj4gPiBlYXNpbHkgZXh0ZW5kZWQgdG8gc3VwcG9ydCBjYXNjYWRlZCBDRE5zDQo+PiA+ ICAgICAqIHRoZXJlIGFyZSBzaG9ydCB0ZXJtIHVzZSBjYXNlcyBmb3IgY2FzY2FkZWQgQ0ROcy4N Cj4+ID4NCj4+ID4gICAgIG90aGVyIHZvdGVycz8NCj4+ID4NCj4+ID4gICAgIFRoYW5rcw0KPj4g Pg0KPj4gPiAgICAgRnJhbmNvaXMNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICBvdGhl cndpc2UgeW91IGNhbiBnZXQgbXVsdGlwbGljYXRpdmUgbG9vcCBkaWFtZXRlcnMgYW5kDQo+PiA+ IGVmZmVjdGl2ZWx5IG5vdCBoYXZlIHVzZWZ1bCBsb29wIGRldGVjdGlvbiB3aGVuIHRoZSBub24t bG9vcGluZyBwYXRocw0KPj4gYXJlDQo+PiA+IGxvbmcuIFRoaXMgaXMgcm91dGluZzsgd2Uga25v dyB3aGF0IGhhcHBlbnMgd2hlbiB5b3UgZG8gbG9vcCBkZXRlY3QNCj4+d2l0aA0KPj4gPiB0aGlu ZyBsaWtlIGNvdW50LXRvLWluZmluaXR5Lg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAg IEluY2lkZW50bHksIG15IGZhdm9yaXRlIGxvb3AgZGV0ZWN0aW9uIHNjaGVtZSB3YXMgaW52ZW50 ZWQgYnkNCj4+ID4gS251dGggYWxsIHRoZSB3YXkgYmFjayBpbiB2b2x1bWUgMi4gSXQgaGFzIHRo ZSBuaWNlIHByb3BlcnR5IG9mDQo+PiBkZXRlY3RpbmcNCj4+ID4gbG9vcHMgaW4gY29uc3RhbnQg bWVtb3J5IGFuZCB3aXRoIGFuIHVwcGVyIGJvdW5kIG9mIHRyYXZlcnNpbmcgdGhlDQo+Pmxvb3AN Cj4+IDINCj4+ID4gdGltZXMsIGZvciBhbGwgbG9vcCBkaWFtZXRlcnMuIExvb2sgaXQgdXAgLSBp dCdzIGNhbGxlZCB0aGUgImV2ZW4tb2RkDQo+PiA+IGl0ZXJhdGlvbiBjb3VudGluZyIuDQo+PiA+ DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAgRGF2ZU8uDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ DQo+PiA+ICAgICAgICAgICAgIFRoYW5rcw0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICBC ZW4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4NCj4+ID4NCj4+ID4gICAg ICAgICAgICAgQ0ROaSBtYWlsaW5nIGxpc3QNCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICAgICAg Q0ROaUBpZXRmLm9yZw0KPj4gPg0KPj4gPg0KPj4gPiAgICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+ICAgICBDRE5pIG1haWxpbmcgbGlzdA0KPj4gPiAgICAgQ0ROaUBpZXRmLm9yZw0KPj4gPiAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+PiA+DQo+PiA+ DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+PiA+ IERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4+ID4gQ29ycG9yYXRlIERldmVsb3BtZW50DQo+PiA+ IGZsZWZhdWNoQGNpc2NvLmNvbQ0KPj4gPiBQaG9uZTogKzMzIDQ5IDcyMyAyNjE5DQo+PiA+IE1v YmlsZTogKzMzIDYgMTkgOTggNTAgOTANCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAg IENpc2NvIFN5c3RlbXMgRnJhbmNlDQo+PiA+IEdyZWVuc2lkZQ0KPj4gPiA0MDAgQXZlIGRlIFJv dW1hbmlsbGUNCj4+ID4gMDY0MTAgU29waGlhIEFudGlwb2xpcw0KPj4gPiBGcmFuY2UNCj4+ID4g Q2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2NvLmNvbT4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4N Cj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gIFRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuDQo+PiA+DQo+ PiA+IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUNCj4+c29sZQ0KPj4gPiB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dC4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3INCj4+IGRpc2Nsb3N1cmUNCj4+ID4g Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZA0KPj5yZWNpcGllbnQNCj4+ID4gKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhl IHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZQ0KPj5zZW5kZXINCj4+IGJ5DQo+PiA+IHJl cGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQo+PiA+DQo+ PiA+IENpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGlt aXTDqWUsIFJ1ZSBDYW1pbGxlDQo+PiA+IERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMg Rm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzDQo+PiBNb3VsaW5lYXV4LA0KPj4gPiBB dSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50ZXJyZSwgRGlyZWN0 ZXVyIGRlIGxhDQo+PiA+IHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25lLg0KPj4g Pg0KPj4gPiBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KPj4gPiBodHRw Oi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4 Lmh0bWwNCj4+ID4NCj4+ID4NCj4NCg0K From yiu_lee@cable.comcast.com Mon Feb 14 11:00:53 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AA13A6A15 for ; Mon, 14 Feb 2011 11:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.095 X-Spam-Level: X-Spam-Status: No, score=-101.095 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1D81QMGXD1B for ; Mon, 14 Feb 2011 11:00:52 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 9196F3A6D97 for ; Mon, 14 Feb 2011 11:00:52 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.25781303; Mon, 14 Feb 2011 12:12:30 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 14 Feb 2011 14:01:03 -0500 From: "Lee, Yiu" To: Francois Le Faucheur , David R Oran Thread-Topic: [CDNi] Loop detection requirement Thread-Index: AQHLzHmGRXvg9nmg7EC/kP9N1RgVRg== Date: Mon, 14 Feb 2011 19:01:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "mvittal@cisco.com" Subject: Re: [CDNi] Loop detection requirement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 19:00:53 -0000 Oops. I read Francois's reply after I had sent my reply. I agree what he said. Sorry for flooding the reflector. /Yiu On 2/14/11 4:13 AM, "Francois Le Faucheur" wrote: >Folks, > >On 12 Feb 2011, at 15:43, David R Oran wrote: > >>=20 >> On Feb 11, 2011, at 10:49 AM, wrote: >>=20 >>> .. >>>> [phil] well, in the case with only 2 CDNs interconnected, solving loop >>>> detection is trivial; if there is a chain then it is not clear to me >>>>that >>>> the issues are trivial. >>>=20 >>> IMO the check is identical in both cases: a CDN must check that it is >>>not trying to provide a service that it asked for. >>>=20 >> I don't think it's quite that straightforward semantically - having >>been through the subtleties of spirals in SIP I'm not convinced it's >>easy to ascertain whether you are being asked to provide a service that >>you have outstanding. This is especially tricky if you have a >>distributed implementation of hat looks like a single CDN node to the >>outside world. On the other hand, checking for a request loop is easier >>than checking for a service loop, because the latter is mechanical and >>does not have to "back map" to the semantic level of figuring out what >>the service being requested is/was. >>=20 >>> [phil] if the chain of CDNs is: >>> A - B - C - D - B >>> Detecting the loop is not (i think) as easy as is in the case: >>> A - B - A >>>=20 >> Depends on the algorithm. For most of the algorithms using only local >>state (as opposed to putting state in the messages, like a hop count), >>the complexity of what A has to do in your second example is in fact no >>simpler than what B has to do in your first. For hop count algorithms, >>the diameter of the loop is of course irrelevant. >>=20 >>> Do we defined 'chain' ? >>> [phil] not as far as i know - probably not the best term >> Well, the request pattern could just as easily be a tree or some other >>graph, no? Is there some prohibition against forking requests, or did I >>miss that in the draft? > >The I-D currently states than any topology of interconnected CDNs SHOULD >be supported: >" > 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.). >" > >The I-D currently refers to "cascaded CDNs" as the scenario where a CDN >to which a request is redirected, in turn will redirect the request to >another CDN: >" > R8 The CDNI solution SHOULD support cascaded CDN redirection (CDN1 > redirects to CDN2 that redirects to CDN3) to an arbitrary number > of levels. >" > >The I-D currently refers to the "chain of CDNs" in the context of a given >request. ie for a given request, that request has been routed over a >chain of CDNs (CDN1-->CDN2-->CDN3). Again, this is only relative to a >particular request: >" > R71 The CDNI solution MUST be able to ensure that for any given > request redirected to a Downstream CDN, the chain of CDN > Delegation (leading to that request being served by that CDN) > can be established with non-repudiation. >" > >Focusing on the "Requirements I-D", I propose that, for now, we: > * move the MUST requirement for loop prevention in the generic section > * keep the SHOULD requirements for support of cascaded CDNs (over >arbitrary interconnected CDN topologies) in the generic section > >As potential solutions are discussed and better understood, the group can >make a decision on whether "cascaded CDNs" are supported or not in >initial scope and, given that fact how to perform loop prevention (noting >Dave's point above that depending on how loop prevention is performed, >its complexity may or may not depend on support of cascaded CDNs). > >Additional discussions on potential solutions are welcome, but I'd like >to have a base proposal for the Requirement I-D. > >Francois > > >>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 > > From flefauch@cisco.com Thu Feb 17 07:00:11 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750823A6CE1 for ; Thu, 17 Feb 2011 07:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQWCCX45xcyr for ; Thu, 17 Feb 2011 07:00:10 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1F0893A6E23 for ; Thu, 17 Feb 2011 07:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=1841; q=dns/txt; s=amsiport02001; t=1297954841; x=1299164441; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=UvhZKmTtBdKe1gwwEW4nUHN4o5r21p5ZYTf+jJafs/w=; b=yTUUjeyyPArdI4t6SJUfzcnewDvBiuS3GNC0sIqEAwNka5efySh9WduS OKzkDYdtAekFZMZgB4yoaMbGC3QI3wmSiu8+r+8ncXWS4Bxl2jXxxtSVS K2upk7EJ3tuzVjjrfPqHDeB9Cba8nAdAcXGZhsAEJh47srTQ06V7wSr5I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsFAHPHXE2Q/khLgWdsb2JhbACYDI4MFQEBFiIkoDqbU4J9gmEEjBA X-IronPort-AV: E=Sophos;i="4.60,486,1291593600"; d="scan'208";a="19447750" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Feb 2011 15:00:30 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1HF0UPc001521 for ; Thu, 17 Feb 2011 15:00:30 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 16:00:17 +0100 References: <8E09C72DBC577D489F13A71228C0B7BF021CD313@ftrdmel0.rd.francetelecom.fr> To: cdni@ietf.org Message-Id: <76CC465F-758D-4294-A884-348ABC3654E4@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [CDNi] Fwd: TR: Experiments I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 15:00:11 -0000 This is just a resend of Gilles' message that does not seem to have made = it to the list for some reasons. Cheers Francois >=20 > -----Message d'origine----- > De : BERTRAND Gilles RD-CORE-ISS=20 > Envoy=E9 : mercredi 16 f=E9vrier 2011 11:05 > =C0 : cdni@ietf.org > Objet : Experiments I-D >=20 > Dear all, > =20 > We have posted a new I-D, which describes experiments on CDN = interconnection. It can be found here: > http://www.ietf.org/id/draft-bertrand-cdni-experiments-00.txt. =20 >=20 > Looking forward to your feedback. > -- > Gilles >=20 >=20 > -----Message d'origine----- > De : IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Envoy=E9 = : mercredi 16 f=E9vrier 2011 11:01 =C0 : BERTRAND Gilles RD-CORE-ISS Cc = : flefauch@cisco.com; lpeterson@verivue.com Objet : New Version = Notification for draft-bertrand-cdni-experiments-00=20 >=20 >=20 > A new version of I-D, draft-bertrand-cdni-experiments-00.txt has been = successfully submitted by Gilles Bertrand and posted to the IETF = repository. >=20 > Filename: draft-bertrand-cdni-experiments > Revision: 00 > Title: Content Distribution Network Interconnection = (CDNI) Experiments > Creation_date: 2011-02-16 > WG ID: Independent Submission > Number_of_pages: 20 >=20 > Abstract: > This document reports studies and related experiments on CDN = interconnection performed by France Telecom-Orange Labs. The document = summarizes implications of CDN interconnection to CDN service providers = and lessons learned through CDNI experiments. >=20 > The main purpose of the experiments was to test the interconnection of = CDN solutions from two vendors (namely, Cisco and Verivue) and to = identify the gaps and needs for standardization work for CDN = interconnection. >=20 >=20 >=20 > The IETF Secretariat. From gilles.bertrand@orange-ftgroup.com Thu Feb 17 15:16:45 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1323A6CEC for ; Thu, 17 Feb 2011 15:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwOo35a5VCxY for ; Thu, 17 Feb 2011 15:16:44 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 3DD233A6CC3 for ; Thu, 17 Feb 2011 15:16:41 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 850D28B86D3 for ; Fri, 18 Feb 2011 00:17:26 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id BC5369B1439 for ; Wed, 16 Feb 2011 11:05:53 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 11:05:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 11:05:00 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF021CD306@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experiments I-D Thread-Index: AcvNwPjLD2om+8w/SHmKiUzZoUw7sQ== From: To: X-OriginalArrivalTime: 16 Feb 2011 10:05:01.0795 (UTC) FILETIME=[F9C39330:01CBCDC0] Subject: [CDNi] Experiments I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 23:16:45 -0000 Dear all, =A0 We have posted a new I-D, which describes experiments on CDN = interconnection. It can be found here: http://www.ietf.org/id/draft-bertrand-cdni-experiments-00.txt. =A0 Looking forward to your feedback. -- Gilles -----Message d'origine----- De : IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Envoy=E9 : mercredi 16 f=E9vrier 2011 11:01 =C0 : BERTRAND Gilles RD-CORE-ISS Cc : flefauch@cisco.com; lpeterson@verivue.com Objet : New Version Notification for draft-bertrand-cdni-experiments-00=20 A new version of I-D, draft-bertrand-cdni-experiments-00.txt has been = successfully submitted by Gilles Bertrand and posted to the IETF = repository. Filename: draft-bertrand-cdni-experiments Revision: 00 Title: Content Distribution Network Interconnection (CDNI) Experiments Creation_date: 2011-02-16 WG ID: Independent Submission Number_of_pages: 20 Abstract: This document reports studies and related experiments on CDN = interconnection performed by France Telecom-Orange Labs. The document = summarizes implications of CDN interconnection to CDN service providers = and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of = CDN solutions from two vendors (namely, Cisco and Verivue) and to = identify the gaps and needs for standardization work for CDN = interconnection. = =20 The IETF Secretariat. From gilles.bertrand@orange-ftgroup.com Thu Feb 17 16:14:23 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D563A6F73 for ; Thu, 17 Feb 2011 16:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al+xMsZumUym for ; Thu, 17 Feb 2011 16:14:22 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 82FA63A6F72 for ; Thu, 17 Feb 2011 16:14:21 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9B7CF8B8D82 for ; Fri, 18 Feb 2011 01:14:58 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 35D578B97E2 for ; Thu, 17 Feb 2011 10:09:14 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 10:07:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 10:07:08 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF021CD71D@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experiments I-D Thread-Index: AcvNwPjLD2om+8w/SHmKiUzZoUw7sQ== From: To: X-OriginalArrivalTime: 17 Feb 2011 09:07:10.0607 (UTC) FILETIME=[0F3011F0:01CBCE82] Subject: [CDNi] Experiments I-D X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:14:23 -0000 Dear all, =A0 We have posted a new I-D, which describes experiments on CDN = interconnection. It can be found here: http://www.ietf.org/id/draft-bertrand-cdni-experiments-00.txt. =A0 Looking forward to your feedback. -- Gilles -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : mercredi 16 f=E9vrier 2011 11:15 =C0 = : i-d-announce@ietf.org Objet : I-D = Action:draft-bertrand-cdni-experiments-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Content Distribution Network Interconnection (CDNI) = Experiments Author(s) : G. Bertrand, et al. Filename : draft-bertrand-cdni-experiments-00.txt Pages : 20 Date : 2011-02-16 This document reports studies and related experiments on CDN = interconnection performed by France Telecom-Orange Labs. The document = summarizes implications of CDN interconnection to CDN service providers = and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of = CDN solutions from two vendors (namely, Cisco and Verivue) and to = identify the gaps and needs for standardization work for CDN = interconnection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-experiments-00.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@niven-jenkins.co.uk Tue Feb 22 00:46:56 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316D23A63D2 for ; Tue, 22 Feb 2011 00:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32wfk3yqtXhp for ; Tue, 22 Feb 2011 00:46:55 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 15F443A63CA for ; Tue, 22 Feb 2011 00:46:54 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-144-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PrnuD-0004xF-68; Tue, 22 Feb 2011 08:47:37 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <3FF73AB3-B934-424B-ABCC-2B25048DE0FC@niven-jenkins.co.uk> Date: Tue, 22 Feb 2011 08:47:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4CF48D86-237B-4EE7-96FC-7AFA52638A0E@niven-jenkins.co.uk> References: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> <3FF73AB3-B934-424B-ABCC-2B25048DE0FC@niven-jenkins.co.uk> To: "philip.eardley@bt.com>" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: [CDNi] Dynamic Vs Pre-positioned acquisition of content X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:46:56 -0000 Philip, Colleagues, A couple of weeks ago, I promised to try to come up with some = definitions for dynamic & pre-positioned acquisition of content. I = apologise for my belated follow-up. I propose we add the following definitions to the CDNI Problem Statement = draft. I have tried to keep the definitions solution neutral and = therefore avoided mention of "pulling" Vs "pushing" content between = CDNs. Comments, improvements, etc are welcomed as always. Dynamic content acquisition: Dynamic content acquisition is where a CDN = only acquires content from the content source in response to an End User = requesting that content from the CDN. In the context of CDN = Interconnect, dynamic acquisition means that a downstream CDN does not = acquire any content from content sources (including upstream CDNs) until = a content request for that content has been delegated to the downstream = CDN by an Upstream CDN. Pre-Positioned content acquisition: Pre-positioning is where a CDN = acquires content from the content source prior to any End User = requesting that content from the CDN. Additionally, in some cases, = additional metadata may be provided to instruct the CDN how to treat the = content (for example time windows describing when the content may be = made available to end users, etc.). In the context of CDN interconnect = the Upstream CDN instructs the Downstream CDN to acquire the content = along with any associated pre-positioning metadata from content sources = (including upstream CDNs) in advance of any End User requesting it. Thanks Ben On 7 Feb 2011, at 10:56, Ben Niven-Jenkins wrote: > On 3 Feb 2011, at 14:58, = wrote: >> 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. >=20 > I will try and come up with some proposed text this week (based on = some of the text that was in your e-mail) which I will share on the list = and if we can form a consensus around it we can include it in the next = revision of the problem statement. From flefauch@cisco.com Tue Feb 22 01:52:54 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5193A6774 for ; Tue, 22 Feb 2011 01:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.964 X-Spam-Level: X-Spam-Status: No, score=-9.964 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgcjSk08md9f for ; Tue, 22 Feb 2011 01:52:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 196B23A683D for ; Tue, 22 Feb 2011 01:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=9954; q=dns/txt; s=iport; t=1298368415; x=1299578015; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=mXp2zvgQ1xjdiMjGgr3z4sM5Maz0/XzBXk/VcBK6wGI=; b=OCGyLGNOplu0qWdADt9IUV7rtHPktrC7TNLrADHSM18UIgFFRGBuyLj7 w/PbJoc18E/GN5QDnM6CzuURLLThCsOUKrGRWE5wJbqjHnycLsXr96+Ub TSbu9dgICOqaekfVtvw9/r2nCKoKzi/Fhcm1mKrzIX+V+kYpfmpIx10sk U=; X-IronPort-AV: E=Sophos;i="4.62,206,1297036800"; d="scan'208,217";a="19773482" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2011 09:53:34 +0000 Received: from [144.254.53.124] ([144.254.53.124]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1M9rXXh004551; Tue, 22 Feb 2011 09:53:33 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1118-86148499 From: Francois Le Faucheur In-Reply-To: <4CF48D86-237B-4EE7-96FC-7AFA52638A0E@niven-jenkins.co.uk> Date: Tue, 22 Feb 2011 10:53:31 +0100 Message-Id: References: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> <3FF73AB3-B934-424B-ABCC-2B25048DE0FC@niven-jenkins.co.uk> <4CF48D86-237B-4EE7-96FC-7AFA52638A0E@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 09:52:54 -0000 --Apple-Mail-1118-86148499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ben and all, On 22 Feb 2011, at 09:47, Ben Niven-Jenkins wrote: > Philip, Colleagues, >=20 > A couple of weeks ago, I promised to try to come up with some = definitions for dynamic & pre-positioned acquisition of content. I = apologise for my belated follow-up. >=20 > I propose we add the following definitions to the CDNI Problem = Statement draft. I have tried to keep the definitions solution neutral = and therefore avoided mention of "pulling" Vs "pushing" content between = CDNs. >=20 > Comments, improvements, etc are welcomed as always. >=20 > Dynamic content acquisition: Dynamic content acquisition is where a = CDN only acquires content from the content source in response to an End = User requesting that content from the CDN. In the context of CDN = Interconnect, dynamic acquisition means that a downstream CDN does not = acquire any content from content sources (including upstream CDNs) until = a content request for that content has been delegated to the downstream = CDN by an Upstream CDN. >=20 > Pre-Positioned content acquisition: Pre-positioning is where a CDN = acquires content from the content source prior to any End User = requesting that content from the CDN. Additionally, in some cases, = additional metadata may be provided to instruct the CDN how to treat the = content (for example time windows describing when the content may be = made available to end users, etc.). In the context of CDN interconnect = the Upstream CDN instructs the Downstream CDN to acquire the content = along with any associated pre-positioning metadata from content sources = (including upstream CDNs) in advance of any End User requesting it. 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 content from the content source in response to an End User = requesting that content from the CDN. In the context of CDN = Interconnect, dynamic acquisition means that a downstream CDN does not = acquire any content from content sources (including upstream CDNs) until = a content request for that content has been delegated to the downstream = CDN by an Upstream CDN. Pre-Positioned content acquisition: Content Pre-positioning is where a = CDN acquires content from the content source prior to 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 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 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 prior to = any End User requesting that content from the Downstream CDN.=20 " Cheers Francois PS: If we agree on something like the above, we could also include text = discussing possible combinations. >=20 > Thanks > Ben >=20 >=20 >=20 > On 7 Feb 2011, at 10:56, Ben Niven-Jenkins wrote: >> On 3 Feb 2011, at 14:58, = wrote: >>> 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. >>=20 >> I will try and come up with some proposed text this week (based on = some of the text that was in your e-mail) which I will share on the list = and if we can form a consensus around it we can include it in the next = revision of the problem statement. >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-1118-86148499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ben = and all,

On 22 Feb 2011, at 09:47, Ben Niven-Jenkins = wrote:

Philip, Colleagues,

A couple of weeks ago, I = promised to try to come up with some definitions for dynamic & = pre-positioned acquisition of content. I apologise for my belated = follow-up.

I propose we add the following definitions to the CDNI = Problem Statement draft. I have tried to keep the definitions solution = neutral and therefore avoided mention of "pulling" Vs "pushing" content = between CDNs.

Comments, improvements, etc are welcomed as = always.

Dynamic content acquisition: Dynamic content acquisition = is where a CDN only acquires content from the content source in response = to an End User requesting that content from the CDN. In the context of = CDN Interconnect, dynamic acquisition means that a downstream CDN does = not acquire any content from content sources (including upstream CDNs) = until a content request for that content has been delegated to the = downstream CDN by an Upstream CDN.

Pre-Positioned content = acquisition: Pre-positioning is where a CDN acquires content from the = content source prior to any End User requesting that content from the = CDN. Additionally, in some cases, additional metadata may be provided to = instruct the CDN how to treat the content (for example time windows = describing when the content may be made available to end users, etc.). = In the context of CDN interconnect the Upstream CDN instructs the = Downstream CDN to acquire the content along with any associated = pre-positioning metadata from content sources (including upstream CDNs) = in advance of any End User requesting = it.

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 content from = the content source in response to an End User requesting that content = from the CDN. In the context of CDN Interconnect, dynamic acquisition = means that a downstream CDN does not acquire any content from content = sources (including upstream CDNs) until a content request for that = content has been delegated to the downstream CDN by an Upstream = CDN.

Pre-Positioned content acquisition: Content Pre-positioning = is where a CDN acquires content from the content source prior to 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 = 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 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 prior to 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.



Thanks
Ben



On 7 Feb 2011, at = 10:56, Ben Niven-Jenkins wrote:
On 3 Feb = 2011, at 14:58, <philip.eardley@bt.com> = <philip.eardley@bt.com>= wrote:
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.

I will try and = come up with some proposed text this week (based on some of the text = that was in your e-mail) which I will share on the list and if we can = form a consensus around it we can include it in the next revision of the = problem = statement.


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

To: Francois Le Faucheur , Ben Niven-Jenkins Thread-Topic: [CDNi] Dynamic Vs Pre-positioned acquisition of content Thread-Index: AQHL0p063V2MsejZBkqbSWegIt/fyA== Date: Tue, 22 Feb 2011 14:31:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_C98932508F2Dyiuleecablecomcastcom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:31:11 -0000 --_000_C98932508F2Dyiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben and Francois, Thanks for working on the definitions. I like them. Yiu From: Francois Le Faucheur > Date: Tue, 22 Feb 2011 10:53:31 +0100 To: Ben Niven-Jenkins > Cc: > Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content Ben and all, On 22 Feb 2011, at 09:47, Ben Niven-Jenkins wrote: Philip, Colleagues, A couple of weeks ago, I promised to try to come up with some definitions f= or dynamic & pre-positioned acquisition of content. I apologise for my bela= ted follow-up. I propose we add the following definitions to the CDNI Problem Statement dr= aft. I have tried to keep the definitions solution neutral and therefore av= oided mention of "pulling" Vs "pushing" content between CDNs. Comments, improvements, etc are welcomed as always. Dynamic content acquisition: Dynamic content acquisition is where a CDN onl= y acquires content from the content source in response to an End User reque= sting that content from the CDN. In the context of CDN Interconnect, dynami= c acquisition means that a downstream CDN does not acquire any content from= content sources (including upstream CDNs) until a content request for that= content has been delegated to the downstream CDN by an Upstream CDN. Pre-Positioned content acquisition: Pre-positioning is where a CDN acquires= content from the content source prior to any End User requesting that cont= ent from the CDN. Additionally, in some cases, additional metadata may be p= rovided to instruct the CDN how to treat the content (for example time wind= ows describing when the content may be made available to end users, etc.). = In the context of CDN interconnect the Upstream CDN instructs the Downstrea= m CDN to acquire the content along with any associated pre-positioning meta= data from content sources (including upstream CDNs) in advance of any End U= ser requesting it. In line with Phil's initial comment, I'd suggest we try separate handling o= f content and handling of metadata. How about something like: " Dynamic content acquisition: Dynamic content acquisition is where a CDN onl= y acquires content from the content source in response to an End User reque= sting that content from the CDN. In the context of CDN Interconnect, dynami= c acquisition means that a downstream CDN does not acquire any content from= content sources (including upstream CDNs) until a content request for that= content has been delegated to the downstream CDN by an Upstream CDN. Pre-Positioned content acquisition: Content Pre-positioning is where a CDN = acquires content from the content source prior to any End User requesting t= hat content from the CDN. In the context of CDN interconnect the Upstream C= DN instructs the Downstream CDN to acquire the content from content sources= (including upstream CDNs) in advance of any End User requesting it. Dynamic CDNI metadata acquisition: In the context of CDN Interconnect, dyna= mic CDNI metadata acquisition means that a downstream CDN does not acquire = CDNI metadata from the upstream CDN until a content request for that conten= t has been delegated to the downstream CDN by an Upstream CDN. Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnec= t, Metadata Pre-positioning is where the Upstream CDN instructs the Downstr= eam CDN to acquire distribution metadata prior to any End User requesting t= hat content from the Downstream CDN. " Cheers Francois PS: If we agree on something like the above, we could also include text dis= cussing possible combinations. Thanks Ben On 7 Feb 2011, at 10:56, Ben Niven-Jenkins wrote: On 3 Feb 2011, at 14:58, > > wrote: It would be worth having a definition of dynamic acquisition & pre-position= ing (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. I will try and come up with some proposed text this week (based on some of = the text that was in your e-mail) which I will share on the list and if we = can form a consensus around it we can include it in the next revision of th= e problem statement. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf= .org https://www.ietf.org/mailman/listinfo/cdni --_000_C98932508F2Dyiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0A51400E0189D946A1417C71506A9CE8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi Ben and Francois,

Thanks for working on the definitions. I like them. 

Yiu

From: Francois Le Faucheur <flefauch@cisco.com>
Date: Tue, 22 Feb 2011 10:53:31 = 3;0100
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Cc: <cdni@ietf.org>
Subject: Re: [CDNi] Dynamic Vs Pre-= positioned acquisition of content

Ben and all,

On 22 Feb 2011, at 09:47, Ben Niven-Jenkins wrote:

Philip, Colleagues,

A couple of weeks ago, I promised to try to come up with some definitions f= or dynamic & pre-positioned acquisition of content. I apologise for my = belated follow-up.

I propose we add the following definitions to the CDNI Problem Statement dr= aft. I have tried to keep the definitions solution neutral and therefore av= oided mention of "pulling" Vs "pushing" content between= CDNs.

Comments, improvements, etc are welcomed as always.

Dynamic content acquisition: Dynamic content acquisition is where a CDN onl= y acquires content from the content source in response to an End User reque= sting that content from the CDN. In the context of CDN Interconnect, dynami= c acquisition means that a downstream CDN does not acquire any content from content sources (including upstream = CDNs) until a content request for that content has been delegated to the do= wnstream CDN by an Upstream CDN.

Pre-Positioned content acquisition: Pre-positioning is where a CDN acquires= content from the content source prior to any End User requesting that cont= ent from the CDN. Additionally, in some cases, additional metadata may be p= rovided to instruct the CDN how to treat the content (for example time windows describing when the content= may be made available to end users, etc.). In the context of CDN interconn= ect the Upstream CDN instructs the Downstream CDN to acquire the content al= ong with any associated pre-positioning metadata from content sources (including upstream CDNs) in advance of any = End User requesting it.

In line with Phil's initial comment, I'd suggest we try separate handl= ing of content and handling of metadata. How about something like:

"
Dynamic content acquisition: Dynamic content acquisition is where a CD= N only acquires content from the content source in response to an End User = requesting that content from the CDN. In the context of CDN Interconnect, d= ynamic acquisition means that a downstream CDN does not acquire any content from content sources (includin= g upstream CDNs) until a content request for that content has been delegate= d to the downstream CDN by an Upstream CDN.

Pre-Positioned content acquisition: Content Pre-positioning is where a CDN = acquires content from the content source prior to any End User requesting t= hat content from the CDN. In the context of CDN interconnect the Upstr= eam CDN instructs the Downstream CDN to acquire the content from content sources (including upstream CDNs) in a= dvance of any End User requesting it.

Dynamic CDNI metadata acquisition: In the context of CDN Intercon= nect, dynamic CDNI metadata acquisition means that a downstream CDN does no= t acquire CDNI metadata from the upstream CDN until a content request for t= hat content has been delegated to the downstream CDN by an Upstream CDN.

Pre-positioned CDNI Metadata acquisition: In the context of CDN I= nterconnect, Metadata Pre-positioning is where the Upstream CDN i= nstructs the Downstream CDN to acquire distribution metadata prior to = 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 tex= t discussing possible combinations.



Thanks
Ben



On 7 Feb 2011, at 10:56, Ben Niven-Jenkins wrote:
On 3 Feb 2011, at 14:58, <philip.eardley@bt.com> <philip.eardley@bt.com> wrote:
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 a= lso to metadata. As you could push the CDNI Metadata and then pull the content later.

I will try and come up with some proposed text th= is week (based on some of the text that was in your e-mail) which I will sh= are on the list and if we can form a consensus around it we can include it = in the next revision of the problem statement.


_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni


_______________________________________________ CDNi mailing list CDNi@ietf.org ht= tps://www.ietf.org/mailman/listinfo/cdni --_000_C98932508F2Dyiuleecablecomcastcom_-- From meadorg@cisco.com Mon Feb 28 11:24:25 2011 Return-Path: X-Original-To: cdni@core3.amsl.com Delivered-To: cdni@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F593A6A1D for ; Mon, 28 Feb 2011 11:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70PWL6p3kcAf for ; Mon, 28 Feb 2011 11:24:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 80DF83A6A0F for ; Mon, 28 Feb 2011 11:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=meadorg@cisco.com; l=5889; q=dns/txt; s=iport; t=1298921124; x=1300130724; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=tLUUbdalWyPIth0iGZMhuYVzbxLoT6MoxOt3qTJurS8=; b=iVByA0vasrH1tOhL4PL8L0lfFqrh0pLFaZq+DZge9kZJ6zhrQvBhAQRY 2Tp4KDF7SgqIbxUwTJqTH/4xGjG2B8PD71PL/8fYs2QFbQ7BlquiComP5 N3h3WH09V9Id4FF29oQOGzO3Q+pkL+LP3IqpRMm2wwL/QIWfHNys6qgMB s=; X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208,217";a="221178703" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2011 19:25:24 +0000 Received: from [192.168.1.111] (rtp-vpn3-585.cisco.com [10.82.218.76]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SJPO04019499; Mon, 28 Feb 2011 19:25:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-638860447 From: Guy Meador In-Reply-To: Date: Mon, 28 Feb 2011 14:25:23 -0500 Message-Id: References: <9510D26531EF184D9017DF24659BB87F327828C214@EMV65-UKRD.domain1.systemhost.net> <3FF73AB3-B934-424B-ABCC-2B25048DE0FC@niven-jenkins.co.uk> <4CF48D86-237B-4EE7-96FC-7AFA52638A0E@niven-jenkins.co.uk> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1082) Cc: cdni@ietf.org Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 19:24:25 -0000 --Apple-Mail-4-638860447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > In line with Phil's initial comment, I'd suggest we try separate = handling of content and handling of metadata. How about something like: >=20 > " > 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 > " >=20 > Cheers >=20 > Francois >=20 > PS: If we agree on something like the above, we could also include = text discussing possible combinations. >=20 --Apple-Mail-4-638860447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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.

= --Apple-Mail-4-638860447--