[CDNi] redirect target capability object

[Ori Finkelman <[e-mail]>]

[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" :"<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 Sun, Apr 15, 2018 at 4:18 PM, Ori Finkelman <[e-mail]> 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" :"<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]
>



-- 

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