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

[Ori Finkelman <[e-mail]>]

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" :"<endpoint>"
# 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" : "<endpoint>",
# 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>"
# 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": [
           <Footprint objects>
         ]
       }
     ]
    }


*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 <[e-mail]> 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/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
>
>
>
>
>
>
>
> On Tue, Mar 6, 2018 at 5: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-ex
>> tensions-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]
>



-- 

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