Subject: Re: [CDNi] New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 6 Mar 2018 14:31:38 +0000

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

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 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’s DNS resolver and the dCDN’s request router needs to use a different CNAME per “CDN service” so it can look up the appropriate metadata for that “CDN service”.

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 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": [ { “endpoints": [] } ]

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

“hosts": { “<host/FQDN>”: { "dns-targets": [ { “endpoints”: [] } ] }, “http-targets": [ { “uri-prefixes”: [] } }

Regards
Ben

> On 12 Feb 2018, at 14:32, Ori Finkelman <[email-masked]> wrote:
> 
> Dear Colleagues,
> Please see the new draft for the SVA request routing extensions.
> 
> Best regards,
> Ori
> 
> 
> ---------- Forwarded message ----------
> From: <[email-masked] <mailto:[email-masked]>>
> Date: Mon, Feb 12, 2018 at 4:30 PM
> Subject: New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt
> To: Sanjay Mishra <[email-masked] <mailto:[email-masked]>>, Ori Finkelman <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> 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 <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/ <https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/>
> Htmlized:       https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-extensions-00 <https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-extensions-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-finkelman-cdni-rr-sva-extensions-00 <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 <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked] <mailto:[email-masked]>_______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 7 Mar 2018 21:17:19 +0200

Hi Ben,
I totally agree.
What we had in mind was mainly focused on the HTTP redirect use case, where
the solution can be to use the uCDN FQDN as the first path segment, as
shown in section 3.2 of rfc 7336,
https://tools.ietf.org/html/rfc7336#section-3.2 and by that allowing the
dCDN to know which service is being requested.
DNS routing cannot be solved that way.
I will fix that in revision 01.

Thanks for feedback.
Best regards,
Ori

On Tue, Mar 6, 2018 at 4:31 PM, Ben Niven-Jenkins <[email-masked]>
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 have.
>
> 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’s DNS resolver and the dCDN’s request router needs to use a
> different CNAME per “CDN service” so it can look up the appropriate
> metadata for that “CDN service”.
>
> 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 might be better to provide the dCDN some choice in what mapping
> it uses.
>
> “hosts": { “<host/FQDN>”: { "dns-targets": [ { “endpoints”: [] } ] },
> “http-targets": [ { “uri-prefixes”: [] } }
>
> Regards
> Ben
>
>
>
> From: <[email-masked]>
> To: Sanjay Mishra <[email-masked]>, Ori Finkelman <
> [email-masked]>
>
>
>
> 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:
> 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> | [email-masked]
> _______________________________________________
> CDNi mailing list
> [email-masked]

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: [email-masked]
Date: Wed, 7 Mar 2018 23:58:42 +0000

Ben – Thank you and +1 to Ori.

-Sanjay

From: CDNi [mailto:[email-masked]] On Behalf Of Ori Finkelman
Sent: Wednesday, March 07, 2018 11:17 AM
To: Ben Niven-Jenkins <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: [E] Re: [CDNi] New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt

Hi Ben,
I totally agree.
What we had in mind was mainly focused on the HTTP redirect use case, where the solution can be to use the uCDN FQDN as the first path segment, as shown in section 3.2 of rfc 7336, https://tools.ietf.org/html/rfc7336#section-3.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7336-23section-2D3.2&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=P7zU1pxgiVUK4gmFcU21SLVqg3YQIsxwNB3toOPApCQ&e=> and by that allowing the dCDN to know which service is being requested.
DNS routing cannot be solved that way.
I will fix that in revision 01.

Thanks for feedback.
Best regards,
Ori

On Tue, Mar 6, 2018 at 4:31 PM, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ori & Sanjay

Regards
Ben

On 12 Feb 2018, at 14:32, Ori Finkelman <[email-masked]<mailto:[email-masked]>> wrote:

Dear Colleagues,

Best regards,
Ori

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Feb 12, 2018 at 4:30 PM
Subject: New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt
To: Sanjay Mishra <[email-masked]<mailto:[email-masked]>>, Ori Finkelman <[email-masked]<mailto:[email-masked]>>

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dfinkelman-2Dcdni-2Drr-2Dsva-2Dextensions-2D00.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=CKhoom5tmleJ0IITEw5sxsD06NgueTCFuPlOqcWq6zU&e=>
Status:         https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfinkelman-2Dcdni-2Drr-2Dsva-2Dextensions_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=9TOMYz1Y_pYQj9SPDuPIC9tr1YtQup2M2p1zoiC3DiU&e=>
Htmlized:       https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfinkelman-2Dcdni-2Drr-2Dsva-2Dextensions-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=Kn3ay_vKhxW1w9rshQcLxeOXMfm4SRASZA7skvXiiKs&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-finkelman-cdni-rr-sva-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dfinkelman-2Dcdni-2Drr-2Dsva-2Dextensions-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=nzuJ2zUehooPmQe78AV9uR_rrV1asgNI6D5X5E2BBzo&e=>

Abstract:

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=KAtCuGEfOP8ClSX_DwVVC4A60EzGp7QwtoCK5KnZoP8&e=>.

The IETF Secretariat

--
Ori Finkelman
Qwilt | Work: +972-72-2221647<tel:072-222-1647> | Mobile: +972-52-3832189<tel:052-383-2189> | [email-masked]<mailto:[email-masked]>
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=I8mVVuUSsycP4ReLMBrhgyV2PrXMJvEee9FMWO8Tja8&s=NB6uRjRQGCajxllGQ06vKPGzzjypjgrQe6IJR0t09HU&e=>

--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]<mailto:[email-masked]>

---

From: Ori Finkelman <[email-masked]>
Date: Mon, 26 Mar 2018 12:12:23 +0300

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/
html/rfc8008#section-6.2 ) (i.e DNS-I, DNS-R, HTTP-I, HTTP-R etc.)

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 ?
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 first
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 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 with them (e.g.
http://<host>/<path-prexif>) as you have removed the endpoints fields ?

Thanks,
Ori

--