From nobody Sun Apr 15 06:19:00 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB101200C5 for ; Sun, 15 Apr 2018 06:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qwilt-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMCDG0VmtwBO for ; Sun, 15 Apr 2018 06:18:56 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA25C1200A0 for ; Sun, 15 Apr 2018 06:18:55 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v24so1826627wra.8 for ; Sun, 15 Apr 2018 06:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=is6tGTWfysMt9p6SDCIDdXNnpseaqn5IodV86jnYjAs=; b=Zq4pzXPouPBKTFAYVk4hhFAwhmMtNNqc5nuWDYywcLuA6sTZEI8imsHfoTdCZURpNj REsFuqR6vJAMye7Ucl+opwpJR+n0fGCVjtiudD44792Hssoux9OkTbVFoQMND8Wj8s4u lwlc9NN1VtcQGKa6lp0fERI58s0gwTFgLDtlv9Dfuv9nY9iSLF6w0IJ+enwo/e/Rs9un 5BoIwQevC0YS8TDYCX9+jLPWY8r2X6nc/DT2mx7YZ96u4Fb/I5+cnQSHkgEta4xn+t9Z /IhfDr5pkOVIzSrpa69fV6vzwlY2rBaKtXlcMUZIrZcrjtbHgfXldVdzxNubvUY2Wn2E o5hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=is6tGTWfysMt9p6SDCIDdXNnpseaqn5IodV86jnYjAs=; b=n/5hV/PvU/DVGYWeqLgNiTdWEa8IBqzWBxsRHsDpRYnY9JG+XJ4VAKXMDBVSVaa2Vm 5Q4A+d9PQlji4/AmhL/s3NVbrvH4jPzEjyIahIRR8R6hjJRYUO7diXU66PmTWAICaMWv rS7T7mRvlxQJOBXWQ8Z6r8GzgOR0jXB55iO9+Cir71G1+B5UCT/xZnjzxN8WrQAjzjOk xTXgCxHrpJrEeT9C/ZYSF2D3JkEwRAUAfwYIQwasw3XaHLN7WogGNoiSpGD+aCey9UFS ckJyF4bB46294XZGz0zub9XIjJk+Y5Uucwhuz+KNe7fmXHWBSQG89utSpP5BK4CoHyhO Sjzg== X-Gm-Message-State: ALQs6tCnYB6DFKxdROxLHjf17hEKnal97ZRfRExriyshfAc648hNPf+i a0WH3IP6Ozbj58L0+JGxzTr/4MoQfPxXN5jmOH7X1xEGKqs= X-Google-Smtp-Source: AIpwx4+Zy6h48ais8I5itCRQ1J2z4hnko5yjeuycYpi8tsycTeC9JvjRlhOnucxmFsMZGjkNmP+h5zlMecxatvbOxHU= X-Received: by 10.223.131.70 with SMTP id 64mr5945098wrd.151.1523798334031; Sun, 15 Apr 2018 06:18:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.3.193 with HTTP; Sun, 15 Apr 2018 06:18:22 -0700 (PDT) In-Reply-To: References: <151844583990.6130.2280764624601101619.idtracker@ietfa.amsl.com> <234C8324-98A2-4916-93CB-D21A946A6A2B@niven-jenkins.co.uk> From: Ori Finkelman Date: Sun, 15 Apr 2018 16:18:22 +0300 Message-ID: To: Ben Niven-Jenkins Cc: "" Content-Type: multipart/alternative; boundary="94eb2c0d247668e3500569e2f2c9" Archived-At: Subject: Re: [CDNi] New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 13:18:59 -0000 --94eb2c0d247668e3500569e2f2c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Here is my proposal for the fixed redirect target object. Comments are within the JSON object for clarity. A few points for discussion below the object. { "capabilities": [ { "capability-type": "FCI.RedirectTarget", "capability-value": { "ucdn-hosts": [ endpoints ], # a list of uCDN hosts that this redirect target applies to # a ucdn-host is a host which is mapped to a specific metadata HostMatch object # the ucdn-hosts is optional. The default is this target for redirect of all services of the uCDN "dns-target": { "host" :"" # a host name, used for CNAME redirect from uCDN to dCDN # I have allowed a single host here rather than an array as I don't see the case of allowing the uCDN to choose to which dCDN target to redirect the traffic. Load balancing should be done within the dCDN by other means. }, # the dns-target is optional, but either dns-target or http-target MUST be present and non-empty "http-target": { "host" : "", # a hostname use for the HTTP redirect from uCDN to dCDN. Mandatory # I have allowed a single host here rather than an array as I don't see the case of allowing the uCDN to choose to which dCDN target to redirect the traffic. Load balancing should be done within the dCDN by other means. "path-prefix": "" # path prefix for the HTTP redirect. the original path is appended after this prefix. # optional. the default is for the uCDN to prepend the uCDN host, as it appears in the HostMatch metadata object, as the first path segment. } }, # the http-target is optional, but either dns-target or http-target MUST be present and non-empty "footprints": [ ] } ] } *Discussion points* 1. Single or multiple targets - we have tried to find a use case in which it is beneficial for the uCDN to be aware of multiple targets for a given footprint, and I couldn't find such. Therefore I have enabled a single target rather than an array. Would be good to get feedback about this. 2. I am using the endpoint object which is defined in https://tools.ietf.org/html/rfc8006#section-4.3.3 however, this allows using a dotted IP notation, which is not relevant in most of the cases, for example it can't be used for CNAME delegation. Still I don't think this calls for definition of a new object that will allow only FQDN ? thoughts ? 3. We need clear definition of how to use the path-prefix. Here is an initial proposal + If path-prefix is not present, the uCDN should set it's own hostname, as appears int he ucdn-hosts field, and the respective metadata HostMatch object, as the fast path segment. + If path-prefix is present and not empty, the uCDN should use ONLY this path prefix. + If path-prefix is present but empty, the uCDN should not prepend any prefix and use it's own content path as is. Thanks, Ori On Mon, Mar 26, 2018 at 12:12 PM, Ori Finkelman wrote: > Hi Ben, all, > Took me some time to get back to this. > > A few questions regarding your proposal. > > > Your proposal splits between dns-targets and http-targets, which make > sense. > However this makes me think that we should be more flexible and instead o= f > using the method name prepended to the "-target" we could have a separate > field indicating which type of redirection mode it applies to, choosing > from redirection modes available in https://tools.ietf.org/html > /rfc8008#section-6.2 ) (i.e DNS-I, DNS-R, HTTP-I, HTTP-R etc.) > > > The object you have defined relates the to the dns targets, > but not to the http-targets. Wouldn't it be more flexible to allow this > also for the http-targets, and by that enabling different dCDN host names > for different services also in HTTP redirect ? > I am not quite sure about this, as the mapping for services in HTTP > redirection is supposed to work by putting the uCDN host name as the firs= t > path segment in the dCDN path, as proposed in https://tools.ietf.org/ > html/rfc7336#section-3.2 > However, maybe there are use cases in which it would be beneficial to set > the dCDN target address per the uCDN host name ? I am looking for feedbac= k > / ideas about this. > > > As for the uri-prefixes, I think that is a good idea. Did you meant the > uri-prefixes for http-targets should include the endpoints with them (e.g= . > http:///) as you have removed the endpoints fields ? > > > Thanks, > Ori > > > > > > > > On Tue, Mar 6, 2018 at 5:31 PM, Ben Niven-Jenkins > wrote: > >> Hi Ori & Sanjay >> >> I read your draft and I am not sure the objects you define contain >> sufficient information for the Footprint & Capabilities use case you hav= e. >> >> My understanding is that you want a dCDN to advertise its request router >> address(es) by geography. >> >> The FCI object you define does not provide a mapping between the FQDN th= e >> client is requesting and the name/URI the dCDN would like that FQDN to b= e >> redirected to. >> >> With DNS redirection the uCDN needs to know what CNAME to return to the >> client=E2=80=99s DNS resolver and the dCDN=E2=80=99s request router need= s to use a >> different CNAME per =E2=80=9CCDN service=E2=80=9D so it can look up the = appropriate >> metadata for that =E2=80=9CCDN service=E2=80=9D. >> >> With HTTP redirection, what you have works if you assume a static mappin= g >> between the URI the client requests from the uCDN and the redirection UR= I >> in the dCDN, although I wonder if having the dCDN advertise a URI prefix >> explicitly might be better to provide the dCDN some choice in what mappi= ng >> it uses. >> >> Therefore I think you need to change your object from: >> >> "target-addresses": [ { =E2=80=9Cendpoints": [] } ] >> >> to something that also includes the host/FQDN the client will use in its >> request to the uCDN, e.g.: >> >> =E2=80=9Chosts": { =E2=80=9C=E2=80=9D: { "dns-targets": [ { = =E2=80=9Cendpoints=E2=80=9D: [] } ] }, >> =E2=80=9Chttp-targets": [ { =E2=80=9Curi-prefixes=E2=80=9D: [] } } >> >> Regards >> Ben >> >> >> >> On 12 Feb 2018, at 14:32, Ori Finkelman wrote: >> >> Dear Colleagues, >> Please see the new draft for the SVA request routing extensions. >> >> Best regards, >> Ori >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Feb 12, 2018 at 4:30 PM >> Subject: New Version Notification for draft-finkelman-cdni-rr-sva-ex >> tensions-00.txt >> To: Sanjay Mishra , Ori Finkelman < >> orif@qwilt.com> >> >> >> >> A new version of I-D, draft-finkelman-cdni-rr-sva-extensions-00.txt >> has been successfully submitted by Ori Finkelman and posted to the >> IETF repository. >> >> Name: draft-finkelman-cdni-rr-sva-extensions >> Revision: 00 >> Title: CDNI SVA Request Routing Extensions >> Document date: 2018-02-12 >> Group: Individual Submission >> Pages: 9 >> URL: https://www.ietf.org/internet- >> drafts/draft-finkelman-cdni-rr-sva-extensions-00.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-finkelman-cdni-rr-sva-extensions/ >> Htmlized: https://tools.ietf.org/html/d >> raft-finkelman-cdni-rr-sva-extensions-00 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-finkelman-cdni-rr-sva-extensions-00 >> >> >> Abstract: >> The Open Caching working group of the Streaming Video Alliance is >> focused on the delegation of video delivery requests from commercial >> CDNs to a caching layer at the ISP. In that aspect, Open Caching is >> a specific use case of CDNI, where the commercial CDN is the upstream >> CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >> +972-52-3832189 <052-383-2189> | orif@qwilt.com >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> >> >> > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | > orif@qwilt.com > --=20 *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --94eb2c0d247668e3500569e2f2c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Here is my proposal for the fixed redirect target = object.
Comments are within the JSON object for clarity.
A few points for discussion below the object.

= =C2=A0{
=C2=A0 =C2=A0 =C2=A0"capabilities": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;capability-type": "FCI.RedirectTarget= ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"capability-valu= e": {
=C2=A0 =C2=A0= =C2=A0"ucdn-hosts": [ endpoints ],
=
# a list of uCDN hosts that this=C2=A0redirect=C2=A0target=C2=A0applies to=
# a ucdn-host is a host which is mapped to a = specific metadata HostMatch object=C2=A0
# the ucdn-hosts is optional. The default is this=C2=A0target=C2=A0for=C2=A0<= span class=3D"gmail-il">redirect=C2=A0of all services o= f the uCDN

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"dns-target": {=C2=A0
=
= =C2=A0 =C2=A0 =C2=A0"ho= st" :"<endpoint>"
# a hos= t name, used for CNAME=C2=A0redirect<= /span>=C2=A0from uCDN to dCDN
# I have allowed a single host here rather than an array as I don't= see the case of allowing the uCDN to choose to which dCDN=C2=A0target=C2=A0to=C2=A0redirect=C2=A0the traffic= . Load balancing should be done within the dCDN by other means.
=C2=A0 =C2=A0 =C2=A0},
=
= # the dns-target=C2=A0is optional, but either dns-target= =C2=A0or http-target=C2=A0MUST be present and non-empty
=C2=A0"http-target": {
= =C2=A0 =C2=A0 =C2=A0"host" : "<endpoint>&quo= t;,
# a hostname use for the HTTP=C2=A0<= /span>redirect=C2=A0from uCDN = to dCDN. Mandatory
# I have allowed a single host here rather than an array as I don'= t see the case of allowing the uCDN to choose to which dCDN=C2=A0target=C2=A0to=C2=A0<= /span>redirect=C2=A0the traffi= c. Load balancing should be done within the dCDN by other means.=C2=A0
=C2=A0 =C2=A0 =C2=A0"path-prefix": "<path>"
# path prefix for the HTTP=C2=A0redirect. the original path is appended after= this prefix.=C2=A0
# optional. the def= ault is for the uCDN to prepend the uCDN host, as it appears in the HostMat= ch metadata object, as the first path segment.
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0},
# the http-target=C2=A0is optional, but either dns-target=C2=A0or http-target=C2=A0MUST be present and non-empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"footprints": [
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial">= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Footprint objects>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2= =A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 }


Discussion points
1. = Single or multiple targets - we have tried to find a use case in which it i= s beneficial for the uCDN to be aware of multiple targets for a given footp= rint, and I couldn't find such. Therefore I have enabled a single targe= t rather than an array. Would be good to get feedback about this.

2. I am using the endpoint object which is defined in=C2=A0= https://tools= .ietf.org/html/rfc8006#section-4.3.3 however, this allows using a dotte= d IP notation, which is not relevant in most of the cases, for example it c= an't be used for CNAME delegation. Still I don't think this calls f= or definition of a new object that will allow only FQDN ? thoughts ?
<= div>
3. We need clear definition of how to use the path-prefi= x. Here is an initial proposal
+ If path-prefix is not present, t= he uCDN should set it's own hostname, as appears int he ucdn-hosts fiel= d, and the respective metadata HostMatch object, as the fast path segment.<= /div>
+ If path-prefix is present and not empty, the uCDN should use ON= LY this path prefix.
+ If path-prefix is present but empty, the u= CDN should not prepend any prefix and use it's own content path as is.<= /div>



Thanks,
Or= i


On Mon, Mar 26, 2018 at 12:12 PM, Ori Finkelman <ori= f@qwilt.com> wrote:
Hi Ben, all,
Took me some time to get back to this.

A few questions regarding your proposal.


Your proposal splits between dns-targets and http-tar= gets, which make sense.
However this makes me think that we shoul= d be more flexible and instead of using the method name prepended to the &q= uot;-target" we could have a separate field indicating which type of r= edirection mode it applies to, choosing from redirection modes=C2=A0 availa= ble in=C2=A0https://tools.ietf.org/html/rfc8008#section-6.2=C2= =A0) (i.e DNS-I, DNS-R, HTTP-I, HTTP-R etc.)


<= /div>
The object you have defined relates the <host/FQDN> to the = dns targets, but not to the http-targets. Wouldn't it be more flexible = to allow this also for the http-targets, and by that enabling different dCD= N host names for different services also in HTTP redirect ?=C2=A0
I am not quite sure about this, as the mapping for services in HTTP redire= ction is supposed to work by putting the uCDN host name as the first path s= egment in the dCDN path, as proposed in=C2=A0https://tools.ietf.org/html/rfc7336#section-3.2=C2=A0
However, maybe there are use = cases in which it would be beneficial to set the dCDN target address per th= e uCDN host name ? I am looking for feedback / ideas about this.
=

As for the uri-prefixes, I think that is a go= od idea. Did you meant the uri-prefixes for http-targets should include the= endpoints with them (e.g. http://<host>/<path-prexif>) as you = have removed the endpoints fields ?


=
Thanks,
Ori






=

On Tue, Mar 6, 2018 at 5:31 PM, Ben Niven-Jenkins <ben@niven-jenkin= s.co.uk> wrote:
Hi Ori & Sanjay<= div>
I read your draft and I am not sure the objects you defi= ne contain sufficient information for the Footprint & Capabilities use = case you have.

My understanding is that you want a= dCDN to advertise its request router address(es) by geography.
<= br>
The FCI object you define does not provide a mapping between = the FQDN the client is requesting and the name/URI the dCDN would like that= FQDN to be redirected to.

With DNS redirection th= e uCDN needs to know what CNAME to return to the client=E2=80=99s DNS resol= ver and the dCDN=E2=80=99s request router needs to use a different CNAME pe= r =E2=80=9CCDN service=E2=80=9D so it can look up the appropriate metadata = for that =E2=80=9CCDN service=E2=80=9D.

With HTTP = redirection, what you have works if you assume a static mapping between the= URI the client requests from the uCDN and the redirection URI in the dCDN,= although I wonder if having the dCDN advertise a URI prefix explicitly mig= ht be better to provide the dCDN some choice in what mapping it uses.
=

Therefore I think you need to change your object from:<= /div>

"target-addresses": [ { =E2=80=9Cendpoin= ts": [] } ]

to something that also includes t= he host/FQDN the client will use in its request to the uCDN, e.g.:

=E2=80=9Chosts": { =E2=80=9C<host/FQDN>=E2=80= =9D: { "dns-targets": [ { =E2=80=9Cendpoints=E2=80=9D: [] } ] }, = =E2=80=9Chttp-targets": [ { =E2=80=9Curi-prefixes=E2=80=9D: [] } }

Regards
Ben



On 12 Feb 2018, at 14:32, Ori Finkelman <orif@qwilt.com> wrote:

Dear Colleagues,
Please see the new draft for the SVA requ= est routing extensions.

Best regards,
Or= i


---------- Forwarded m= essage ----------
From: <inte= rnet-drafts@ietf.org>
Date: Mon, Feb 12, 2018 at 4:30 PMSubject: New Version Notification for draft-finkelman-cdni-rr-sva-ex= tensions-00.txt
To: Sanjay Mishra <sanjay.mishra@verizon.com>, Ori Finkelm= an <orif@qwilt.com>



A new version of I-D, draft-finkelman-cdni-rr-sva-extensions-00.txt has been successfully submitted by Ori Finkelman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-finkelman-cdni-rr-sva-e= xtensions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI SVA Request Routing Extension= s
Document date:=C2=A0 2018-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft= -finkelman-cdni-rr-sva-extensions-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-= sva-extensions/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-exte= nsions-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-finkelman-c= dni-rr-sva-extensions-00


Abstract:
=C2=A0 =C2=A0The Open Caching working group of the Streaming Video Alliance= is
=C2=A0 =C2=A0focused on the delegation of video delivery requests from comm= ercial
=C2=A0 =C2=A0CDNs to a caching layer at the ISP.=C2=A0 In that aspect, Open= Caching is
=C2=A0 =C2=A0a specific use case of CDNI, where the commercial CDN is the u= pstream
=C2=A0 =C2=A0CDN (uCDN) and the ISP caching layer is the downstream CDN (dC= DN).





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
_______________________________________________
CDNi mailing listCDNi@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/cdni" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/cdni




-= -
Ori Finkelman
Qwilt | Work:= +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com



--
=
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +9= 72-52-3832189 | orif@qwilt.com
--94eb2c0d247668e3500569e2f2c9-- From nobody Sun Apr 15 08:07:40 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696DA1270B4 for ; Sun, 15 Apr 2018 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qwilt-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk626vhBp_WN for ; Sun, 15 Apr 2018 08:07:33 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65966127275 for ; Sun, 15 Apr 2018 08:07:33 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id c10-v6so6204074ybn.7 for ; Sun, 15 Apr 2018 08:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=lvIBGnMQO0FramtVn+YOpqPXf5r2ESo3ZquwAuC8lqw=; b=RtxCpIFCEQ92AxX28XmJlcRDxm1uGgpUTNl2MTRDBWhsb76gSUHi1TiF0VcnQXm/Kh LJsDu7TOCv8p8yuEjam6E1qD+61Yi3sGYqaD99rv2VDvHYp//xkUeRKUit64sXR/6SDh +ZZ0DSUt8TJy/yvmkWApEuKWDKUvLA/day24A63oe8hmqxynmJ0UOcLX1OIRshRYbBZO WI0wRWPmJZv3YgH6c+2xbSuv7TMTLmjU9Lv/jVQHNuBBin6QRjOclcrNO3fTJhQZikyO Iw+K571DQTLlxpoiWOmzeVpcz0x0MEDQ5k2GesurWRJCP4ta5lueRNe54+6XIyDZStfb IMYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lvIBGnMQO0FramtVn+YOpqPXf5r2ESo3ZquwAuC8lqw=; b=jbTXEFTmi13ki4HCYAgxAwATdzmB1wcy9HBhi7RnlApsIdkR1W5WHUFnhDRPnBnEPi d4XNMYRPNaekI4syHAoUz7y654zjs3DdXp4W6S+KDoEu7BSgElZMd73vUIjGywm9aC8q qElQARt5UavybRQ6Z0KOU8xax3H41jCwGq9RsMn+HVZZ+EtysybZERUdQfW/hd8aXvLY l+cd21a0h+cuBrOKVSE9Ls3ederhuNLcOjH4GP7N5B2U8J22mp+XRZ340GLotonGnCek rtugsrwiLZu6vjOSuBk6bjat5PaVg+hvev8qcUEY3yjTJLucnI5J+3dF4jVpWcaVrQHA Hdxg== X-Gm-Message-State: ALQs6tBT2INnafAHcayNAcTBa5hEHMsB0XfDnT3hiSrFk6EeHWO7jMHQ cfVlcekUDz5zLI3Wm69AaTF7qHe8leoytX28gTDKlg== X-Google-Smtp-Source: AIpwx4/w0JPfbw3ZFiRakI2sSWkAaToIpZy/pcNIPCINEtGbctgoDZJ/U4nrDqd7g1YdESYQrd4lper0twjPlgoa3EU= X-Received: by 2002:a25:c9c7:: with SMTP id z190-v6mr9042396ybf.402.1523804852414; Sun, 15 Apr 2018 08:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d38b:0:0:0:0:0 with HTTP; Sun, 15 Apr 2018 08:07:01 -0700 (PDT) From: Ori Finkelman Date: Sun, 15 Apr 2018 18:07:01 +0300 Message-ID: To: Ben Niven-Jenkins Cc: "" Content-Type: multipart/alternative; boundary="000000000000ef81a60569e476b3" Archived-At: Subject: [CDNi] redirect target capability object X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 15:07:38 -0000 --000000000000ef81a60569e476b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [renames thread. this thread discusses the redirect target capability object proposed in draft-finkelman-cdni-rr-sva-extensions-00.txt] Hi, Here is my proposal for the fixed redirect target object. Comments are within the JSON object for clarity. A few points for discussion below the object. { "capabilities": [ { "capability-type": "FCI.RedirectTarget", "capability-value": { "ucdn-hosts": [ endpoints ], # a list of uCDN hosts that this redirect target applies to # a ucdn-host is a host which is mapped to a specific metadata HostMatch object # the ucdn-hosts is optional. The default is this target for redirect of all services of the uCDN "dns-target": { "host" :"" # a host name, used for CNAME redirect from uCDN to dCDN # I have allowed a single host here rather than an array as I don't see the case of allowing the uCDN to choose to which dCDN target to redirect the traffic. Load balancing should be done within the dCDN by other means. }, # the dns-target is optional, but either dns-target or http-target MUST be present and non-empty "http-target": { "host" : "", # a hostname use for the HTTP redirect from uCDN to dCDN. Mandatory # I have allowed a single host here rather than an array as I don't see the case of allowing the uCDN to choose to which dCDN target to redirect the traffic. Load balancing should be done within the dCDN by other means. "path-prefix": "" # path prefix for the HTTP redirect. the original path is appended after this prefix. # optional. the default is for the uCDN to prepend the uCDN host, as it appears in the HostMatch metadata object, as the first path segment. } }, # the http-target is optional, but either dns-target or http-target MUST be present and non-empty "footprints": [ ] } ] } *Discussion points* 1. Single or multiple targets - we have tried to find a use case in which it is beneficial for the uCDN to be aware of multiple targets for a given footprint, and I couldn't find such. Therefore I have enabled a single target rather than an array. Would be good to get feedback about this. 2. I am using the endpoint object which is defined in https://tools.ietf.org/html/rfc8006#section-4.3.3 however, this allows using a dotted IP notation, which is not relevant in most of the cases, for example it can't be used for CNAME delegation. Still I don't think this calls for definition of a new object that will allow only FQDN ? thoughts ? 3. We need clear definition of how to use the path-prefix. Here is an initial proposal + If path-prefix is not present, the uCDN should set it's own hostname, as appears int he ucdn-hosts field, and the respective metadata HostMatch object, as the fast path segment. + If path-prefix is present and not empty, the uCDN should use ONLY this path prefix. + If path-prefix is present but empty, the uCDN should not prepend any prefix and use it's own content path as is. Thanks, Ori On Sun, Apr 15, 2018 at 4:18 PM, Ori Finkelman wrote: > Hi, > Here is my proposal for the fixed redirect target object. > Comments are within the JSON object for clarity. > A few points for discussion below the object. > > { > "capabilities": [ > { > "capability-type": "FCI.RedirectTarget", > "capability-value": { > "ucdn-hosts": [ endpoints ], > > # a list of uCDN hosts that this redirect target applies to > # a ucdn-host is a host which is mapped to a specific metadata HostMatch > object > # the ucdn-hosts is optional. The default is this target for redirect of > all services of the uCDN > > "dns-target": { > "host" :"" > # a host name, used for CNAME redirect from uCDN to dCDN > # I have allowed a single host here rather than an array as I don't see > the case of allowing the uCDN to choose to which dCDN target to redirect = the > traffic. Load balancing should be done within the dCDN by other means. > }, > # the dns-target is optional, but either dns-target or http-target MUST > be present and non-empty > "http-target": { > "host" : "", > # a hostname use for the HTTP redirect from uCDN to dCDN. Mandatory > # I have allowed a single host here rather than an array as I don't see > the case of allowing the uCDN to choose to which dCDN target to redirect = the > traffic. Load balancing should be done within the dCDN by other means. > "path-prefix": "" > # path prefix for the HTTP redirect. the original path is appended after > this prefix. > # optional. the default is for the uCDN to prepend the uCDN host, as it > appears in the HostMatch metadata object, as the first path segment. > } > }, > # the http-target is optional, but either dns-target or http-target MUST > be present and non-empty > "footprints": [ > > ] > } > ] > } > > > *Discussion points* > 1. Single or multiple targets - we have tried to find a use case in which > it is beneficial for the uCDN to be aware of multiple targets for a given > footprint, and I couldn't find such. Therefore I have enabled a single > target rather than an array. Would be good to get feedback about this. > > 2. I am using the endpoint object which is defined in > https://tools.ietf.org/html/rfc8006#section-4.3.3 however, this allows > using a dotted IP notation, which is not relevant in most of the cases, f= or > example it can't be used for CNAME delegation. Still I don't think this > calls for definition of a new object that will allow only FQDN ? thoughts= ? > > 3. We need clear definition of how to use the path-prefix. Here is an > initial proposal > + If path-prefix is not present, the uCDN should set it's own hostname, a= s > appears int he ucdn-hosts field, and the respective metadata HostMatch > object, as the fast path segment. > + If path-prefix is present and not empty, the uCDN should use ONLY this > path prefix. > + If path-prefix is present but empty, the uCDN should not prepend any > prefix and use it's own content path as is. > > > > Thanks, > Ori > > > On Mon, Mar 26, 2018 at 12:12 PM, Ori Finkelman wrote: > >> Hi Ben, all, >> Took me some time to get back to this. >> >> A few questions regarding your proposal. >> >> >> Your proposal splits between dns-targets and http-targets, which make >> sense. >> However this makes me think that we should be more flexible and instead >> of using the method name prepended to the "-target" we could have a >> separate field indicating which type of redirection mode it applies to, >> choosing from redirection modes available in https://tools.ietf.org/htm= l >> /rfc8008#section-6.2 ) (i.e DNS-I, DNS-R, HTTP-I, HTTP-R etc.) >> >> >> The object you have defined relates the to the dns targets, >> but not to the http-targets. Wouldn't it be more flexible to allow this >> also for the http-targets, and by that enabling different dCDN host name= s >> for different services also in HTTP redirect ? >> I am not quite sure about this, as the mapping for services in HTTP >> redirection is supposed to work by putting the uCDN host name as the fir= st >> path segment in the dCDN path, as proposed in https://tools.ietf.org/htm= l >> /rfc7336#section-3.2 >> However, maybe there are use cases in which it would be beneficial to se= t >> the dCDN target address per the uCDN host name ? I am looking for feedba= ck >> / ideas about this. >> >> >> As for the uri-prefixes, I think that is a good idea. Did you meant the >> uri-prefixes for http-targets should include the endpoints with them (e.= g. >> http:///) as you have removed the endpoints fields ? >> >> >> Thanks, >> Ori >> >> >> >> >> >> >> >> On Tue, Mar 6, 2018 at 5:31 PM, Ben Niven-Jenkins < >> ben@niven-jenkins.co.uk> wrote: >> >>> Hi Ori & Sanjay >>> >>> I read your draft and I am not sure the objects you define contain >>> sufficient information for the Footprint & Capabilities use case you ha= ve. >>> >>> My understanding is that you want a dCDN to advertise its request route= r >>> address(es) by geography. >>> >>> The FCI object you define does not provide a mapping between the FQDN >>> the client is requesting and the name/URI the dCDN would like that FQDN= to >>> be redirected to. >>> >>> With DNS redirection the uCDN needs to know what CNAME to return to the >>> client=E2=80=99s DNS resolver and the dCDN=E2=80=99s request router nee= ds to use a >>> different CNAME per =E2=80=9CCDN service=E2=80=9D so it can look up the= appropriate >>> metadata for that =E2=80=9CCDN service=E2=80=9D. >>> >>> With HTTP redirection, what you have works if you assume a static >>> mapping between the URI the client requests from the uCDN and the >>> redirection URI in the dCDN, although I wonder if having the dCDN adver= tise >>> a URI prefix explicitly might be better to provide the dCDN some choice= in >>> what mapping it uses. >>> >>> Therefore I think you need to change your object from: >>> >>> "target-addresses": [ { =E2=80=9Cendpoints": [] } ] >>> >>> to something that also includes the host/FQDN the client will use in it= s >>> request to the uCDN, e.g.: >>> >>> =E2=80=9Chosts": { =E2=80=9C=E2=80=9D: { "dns-targets": [ { = =E2=80=9Cendpoints=E2=80=9D: [] } ] }, >>> =E2=80=9Chttp-targets": [ { =E2=80=9Curi-prefixes=E2=80=9D: [] } } >>> >>> Regards >>> Ben >>> >>> >>> >>> On 12 Feb 2018, at 14:32, Ori Finkelman wrote: >>> >>> Dear Colleagues, >>> Please see the new draft for the SVA request routing extensions. >>> >>> Best regards, >>> Ori >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, Feb 12, 2018 at 4:30 PM >>> Subject: New Version Notification for draft-finkelman-cdni-rr-sva-ex >>> tensions-00.txt >>> To: Sanjay Mishra , Ori Finkelman < >>> orif@qwilt.com> >>> >>> >>> >>> A new version of I-D, draft-finkelman-cdni-rr-sva-extensions-00.txt >>> has been successfully submitted by Ori Finkelman and posted to the >>> IETF repository. >>> >>> Name: draft-finkelman-cdni-rr-sva-extensions >>> Revision: 00 >>> Title: CDNI SVA Request Routing Extensions >>> Document date: 2018-02-12 >>> Group: Individual Submission >>> Pages: 9 >>> URL: https://www.ietf.org/internet- >>> drafts/draft-finkelman-cdni-rr-sva-extensions-00.txt >>> Status: https://datatracker.ietf.org/ >>> doc/draft-finkelman-cdni-rr-sva-extensions/ >>> Htmlized: https://tools.ietf.org/html/d >>> raft-finkelman-cdni-rr-sva-extensions-00 >>> Htmlized: https://datatracker.ietf.org/ >>> doc/html/draft-finkelman-cdni-rr-sva-extensions-00 >>> >>> >>> Abstract: >>> The Open Caching working group of the Streaming Video Alliance is >>> focused on the delegation of video delivery requests from commercial >>> CDNs to a caching layer at the ISP. In that aspect, Open Caching is >>> a specific use case of CDNI, where the commercial CDN is the upstrea= m >>> CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> -- >>> >>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >>> +972-52-3832189 <052-383-2189> | orif@qwilt.com >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> >>> >>> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >> orif@qwilt.com >> > > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | > orif@qwilt.com > --=20 *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --000000000000ef81a60569e476b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[renames thread. this thread discusses the redirect target= capability object proposed in=C2=A0 draft-finkelman-cdni-rr-sva-extensions-00.txt]

Hi,
Here is my proposal for the fixed redirect target = object.
Comments are within the JSON object for clarity.
A few points for discussion below the object.

=C2=A0{
=C2=A0 =C2=A0 =C2=A0"capabilities": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= ;capability-type": "FCI.RedirectTarget",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"capability-value": {
=C2=A0 =C2=A0 =C2=A0"ucdn-hosts": [ endpoints ],

# a lis= t of uCDN hosts that this=C2=A0redirect=C2=A0target=C2=A0applies t= o
# a ucdn-host is a host which is mapp= ed to a specific metadata HostMatch object=C2=A0
# the ucdn-hosts is optional. The default is this=C2=A0target= =C2=A0for=C2=A0redirect=C2=A0of all services of the uCDN<= /font>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= ;dns-target&quo= t;: {=C2=A0
=C2=A0 =C2= =A0 =C2=A0"host" :"<endpoint>"
# a host name, used for CNAME=C2=A0redirect=C2=A0fr= om uCDN to dCDN
# I have allowed a sing= le host here rather than an array as I don't see the case of allowing t= he uCDN to choose to which dCDN=C2=A0target=C2=A0to=C2=A0<= /span>redirect<= span>=C2=A0the traffic. Load balancing should be done within the dCD= N by other means.
=C2=A0 =C2=A0 =C2=A0},
# the dns-target=C2=A0i= s optional, but either dns-target=C2=A0or http-target=C2=A0MUST be present and = non-empty
= =C2=A0"http-target": {
=C2=A0 =C2=A0 =C2=A0"host" : "<endpoint>",
# a hostname use for the HTTP=C2=A0redirect=C2= =A0from uCDN to dCDN. Mandatory
= # I have allowed a single host here rather than an= array as I don't see the case of allowing the uCDN to choose to which = dCDN=C2=A0target=C2=A0to=C2=A0redirect=C2=A0the traff= ic. Load balancing should be done within the dCDN by other means.=C2=A0
=C2=A0 =C2=A0 =C2=A0"path-prefix": "<path>"<= /div>
# path prefix for the HTTP=C2=A0<= span class=3D"gmail-m_-1075266700717757776gmail-il">redirect. the or= iginal path is appended after this prefix.=C2=A0
# optional. the default is for the uCDN to prepend the uCDN host,= as it appears in the HostMatch metadata object, as the first path segment.=
=C2=A0 =C2=A0 = =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
# the http-target<= /span>=C2=A0is optional, but either dns-target=C2=A0or http-target=C2=A0<= /span>MUST be present and non-empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0"footprints": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<Footprint objects>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2= =A0 }


Discussion points
1. Single or multiple targets - we have tried to find a use case in= which it is beneficial for the uCDN to be aware of multiple targets for a = given footprint, and I couldn't find such. Therefore I have enabled a s= ingle target rather than an array. Would be good to get feedback about this= .

2. I am using the endpoint object which is defin= ed in=C2=A0https://tools.ietf.org/= html/rfc8006#section-4.3.3=C2=A0however, this allows using= a dotted IP notation, which is not relevant in most of the cases, for exam= ple it can't be used for CNAME delegation. Still I don't think this= calls for definition of a new object that will allow only FQDN ? thoughts = ?

3. We need clear definition of how to use the pa= th-prefix. Here is an initial proposal
+ If path-prefix is not pr= esent, the uCDN should set it's own hostname, as appears int he ucdn-ho= sts field, and the respective metadata HostMatch object, as the fast path s= egment.
+ If path-prefix is present and not empty, the uCDN shoul= d use ONLY this path prefix.
+ If path-prefix is present but empt= y, the uCDN should not prepend any prefix and use it's own content path= as is.

Thanks,
Ori

=

On Sun,= Apr 15, 2018 at 4:18 PM, Ori Finkelman <orif@qwilt.com> wrote:=
Hi,
Here is my prop= osal for the fixed redirect target object.
Comments are within th= e JSON object for clarity.
A few points for discussion below the = object.

= =C2=A0{
=C2=A0 =C2=A0 =C2=A0"capabilities": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;capability-type": "FCI.RedirectTarget",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"capability-value": {
=C2=A0 =C2=A0 =C2=A0"ucdn-hosts": [ endpoints ],
=
=
# a list o= f uCDN hosts that this=C2=A0redirect=C2=A0target=C2=A0applies to
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial"><= font color=3D"#0000ff"># a ucdn-host is a host which is mapped to a specifi= c metadata HostMatch object=C2=A0
# the= ucdn-hosts is optional. The default is this=C2=A0target=C2=A0for=C2=A0redirect=C2=A0of all services of the uCDN

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"dns-target": {=C2=A0
=C2=A0 =C2=A0 =C2=A0"host" :&quo= t;<endpoint>"
# a host name, used f= or CNAME=C2=A0r= edirect=C2=A0from uCDN to dCDN
# I have allowed a single host here rather than an array as I= don't see the case of allowing the uCDN to choose to which dCDN= =C2=A0target=C2=A0to=C2=A0redirect=C2=A0the traffic. Load balancing sho= uld be done within the dCDN by other means.
=C2=A0 =C2=A0 =C2=A0},
# the dns-target<= span>=C2=A0is optional, but either dns-target=C2=A0or http-target=C2=A0MUST be prese= nt and non-empty
=C2=A0"http-target": {
=C2=A0 =C2=A0 =C2=A0"host" : "<endpoint>",
# a hostname use for the HTTP=C2=A0<= span class=3D"m_-1075266700717757776gmail-il">redirect=C2=A0from uCDN to dCDN. Mandatory
# I have allowed a single host here rather than an arra= y as I don't see the case of allowing the uCDN to choose to which dCDN<= span>=C2=A0target=C2=A0to=C2=A0redirect=C2=A0the traffic. Load balancin= g should be done within the dCDN by other means.=C2=A0<= br>
=C2=A0 =C2= =A0 =C2=A0"path-prefix": "<path>"
# path prefix for the HTTP=C2=A0redirect. the original path is append= ed after this prefix.=C2=A0
# optional.= the default is for the uCDN to prepend the uCDN host, as it appears in the= HostMatch metadata object, as the first path segment.
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0},
# the http-target=C2=A0is o= ptional, but either dns-targ= et=C2=A0or http-target=C2=A0MUST be present and non-empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"footprints": [
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Footprint objects>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0= =C2=A0 =C2=A0]
=C2=A0 =C2=A0 }


Discussion points
1. = Single or multiple targets - we have tried to find a use case in which it i= s beneficial for the uCDN to be aware of multiple targets for a given footp= rint, and I couldn't find such. Therefore I have enabled a single targe= t rather than an array. Would be good to get feedback about this.

2. I am using the endpoint object which is defined in=C2=A0= https://tools.ietf.org/html/rfc8006#section-4.3.3 however, th= is allows using a dotted IP notation, which is not relevant in most of the = cases, for example it can't be used for CNAME delegation. Still I don&#= 39;t think this calls for definition of a new object that will allow only F= QDN ? thoughts ?

3. We need clear definition of ho= w to use the path-prefix. Here is an initial proposal
+ If path-p= refix is not present, the uCDN should set it's own hostname, as appears= int he ucdn-hosts field, and the respective metadata HostMatch object, as = the fast path segment.
+ If path-prefix is present and not empty,= the uCDN should use ONLY this path prefix.
+ If path-prefix is p= resent but empty, the uCDN should not prepend any prefix and use it's o= wn content path as is.



Thanks,
Ori


On Mon, Mar 26, 2018 at 12:12 PM, Ori Finkelman <orif@qwilt.com<= /a>> wrote:
Hi= Ben, all,
Took me some time to get back to this.

<= div>A few questions regarding your proposal.


<= /div>
Your proposal splits between dns-targets and http-targets, which = make sense.


The= object you have defined relates the <host/FQDN> to the dns targets, = but not to the http-targets. Wouldn't it be more flexible to allow this= also for the http-targets, and by that enabling different dCDN host names = for different services also in HTTP redirect ?=C2=A0
I am not qui= te sure about this, as the mapping for services in HTTP redirection is supp= osed to work by putting the uCDN host name as the first path segment in the= dCDN path, as proposed in=C2=A0https://tools.ietf.org/html/rfc7336= #section-3.2=C2=A0
However, maybe there are use cases in whic= h it would be beneficial to set the dCDN target address per the uCDN host n= ame ? I am looking for feedback / ideas about this.


As for the uri-prefixes, I think that is a good idea. Did = you meant the uri-prefixes for http-targets should include the endpoints wi= th them (e.g. http://<host>/<path-prexif>) as you have removed = the endpoints fields ?


Thanks,<= /div>
Ori







On Tue, Mar 6, 2018 at 5:31 PM, Ben Niven-J= enkins <ben@niven-jenkins.co.uk> wrote:
Hi Ori & Sanjay

I read your draft and I am= not sure the objects you define contain sufficient information for the Foo= tprint & Capabilities use case you have.

My un= derstanding is that you want a dCDN to advertise its request router address= (es) by geography.

The FCI object you define does = not provide a mapping between the FQDN the client is requesting and the nam= e/URI the dCDN would like that FQDN to be redirected to.

With DNS redirection the uCDN needs to know what CNAME to return to = the client=E2=80=99s DNS resolver and the dCDN=E2=80=99s request router nee= ds to use a different CNAME per =E2=80=9CCDN service=E2=80=9D so it can loo= k up the appropriate metadata for that =E2=80=9CCDN service=E2=80=9D.
=

With HTTP redirection, what you have works if you assum= e a static mapping between the URI the client requests from the uCDN and th= e redirection URI in the dCDN, although I wonder if having the dCDN adverti= se a URI prefix explicitly might be better to provide the dCDN some choice = in what mapping it uses.

Therefore I think you nee= d to change your object from:

"target-address= es": [ { =E2=80=9Cendpoints": [] } ]

to = something that also includes the host/FQDN the client will use in its reque= st to the uCDN, e.g.:

=E2=80=9Chosts": { =E2= =80=9C<host/FQDN>=E2=80=9D: { "dns-targets": [ { =E2=80=9Ce= ndpoints=E2=80=9D: [] } ] }, =E2=80=9Chttp-targets": [ { =E2=80=9Curi-= prefixes=E2=80=9D: [] } }

Regards
Ben



On 12 Feb 2018, = at 14:32, Ori Finkelman <orif@qwilt.com> wrote:

=
Dear Colleagues,
Please see the new draf= t for the SVA request routing extensions.

Best reg= ards,
Ori


----= ------ Forwarded message ----------
From: = <internet-drafts@ietf.org>
Date: Mon, Feb 12,= 2018 at 4:30 PM
Subject: New Version Notification for draft-finkelman-c= dni-rr-sva-extensions-00.txt
To: Sanjay Mishra <sanjay.mishra@verizon.com>, Ori Finkelman <orif@qwilt.com>



A new version of I-D, draft-finkelman-cdni-rr-sva-extensions-00.txt has been successfully submitted by Ori Finkelman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-finkelman-cdni-rr-sva-e= xtensions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI SVA Request Routing Extension= s
Document date:=C2=A0 2018-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft= -finkelman-cdni-rr-sva-extensions-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-= sva-extensions/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-exte= nsions-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-finkelman-c= dni-rr-sva-extensions-00


Abstract:
=C2=A0 =C2=A0The Open Caching working group of the Streaming Video Alliance= is
=C2=A0 =C2=A0focused on the delegation of video delivery requests from comm= ercial
=C2=A0 =C2=A0CDNs to a caching layer at the ISP.=C2=A0 In that aspect, Open= Caching is
=C2=A0 =C2=A0a specific use case of CDNI, where the commercial CDN is the u= pstream
=C2=A0 =C2=A0CDN (uCDN) and the ISP caching layer is the downstream CDN (dC= DN).





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Ori Finkelman
Qwil= t | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
_______________________________________________
CDNi mailing listCDNi@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/cdni" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/cdni




-= -
Ori Finkelman<= br>Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com



--
=



--
=
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +9= 72-52-3832189 | orif@qwilt.com
--000000000000ef81a60569e476b3--