Re: [CDNi] Cache management interface | Triggers v2

[Alan Arolovitch <[e-mail]>]

Jay,

The nice thing about using BGP ASNs for CDN identification is that it
piggybacks an existing framework that is easy to look up and
the identifier uniqueness is assured, at least for public ASNs.
However, in my view, the use of ASNs to identify CDNs within the CDNI
architecture is fully obsolete.
You may have uCDNs that do not have their own AS (e.g. content provider
using 3rd party networks for origin layer),
dCDNs deployed across multiple ASNs, and what's worse - multiple dCDNs that
share the same AS and maybe even multiple uCDNs doing so.

By making cdn-path in the trigger command optional in CI/T v2 we do not
break CI/T v1 and backwards compatibility is maintained.
The CI/T v2 capable dCDN will be able to consume both CI/T v1 triggers with
cdn-path and CI/T v2 triggers without it.
The Error.v2 Description object can only be sent to a CI/T v2 capable uCDN
in response to a CI/T v2 trigger, so there's no incompatibility risk.

Making cdn-path and cdn-id optional would take care of the SVTA OC / CDNI
interoperability in the context of CI/T v2,
without forcing implementers to use dummy values.

There's a broader question of updating the CDNi identification scheme with
a mechanism that would not depend on BGP and also
address cascading (if indeed needed in the future) and, more importantly,
mutual identification of uCDN and dCDN during authentication
phase of the CDNi interface access.
There's ongoing work in the SVTA Testbed WG and it considers using:
- using OAuth 2.0 (RFC6749) with external identity server, that can be
shared by multiple dCDNs and uCDNs, and would be a preferred option for any
cascading scenarios
- self-issued JWT tokens (RFC9068) based on shared secrets between directly
attached dCDN and uCDN (i.e. dCDN acts as its own identity provider)

Based on this effort, the CDN identifier should include at least the
identity provider URI (3rd party identity server or dCDN-operated) and the
CDN ID.
Given that this effort will not conclude before the CI/T v2 draft goes into
the last call, maybe we should allow an additional optional field in the
trigger command
and Error.v2 Description that can be used later once this new
identification scheme is fully established

Kind regards
Alan


On Tue, Mar 5, 2024 at 11:20 PM Jay Robertson <[e-mail]> wrote:

