Re: [CDNi] CDNI Named Footprints - Comments

["Arolovitch, Alan (Contractor)" <[e-mail]>]

Nir,
Apologies for delayed response to this
Thanks for reviewing the draft


  1.  I am okay with allowing footprint value as an additive list, it's an omission on my part to not use it.

  1.  With regards to "footprint-source", it does make sense to call out the source of the value explicitly.
It is also relevant for any footprint type that is not IPv4/IPv6 CIDRs, because even BGP ASNs may require that.
I am not sure however that providing a single string as a source is sufficient.

There's body of work in IETF that addresses standardization of geolocation information, including
RFC8805 that defines a format for self-published IP geolocation feeds, and RFC9092 that addresses
how IP geofeeds could be aggregated and looked up, but falls short of defining a common way of accessing
IP geofeed registries.
It is therefore plausible for dCDN to self-publish a geofeed using the RFC8805 format, to enumerate its
networks and mark them up with country and sub-country codes, and define the footprint accordingly
country and country-code,  and refer to its definition.

I am therefore proposing the following syntax:

      "footprint-def": {
      "footprint-type": "countrycode",
      "footprint-source": {
            "footprint-source-type": "rfc8805",            
            "footprint-source-uri": "http://noc.ietf.org/geo/google.csv",
      }      
      "footprint-value": ["us", "ca"]
     }

      "footprint-def": {
      "footprint-type": "countrycode",
      "footprint-source": {
            "footprint-source-type": "private",            
            "footprint-source-id": "maxmind",
            "footprint-source-version": "latest"
      }      
      "footprint-value": ["us", "ca"]
     }

      The above doesn't address use of non-IP values in MEL expressions.


  1.  I am not sure I follow you here with regards to the resource footprints, could you please expand?
The way I read RFC8006 Appendix B is that the footprints can be used to describe distinct cache node resources within dCDN. I am unaware of a specific use case, where uCDN would make use of such information provided by dCDN.
At the same time, since footprints are such a basic data type, it makes sense to allow for future use cases, where dCDN would use the same format to publish referenceable footprint hierarchies for different purposes.

Kevin, Sanjay,

Please advise what would be the best next step with regards to the named footprints draft?
It appears to have expired.

There were concerns about the named footprints work being out of charter and/or overlap with ALTO work
I had participated in early P4P and ALTO work
My understanding is that ALTO provides a way to aid client-side request routing, by P2P applications (initially) and client based multi-CDN steering applications, allowing ISP/access providers to publish a structured client cache (or server-side) information on their network.
The named footprints address the reverse problem. dCDN publishes structured user (or client-side) information to aid server-side request routing and dCDN delegation.
Additionally, the named footprints information does not necessarily overlap with a specific access network. It likely does overlap in case of operator-based dCDN, however it is not the case of public CDN, that is prepared to serve off-network clients in a specific geography.
Is my understanding correct? Am I missing something?


Additionally, the current draft outlines several extensions to Metadata Expression Language, as initially proposed in https://datatracker.ietf.org/doc/html/draft-goldstein-cdni-metadata-model-extensions-02
What's the current status of this draft? Does it make sense to specify these extensions in this draft?

I plan to submit a follow-up draft before IETF 119, that would incorporate the above changes discussed with Nir, as well as support for push updates, requested in SVTA.  I would appreciate if you could address the above before that, so I can incorporate.

Kind regards,
Alan


________________________________
From: Nir Sopher <[e-mail]>
Sent: Saturday, July 29, 2023 4:22 PM
To: [e-mail] <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: [CDNi] CDNI Named Footprints - Comments

Hi Alan, Following the meeting last week, as well as going over the cdni-named-footprints draft, I think the "named footprint" would bring a significant improvement to the FCI. I have a few comments to be considered: 1. In the draft

Hi Alan,

Following the meeting last week, as well as going over the cdni-named-footprints draft, I think the "named footprint" would bring a significant improvement to the FCI.

I have a few comments to be considered:

1. In the draft the footprint objects examples include a single value as "footprint-value". The definition of "footprint-value" in RFC 8006 is of an additive list.
E.g.
{
   "footprint-type": "countrycode",
   "footprint-value": ["us", "ca"]
}
You might want to adopt this syntax

2. With regards to the "consistent datasource" section. Big like. I think that for country code coordinating the geo-ip db is done on bootstrap, but I never thought about the DBs versioning which complicates things significantly.
Yet, for backward compatibility, I would suggest moving the db identifier from the "footprint-value" to an optional "footprint-source" field
E.g. Instead of
"footprint-def": {
   "footprint-type": "countrycode",
   "footprint-value": ["maxmind-latest:us", "maxmind-latest:ca"]
}

Write
"footprint-def": {
   "footprint-type": "countrycode",
   "footprint-source": "maxmind-latest",
   "footprint-value": ["us", "ca"]
}

It might be less flexible, but more simple and backward compatible. If you need to join a few different sources, just use the "union" footprint type (now official with RFC 9388).

3. The "resource" based footprint is a gap that we may want to address already.
Please note that an FCI "capability" can be considered as a special type of "resource" (and vice versa). Meaning the gap can partially be closed within the current FCI structure, using "named capabilities" as resources - where a capability defined within the FCI can be later pointed at a footprint object of (new) type "capability".
This is just a direction that needs much further thought....

Have a great weekend,
Nir