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

[Ori Finkelman <[e-mail]>]

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 <[e-mail]>
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.
>
> 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 <[e-mail]> wrote:
>
> Dear Colleagues,
> Please see the new draft for the SVA request routing extensions.
>
> Best regards,
> Ori
>
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> 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 <[e-mail]>, Ori Finkelman <
> [e-mail]>
>
>
>
> 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: [phone] <072-222-1647> | Mobile:
> [phone] <052-383-2189> | [e-mail]
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>
>
>


-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]