> Hi Alan,
>
> After giving this some consideration, I am not entirely unconvinced that
> making the cascading information optional is the best approach.  This is a
> simple safety mechanism meant to prevent loops that have unintended, and
> potentially detrimental, consequences.  While I understand that open
> caching is today's most likely use case for CDNi rather than a federated
> delegation model, I think assuming that this will be the primary or only
> use case going forward is not the safest bet as we often cannot predict how
> these specifications may be used in the distant future--or even the odd
> ways that someone might be using them now.  Additionally, I know that some
> amount of care and effort has been spent amending CI/T without breaking the
> original RFC8007.
>
> I think you have an interesting point regarding the use of AS numbers.
> One thing I might note is that the context that AS numbers are being used
> is simply for identification.  I don't think they necessarily need to
> impart any meaning regarding the underlying network architecture.  If a CDN
> has multiple AS numbers in its network, I think they could simply pick one
> and use it consistently for identification purposes.  However, an
> organization could possibly have no AS numbers, particularly if they
> operate a pure open caching network that embeds caches in service provider
> networks, for example.  While I recognize that this could happen, I'm not
> sure I understand how large of a problem this is, and I struggle to think
> of a great solution.  Guillaume suggested possibly negotiating this with a
> bootstrap API, but as far as I can tell, that still remains an
> unimplemented suggestion of RFC7337.  If this is not a huge problem to
> solve, one thing that could be considered is that there is a large range of
> 32-bit private AS numbers (4200000000–4294967294) available.  While not
> wonderful or elegant, one could pick a number at random out of this pool
> and feel reasonably certain about having a unique number.  As written, CI/T
> makes no judgment about the AS number chosen.  Of course, I'm open to other
> suggestions if someone can think of a better approach.
>
> Thanks,
> - Jay
>
>
> On Tue, Mar 5, 2024 at 4:49 AM Guillaume Bichot <
> [e-mail]> wrote:
>
>> Hi Alan.
>>
>> There are several use cases wherein the AS number is not appropriate and
>> also several ones wherein we do not need the cdn-path at all.
>>
>> Therefore, I would go with your two proposals: 1/ making the cdn-path
>> optional and 2/ allowing an alternative format for the CDN PID. The latter
>> is related to CDN identification as a general problem in SVTA OC. This came
>> up as a subject related to authentication where the uCDN is identified
>> through a dedicated claim. The token used during authentication is computed
>> by the dCDN that decides by itself how to identify the uCDN. We could have
>> imagined reusing this uCND id as a the CDN PID. However, this is not
>> standardized process as the form of the token is not imposed in Open
>> Caching.  So, we are back with the pb: how to identify uniquely a CDN. I
>> would propose a mechanism where the dCDN selects and impose the uCDN PID.
>> This could be done through a dedicated API as part of the bootstrap API.
>> For now, regarding the I-D, allowing an alternative scheme would be
>> sufficient maybe like instead of an id starting with AS, we would have a
>> scheme starting with PR (for private) .
>>
>>
>>
>> Guillaume
>>
>>
>>
>>
>>
>> *From:* CDNi <[e-mail]> *On Behalf Of *Alan Arolovitch
>> *Sent:* Tuesday, March 5, 2024 1:43 AM
>> *To:* [e-mail]
>> *Subject:* Re: [CDNi] Cache management interface | Triggers v2
>>
>>
>>
>> One of the goals of the CI/T v2 changes proposed below is to make the
>> cache management interface defined under the open caching architecture
>>
>> fully interoperable with the CI/T v2 triggers.
>>
>> One of the topics that came up in this context is cascaded CDN use case
>> and I would like to solicit the group's feedback to the following:
>>
>> The CDNI architecture in several places deal with CDN cascading,
>> including at least:
>> - request redirection loops (
>> https://www.rfc-editor.org/rfc/rfc7337.html#section-5)
>> - trigger loop detection (CI/T v1
>> https://datatracker.ietf.org/doc/html/rfc8007#section-4.6,  CI/T v2
>> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-ci-triggers-rfc8007bis-11#name-loop-detection-and-preventi
>> )
>> - distribution of metadata in a chain (
>> https://datatracker.ietf.org/doc/html/rfc8006#section-3.2)
>>
>> RFC8007 p4.6 prescribes use of CDN Provider ID (CDN PID) based on ASN, to
>> prevent loops in a cascaded use case
>>
>> The CI/T v2 draft prescribes attaching CDN PID to trigger commands going
>> from uCDN down the chain and error statuses going up the chain from dCDN(s)
>> to uCDN.
>>
>> This is clearly lacking flexibility for actual deployments, where neither
>> uCDNs nor dCDNs necessarily align on AS boundaries.
>>
>>
>>
>> By contrast, the open caching architecture takes a simpler view of the
>> topology and concerns itself with directly attached CDNs only.
>>
>> It doesn't preclude cascading, so it is possible for CDN A to delegate
>> traffic to CDN B which in turn delegates it to CDN C, so that CDN B (tCDN
>> in CDNI terminology)
>> acts as dCDN to CDN A, and as uCDN to CDN C.
>>
>> However under open caching it would be the duty of CDN B to relate
>> commands and metadata between CDN A and CDN C, in a way that prevents loops
>> and without
>> CDN A and the CDN C on either side of CDN B being aware of each other's
>> existence.
>>
>> Also the loop detection appears to be less of a concern, because of how
>> the open caching primarily handles delegation from CDNs with broad coverage
>> footprint down to
>> (ISP-based) CDNs with increasingly narrowing footprint. This is unlike
>> CDNi which initially envisioned a federated delegation model, which made
>> loops in a delegation chain much more likely.
>>
>> One way to make CI/T v2 triggers (and broader CDNI architecture)
>> interoperable with the open caching specs is by either:
>> a. making CDN cascading information optional (e.g. "cdn-path" in CI/T v2
>> trigger command and "cdn-id" in Error.v2 Description in the CI/T v2 draft)
>> b. OR by allowing self-allocated CDN PIDs that are not AS-based
>>
>> Alternatively, if there's a real need to support explicit cascading, we
>> would minimally need a mechanism for CDN PID allocation and management that
>> doesn't depend on AS numbers.
>>
>>
>>
>> Is it a fair assessment of the status quo?
>> Thoughts and comments are welcome.
>>
>> Cheers
>>
>> Alan
>>
>>
>>
>>
>>
>> On Tue, Feb 13, 2024 at 7:18 PM Alan Arolovitch <[e-mail]> wrote:
>>
>> Hello,
>>
>> As a follow-up to my email from last year, I have had sidebar
>> conversations with Nir and Sanjay about the below.
>>
>> There's an interim proposal for the CI/T v2 draft modifications outlined
>> here
>>
>> https://docs.google.com/document/d/11oBs3CMnYSbuXR0rHNU26qe3lLKaug2yKp81aML265c/edit?usp=sharing
>>
>>
>>
>> To summarize it briefly, the CI/T trigger execution model today leaves
>> room for dCDN to process triggers submitted to it by uCDN
>> in any order, in parallel or sequentially, immediately or in batches.
>> There's a need for uCDN to determine trigger processing in further
>> detail, including order and timing of processing, trigger
>> inter-dependencies, and to monitor trigger processing queueing in further
>> detail.
>>
>>
>>
>> To address the above, it is primarily proposed to:
>>
>> - Introduce ExecutionPolicy trigger extension, that would allow uCDN to
>> indicate (i) relative trigger priority (ii) trigger urgency (iii) trigger
>> dependency on other triggers
>>
>> - Introduce trigger labels in key-value format, that can be set at
>> trigger level and/or by trigger extensions, so that trigger status
>> collections
>> can include trigger labels in addition to the trigger URLs, and trigger
>> status collections can be filtered by label in addition to being filtered
>> by
>>
>> trigger state
>>
>> We would like to merge the proposal into the next CI/T v2 draft
>>
>>
>>
>> Kind regards,
>>
>> Alan
>>
>>
>>
>>
>>
>> On Thu, Oct 26, 2023 at 1:26 PM Alan Arolovitch <[e-mail]> wrote:
>>
>>
>> Hello
>>
>> I'm leading the cache management interface project at SVTA. The scope is
>> to define a full-fledged CDNi-compliant cache management interface as part
>> of the open caching architecture
>> We are heading towards completion of the initial spec draft, and I would
>> like to share my thoughts on how to best bring this work into CDNi.
>> The current high-level scope includes:
>> - Trigger-based cache data operations that rely on and extend CDNi
>> triggers v2 as currently defined in CDNI CI/T 2nd edition
>> - Additional CDNi metadata objects allowing uCDN to assign cache objects
>> in configuration hierarchy to cache buckets; tag cache objects for use in
>> triggers via content.ccid trigger type; indicate cache object priority
>> - Cache bucket management API
>>
>> The current thinking is to split the work into two documents - one that
>> specifies extensions to triggers v2, and the other that pertains to cache
>> management specific metadata and related API.
>>
>> If so, would it make sense to incorporate the triggers v2 changes into
>> the current draft - all or some of them, or introduce them as a separate
>> document?
>>
>> The proposed triggers v2 change scope is as follows:
>> 1. New trigger extension PrepositionPolicy, per paragraph 8 of CDNI CI/T
>> v2, governing prepositioning policies like retry, patrial retrieval,
>> preposition methods, concurrency and bandwidth, and use of CDNi metadata
>> 2. New trigger extension PurgePolicy, governing purge semantics
>> 3. New trigger extension CommonPolicy, governing trigger execution
>> priority and type of URLs referenced in triggers (published vs. cache-key
>> URLs)
>> 4. Changes to trigger extension TimePolicy (8.2 in CDNi CI/T v2), adding
>> trigger execution scheduling, based on JSON-based iCAL [RFC7265], allowing
>> specifying start, stop, recurrence, duration, timezone etc.
>> 5. Changes of new content.playlist trigger spec(7.5.1 in CDNi CI/T v2) to
>> content.objectlist spec, in conjunction of introducing new types of object
>> list, in addition to hls, dash and mss types per 7.5.2 in CDNi CI/T v2,
>> allowing specifying lists of objects for trigger in JSON-encoded and plain
>> text formats
>> 6. Changes to Trigger Status Resource v2 (6.1.3 in CDNi CI/T v2) to
>> specify objectlists that were derived from content.objectlist triigger spec
>> 7. Changes to error codes in Error v2 to support the new extension
>> functionality
>>
>> One possible option is to incorporate changes to existing objects (items
>> 4-7) in the current draft, and defer the new trigger extensions (1-3) to a
>> separate document.
>>
>> Sanjay, Kevin,
>> I would appreciate some time in the open mic section in Prague to talk
>> about this
>>
>> Kind regards
>> Alan
>>
>>
>>
>>
>> --
>>
>> Alan Arolovitch
>>
>> CEO, 2You IO
>>
>> *E* [e-mail] | *M* +1.617.8939400 <(617)%20893-9400> | *W*
>> www.2you.io
>>
>> Broadpeak, S.A. Registered offices at 3771 Boulevard des Alliés, 35510
>> Cesson-Sévigné, France
>> Trade Register: 524 473 063
>> This e-mail and its attachments contain confidential information from
>> Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only
>> for the person to whom it is addressed.
>> If you are not the intended recipient of this email, please notify
>> immediately the sender by phone or email and delete it. Any use of the
>> information contained herein in any way, including, but not limited to,
>> total or partial disclosure, reproduction, or dissemination, by persons
>> other than the intended recipient(s) is prohibited, unless expressly
>> authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy
>> laws, and is committed to the protection of personal data. Emails and/or
>> attachments thereof exchanged between us may include your personal data
>> which may be processed by Broadpeak and/or its affiliates according to
>> applicable privacy laws & regulations.
>> In compliance with Regulation (EU) 2016/679 (GDPR) and applicable
>> implementation in local legislations, you can exercise at any time your
>> rights of access, rectification or erasure of your personal data, as well
>> as your rights to restriction, portability or object to the processing.
>> For such purpose, or to know more about how Broadpeak processes your
>> personal data, you may contact Broadpeak by email [e-mail].
>> Local authority : Commission Nationale Informatique et Libertés (CNIL): 3
>> Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>>
>
>
> --
> *Jay Robertson*  CDN System Architect
> Qwilt | [e-mail] | qwilt.com
>