Re: [CDNi] Cache management interface | Triggers v2

[Jay Robertson <[e-mail]>]

Hi Alan,

I believe I understand the challenges behind using ASNs to identify CDNs,
and I agree that it is not congruent with the needs of open caching.

I also recognize that this issue seems to go beyond the cdn-path and loop
detection, as the CDN PID is used for error propagation and trigger
collections.  This would seem to suggest that we need a suitable
replacement for the PID to fully solve this problem.  I also understand
that the issue of identification is being worked on in other WGs, but the
efforts that may help in this regard are not on a path to conclude before
the current Ci/T draft goes to last call.

After giving this some thought, a couple of potential solutions come to
mind:
1. Use registered domain names belonging to the CDN as a PID.  Unlike AS
numbers, every CDN in the path will have one and there should be no risk of
collision.  If a provider operates multiple independent CDNs, then they can
prepend an additional element to the domain name.
2. Use a UUID (RFC4122) as a PID.  A CDN could generate a UUID for each
independent system, and there would be an extremely low chance of collision.

Another thought would be to define a new set of constraints for a PID so
that a more flexible string can be used, which could accommodate different
means of identity in the future.  We can also continue allowing AS-based
PIDs to allow a v2 capable CDN to interoperate with one using v1 triggers.

Thanks,
- Jay


On Wed, Mar 6, 2024 at 9:19 AM Alan Arolovitch <[e-mail]> wrote:

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

-- 
*Jay Robertson*  CDN System Architect
Qwilt | [e-mail] | qwilt.com