Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

[Kevin Ma <[e-mail]>]

Hi Nir,

  (As an individual) I think both items in the draft seem straightforward
and reasonable.  My only comment is that I might consider changing
"footprintobject"
to "footprintunion" to make the intent more obvious.

thanx.

--  Kevin J. Ma

On Fri, Jul 2, 2021 at 7:52 AM Nir Sopher <[e-mail]> wrote:

> Hi,
>
> I prepared an additional draft (
> https://datatracker.ietf.org/doc/html/draft-sopher-cdni-footprint-types-extensions-03),
> allowing the resolution of the ipv4/v6 issue discussed earlier.
> A reminder: a footprint object has a "type" and a "value" list of elements
> of this type - in order to satisfy the term, the client needs to match one
> of the values in the list.
> So in the new draft I suggested to have a new footprint type of type
> "footprint object" - allowing the composition/aggregation of a several
> footprint objects into one.
> See examples in the draft.
>
> https://datatracker.ietf.org/doc/html/draft-sopher-cdni-footprint-types-extensions-03#section-2.2.2
>
> I know it sounds a bit awkward, and I would appreciate your thoughts and
> suggestions to refine this concepts.
>
> Thanks,
> Nir
>
>
>
> On Sat, Feb 20, 2021, 18:47 Nir Sopher <[e-mail]> wrote:
>
>> Thank you for your reply.
>> The need to specify both ASN and a location comes from the usecase of a
>> federation of ISPs serving as a dCDN. In such a scenario we need to specify
>> both the ASN and the location especially in cases of trials, a gradually
>> built coverage within an ISP, and (maybe in the future) capacity indication.
>>
>> I'll create a new draft with the suggested "union" footprint type so we
>> can further discuss it.
>>
>> Thanks,
>> Nir
>>
>>
>> On Mon, Feb 15, 2021, 03:55 Kevin Ma <[e-mail]> wrote:
>>
>>> Hi Nir,
>>>
>>>   Thanks for the explanation.  Is the ASN not inherent?  Is it the case
>>> that the uCDN has multiple dCDNs in NY, each in different ISPs, but all
>>> using the same hostname, and would like to redirect traffic for a specific
>>> ISP to a specific dCDN in NY and cannot otherwise segregate the
>>> configuration by hostname?
>>>
>>>   It seems like there should be another way around this.  Determining
>>> the intersection of an ASN and geographic area just seems like an odd thing
>>> for a uCDN to know how to do?
>>>
>>>   But, to your original question, I would say, yes, we would probably
>>> want a new footprint type for that.
>>>
>>> thanx.
>>>
>>> --  Kevin J. Ma
>>>
>>> On Wed, Jan 27, 2021 at 12:59 AM Nir Sopher <[e-mail]> wrote:
>>>
>>>> Hi Kevin,
>>>>
>>>> We encountered use cases that require intersection of footprint types
>>>> mainly between ASNs and ISO-3166 codes.
>>>> E.g. when a federation of dCDNs, would like to provide a
>>>> footprint object that covers a certain ISP in the state of NY.
>>>> This may be due to partial coverage of the ASN with cache nodes.
>>>>
>>>> If for example an ISP (dCDN) deployed nodes only in NY, we would like
>>>> the uCDN delegate only NY clients to the ISP dCDN.
>>>>
>>>> Another example for tthe need to use an intersection of ASNs and Geo
>>>> info is when discussing capacity indication (discussed on another thread).
>>>> The capacity is associated with a specific location within the ASN.
>>>>
>>>> One may argue that this can just be done using a list of the relevant
>>>> IPs, but it is not always the case, mainly as many uCDNs do not support
>>>> delegation based on IP list while they do support delegation based on
>>>> ASN/Geo.
>>>> Furthermore, in a DNS based delegation, where the name-server CNAMEs
>>>> the queried hostname to a dCDN target hostname, the client IP is not even
>>>> available to the uCDN at the delegation decision point.
>>>>
>>>> Thanks,
>>>> Nir
>>>>
>>>>
>>>> On Mon, Jan 25, 2021, 06:52 Kevin Ma <[e-mail]> wrote:
>>>>
>>>>> Hi Nir,
>>>>>
>>>>> > 1. Remove the narrowing semantics comment from the appendix (just
>>>>> write in the new rfc that it should be disregarded?)
>>>>>
>>>>>   I'm not sure we need a rewrite of the RFC.  I think if we wanted, we
>>>>> could file an errata to clarify the appendix text.
>>>>>
>>>>> > 2. Define a new footprint type: intersection  (name: tbd)
>>>>>
>>>>>   Is there a use case that requires intersection of footprint types
>>>>> for capability advertisement? It's not clear to me when intersecting a
>>>>> country code with an IP address range would be needed?  The implication is
>>>>> that some of the IP address range is outside the country while some is
>>>>> within, or that they can move between countries, and that we don't know
>>>>> which IP addresses are outside the country, but we would somehow be able to
>>>>> determine that later when the request is processed?  Is this to deal with
>>>>> VPN/tunneling detection?  That seems more like an ACL issue, than a
>>>>> capabilitiy advertisement issue?
>>>>>
>>>>> thanx.
>>>>>
>>>>> --  Kevin J. Ma
>>>>>
>>>>> On Wed, Jan 13, 2021 at 1:33 AM Nir Sopher <[e-mail]> wrote:
>>>>>
>>>>>> Thanks Kevin,
>>>>>>
>>>>>> I'll summarize your suggestion as I understand it.
>>>>>> You suggest to
>>>>>> 1. Remove the narrowing semantics comment from the appendix (just
>>>>>> write in the new rfc that it should be disregarded?)
>>>>>> 2. Define a new footprint type: intersection  (name: tbd)
>>>>>>
>>>>>> So if we want to point at ips 1.2.3.0/24 and 2001:db8::/32 only in
>>>>>> the US we would like to intersect
>>>>>> "footprints": [
>>>>>>     {
>>>>>>         "footprint-type": "iso3166code",
>>>>>>         "footprint-value": ["us"]
>>>>>>     }
>>>>>> ]
>>>>>>
>>>>>> with
>>>>>> "footprints": [
>>>>>>     {
>>>>>>         "footprint-type": "ipv4",
>>>>>>         "footprint-value": ["1.2.3.0/24"]
>>>>>>     },
>>>>>>     {
>>>>>>         "footprint-the type": "ipv6",
>>>>>>         "footprint-value": ["2001:db8::/32"]
>>>>>>     }
>>>>>> ]
>>>>>>
>>>>>> To create:
>>>>>> "footprints": [
>>>>>>     {
>>>>>>         "footprint-type": "intersection",
>>>>>>         "footprint-value": [
>>>>>>             [
>>>>>>                 {
>>>>>>                     "footprint-type": "iso3166code",
>>>>>>                     "footprint-value": ["us"]
>>>>>>                 }
>>>>>>             ],
>>>>>>             [
>>>>>>                 {
>>>>>>                     "footprint-type": "ipv4",
>>>>>>                     "footprint-value": ["1.2.3.0/24"]
>>>>>>                 },
>>>>>>                 {
>>>>>>                     "footprint-the type": "ipv6",
>>>>>>                     "footprint-value": ["2001:db8::/32"]
>>>>>>                 }
>>>>>>             ]
>>>>>>         ]
>>>>>>     }
>>>>>>
>>>>>> What would you say about keeping the narrowing semantics and define a
>>>>>> "union" (name: tbd) instead?
>>>>>> It feels more natural to me, and it does not break the definitions
>>>>>> done in RFC-8008 which might have came from a deeper discussion you had
>>>>>> back then.
>>>>>>
>>>>>> "footprints": [
>>>>>>     {
>>>>>>         "footprints": [
>>>>>>             {
>>>>>>                 "footprint-type": "iso3166code",
>>>>>>                 "footprint-value": ["us"]
>>>>>>             },
>>>>>>             {
>>>>>>                 "footprint-type": "union",
>>>>>>                 "footprint-value": [
>>>>>>                     {
>>>>>>                         "footprint-type": "ipv4",
>>>>>>                         "footprint-value": ["1.2.3.0/24"]
>>>>>>                     },
>>>>>>                     {
>>>>>>                         "footprint-the type": "ipv6",
>>>>>>                         "footprint-value": ["2001:db8::/32"]
>>>>>>                     }
>>>>>>                 ]
>>>>>>             }
>>>>>>         ]
>>>>>>     }
>>>>>>
>>>>>> Thanks
>>>>>> Nir
>>>>>>
>>>>>> On Wed, Jan 13, 2021, 06:19 Kevin Ma <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Nir,
>>>>>>>
>>>>>>> > Note that the footprint types are also used by the CDNI Metadata
>>>>>>> LocationACL objects
>>>>>>> <https://tools.ietf.org/html/rfc8006#section-4.2.2.2>, where IIUC
>>>>>>> the list of objects is considered as a set.
>>>>>>>
>>>>>>>   Correct.  In RFC8006 section 4.2.2.1, the footprint list is
>>>>>>> treated as a cumulative list.  I would expect the same to be true of the
>>>>>>> footprint list in the FCI base advertisement object (in section 5.1 of
>>>>>>> RFC8008).  So, the example in section 2.1 of your draft:
>>>>>>>
>>>>>>>     [{"footprint-type": "ipv4cidr","footprint-value": ["192.0.2.0/24
>>>>>>> "]},
>>>>>>>
>>>>>>>   {"footprint-type": "ipv6cidr","footprint-value": ["2001:db8::/32"]}]
>>>>>>>
>>>>>>>
>>>>>>>   would cover the union of the ipv4 and the ipv6 prefixes, not the
>>>>>>> intersection.
>>>>>>>
>>>>>>>   If you wanted to create more complex multi-footprint-intersection
>>>>>>> rules, that could be done by implementing a custom footprint type with the
>>>>>>> intersection rules clearly defined.
>>>>>>>
>>>>>>> thanx.
>>>>>>>
>>>>>>> --  Kevin J. Ma
>>>>>>>
>>>>>>> On Tue, Jan 12, 2021 at 7:25 AM Nir Sopher <[e-mail]> wrote:
>>>>>>>
>>>>>>>> Hi Kevin and Guillaume,
>>>>>>>>
>>>>>>>> I did not intend to change the footprint objects. I assume we can
>>>>>>>> just specify in the new RFC the class of each type and the semantic would
>>>>>>>> apply on the current syntax.
>>>>>>>> If we make changes in the syntax, we can do it simply by defining
>>>>>>>> the footprints in 2 layers. For example:
>>>>>>>> "footprints": [
>>>>>>>>     [
>>>>>>>>         {
>>>>>>>>             "footprint-type": "iso3166code",
>>>>>>>>             "footprint-value": ["ca", "us-ny"]
>>>>>>>>         }
>>>>>>>>     ],
>>>>>>>>     [
>>>>>>>>         {
>>>>>>>>             "footprint-type": "ipv4",
>>>>>>>>             "footprint-value": ["1.2.3.0/24"]
>>>>>>>>         },
>>>>>>>>         {
>>>>>>>>             "footprint-the type": "ipv6",
>>>>>>>>             "footprint-value": ["2001:db8::/32"]
>>>>>>>>         }
>>>>>>>>     ]
>>>>>>>> ]
>>>>>>>>
>>>>>>>> The semantic would be considering the inner lists objects as sets,
>>>>>>>> and then narrowing the outer list results.
>>>>>>>> This would not force us to define the class of each type.
>>>>>>>>
>>>>>>>> The change I describe above can be valid to all FCI implementations.
>>>>>>>> Note that the footprint types are also used by the CDNI Metadata
>>>>>>>> LocationACL objects
>>>>>>>> <https://tools.ietf.org/html/rfc8006#section-4.2.2.2>, where IIUC
>>>>>>>> the list of objects is considered as a set.
>>>>>>>>
>>>>>>>> WRT the ALTO PID, I'll need to look deeper into it
>>>>>>>>
>>>>>>>> Nir
>>>>>>>>
>>>>>>>> On Tue, Jan 12, 2021 at 5:51 AM Kevin Ma <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Nir,
>>>>>>>>>
>>>>>>>>> > IIUC, this would weaken the protocol:
>>>>>>>>>
>>>>>>>>>   Again, just to be clear, the FCI semantics RFC was never
>>>>>>>>> intended to define a "protocol".  The purpose was only to define a common
>>>>>>>>> message format.  It is arguable whether the interpretation of the footprint
>>>>>>>>> list entries should be protocol specific, but I think we can infer that we
>>>>>>>>> felt such interpretations were protocol specific and thus beyond the scope
>>>>>>>>> of the FCI semantics RFC.  We probably could've made that more clear, but
>>>>>>>>> again, hindsight.
>>>>>>>>>
>>>>>>>>> > define now a "footprint object class", grouping the "footprint
>>>>>>>>> object types"
>>>>>>>>>
>>>>>>>>>   wrt the grouping proposal, it is not clear to me that there is a
>>>>>>>>> natural grouping for footprint types or how future footprint types would be
>>>>>>>>> matched to a group, .e.g., should asn always be combined with ipv4/ipv6,
>>>>>>>>> and why not combine IPs with countries?  There will likely always be
>>>>>>>>> counter examples where a fixed grouping doesn't fit a certain scenario or
>>>>>>>>> there is a difference of opinion on what the natural groupings should be.
>>>>>>>>> These are the types of things we were trying to avoid in defining a generic
>>>>>>>>> message envelope and wanted to delegate to protocol implementation specs
>>>>>>>>> (e.g., the altopid footprint type solves the ipv4/ipv6 problem for the ALTO
>>>>>>>>> FCI implementation,
>>>>>>>>> https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>>   Would the intent here be to enforce a grouping proposal on all
>>>>>>>>> FCI implementations?  Or is there a specific FCI protocol you have in
>>>>>>>>> mind?  Is SVA intending to use ALTO for FCI?
>>>>>>>>>
>>>>>>>>> thanx!
>>>>>>>>>
>>>>>>>>> --  Kevin J. Ma
>>>>>>>>>
>>>>>>>>> On Mon, Jan 11, 2021 at 11:45 AM Nir Sopher <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Guillaume and Kevin,
>>>>>>>>>>
>>>>>>>>>> Indeed, disregarding the statement in the appendix would
>>>>>>>>>> negate the need for the ipv4v6cidr.
>>>>>>>>>> However, IIUC, this would weaken the protocol:
>>>>>>>>>> Take for example an integration where we would like the footprint
>>>>>>>>>> to cover only clients within a Europe wide spread ASN, but only in Belgium,
>>>>>>>>>> or only the NY clients of a US-wide ASN. The protocol when disregarding the
>>>>>>>>>> "narrowing semantics" statement would not be able to specify it (while in
>>>>>>>>>> the original semantics it is definable).
>>>>>>>>>>
>>>>>>>>>> One can argue we need to be able to create some boolean
>>>>>>>>>> expression. ORing and ANDing footprints.
>>>>>>>>>> I think a better approach (Guillaume, it might be the direction
>>>>>>>>>> you were pointing at), is to define now a "footprint object class",
>>>>>>>>>> grouping the "footprint object types"
>>>>>>>>>>
>>>>>>>>>>    1. Footprint Class: ip
>>>>>>>>>>    Grouped footprint-types:
>>>>>>>>>>       1. ipv4cidr
>>>>>>>>>>       2. ipv6cidr
>>>>>>>>>>       3. asn
>>>>>>>>>>    2. Footprint Class: geo
>>>>>>>>>>    Grouped footprint-types:
>>>>>>>>>>       1. countrycode
>>>>>>>>>>       2. iso3166code
>>>>>>>>>>
>>>>>>>>>> When a footprint objects list is composed from
>>>>>>>>>> multiple footprint-object classes, we should first merge objects from the
>>>>>>>>>> same class as a "set", and then use the original narrowing semantics
>>>>>>>>>> between the classes.
>>>>>>>>>>
>>>>>>>>>> This approach would solve the issue and would align with the
>>>>>>>>>> original semantics in most cases, but would also avoid the "absurd result".
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>> Thanks,
>>>>>>>>>> Nir
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 11, 2021 at 7:56 AM Kevin Ma <
>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>>   It's been a while since we had the FCI debates, and FCI has a
>>>>>>>>>>> rather complex history, so I've had to refresh my memory.
>>>>>>>>>>>
>>>>>>>>>>>   wrt the text in question: "Multiple footprint constraints are
>>>>>>>>>>> additive: the advertisement of different footprint types narrows the
>>>>>>>>>>> dCDN's candidacy cumulatively." I believe that statement was
>>>>>>>>>>> referring to if multiple FCI messages were sent for the same capability but
>>>>>>>>>>> the messages had different footprints in them; I do not believe it was
>>>>>>>>>>> intended to apply to multiple footprints in the same message.  (I believe
>>>>>>>>>>> it stemmed from a protocol implementation question for how to override
>>>>>>>>>>> footprints and how to deal with footprints in sequential messages, which I
>>>>>>>>>>> had addressed in my original capabilities protocol draft:
>>>>>>>>>>> https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-2
>>>>>>>>>>> and
>>>>>>>>>>> https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-3.2
>>>>>>>>>>> .)
>>>>>>>>>>>
>>>>>>>>>>>   In addition, I don't know that we should give any normative
>>>>>>>>>>> weight to a non-normative statement in an appendix.  As the draft points
>>>>>>>>>>> out (
>>>>>>>>>>> https://tools.ietf.org/html/draft-sopher-cdni-footprint-types-extensions-01#section-2.1
>>>>>>>>>>> ), applying the statement to the list of footprints in a single message
>>>>>>>>>>> produces an absurd result (i.e., disjoint footprints produce an empty set
>>>>>>>>>>> of footprints), and that was certainly not the intention (which I think we
>>>>>>>>>>> can infer from the prevention of such a result in the protocol drafts).
>>>>>>>>>>>
>>>>>>>>>>> > Frankly, this is very strange that the statement is almost
>>>>>>>>>>> hidden in a kind of annex  whereas it could have been located in section 5
>>>>>>>>>>> in a proper dedicated section.
>>>>>>>>>>>
>>>>>>>>>>>   Coming out of IETF 90 and 91, we had decided to focus the FCI
>>>>>>>>>>> semantics draft on just the information that needed to be advertised and
>>>>>>>>>>> separate out the protocol specifications (see:
>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/cdni/3GVjUbBNsf2gV8fQUhcVBRID_mU/
>>>>>>>>>>> ).  All of the less relevant material was moved to appendices (per:
>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/
>>>>>>>>>>> ).  In hindsight we probably could've done more to clean up the appendices,
>>>>>>>>>>> but as is always the case, we did not have the benefit of hindsight at the
>>>>>>>>>>> time.  The decision was made to rely on ALTO as a transport protocol, which
>>>>>>>>>>> defines its own footprint type and enforcement rules (see:
>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1
>>>>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>>   We probably also could have done more to specify the
>>>>>>>>>>> interpretation of the footprint list, but I think that was just delegated
>>>>>>>>>>> to the protocol specs.  At the time, there was contentious debate between
>>>>>>>>>>> advertising of footprints vs advertising of capabilities (thus:
>>>>>>>>>>> https://tools.ietf.org/html/rfc8008#section-3 ), and our focus
>>>>>>>>>>> was clarifying the advertisement of capabilities with footprint
>>>>>>>>>>> restrictions and completing the semantics draft so we could move forward
>>>>>>>>>>> with the protocol draft(s).
>>>>>>>>>>>
>>>>>>>>>>>   If folks feel strongly about the appendix being confusing, we
>>>>>>>>>>> could consider filing an errata?
>>>>>>>>>>>
>>>>>>>>>>> Sanjay/Nir,
>>>>>>>>>>>
>>>>>>>>>>>   If we disregard the statement in the appendix and assume that
>>>>>>>>>>> within a single message, multiple footprint types are allowed and are
>>>>>>>>>>> considered as a set, does that negate the need for the proposed ipv4v6cidr
>>>>>>>>>>> footprint type?
>>>>>>>>>>>
>>>>>>>>>>>   wrt the iso3166code footprint type, I don't see any issue
>>>>>>>>>>> with it if folks feel it would be useful.
>>>>>>>>>>>
>>>>>>>>>>> thanx!
>>>>>>>>>>>
>>>>>>>>>>> --  Kevin J. Ma
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jan 10, 2021 at 5:54 PM Guillaume Bichot <
>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Sanjay & Nir.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the  statement from 8008 (Appendix B) : Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively.
>>>>>>>>>>>>
>>>>>>>>>>>> Frankly, this is very strange that the statement is almost hidden in a kind of annex  whereas it could have been located in section 5 in a proper dedicated section.
>>>>>>>>>>>>
>>>>>>>>>>>> Your proposal solves the issue but not completely. I guess nothing prevent me to add several footprint constraints of the same type like the example below. Strictly speaking, if I captured well that statement, we should end up with an empty list as well.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>>      "capabilities": [
>>>>>>>>>>>>
>>>>>>>>>>>>        {
>>>>>>>>>>>>
>>>>>>>>>>>>          "capability-type": <CDNI capability object type>,
>>>>>>>>>>>>
>>>>>>>>>>>>          "capability-value": <CDNI capability object>,
>>>>>>>>>>>>
>>>>>>>>>>>>          },
>>>>>>>>>>>>
>>>>>>>>>>>>          "footprints": [
>>>>>>>>>>>>
>>>>>>>>>>>>              {
>>>>>>>>>>>>
>>>>>>>>>>>>                  "footprint-type": "ipv4cidr",
>>>>>>>>>>>>
>>>>>>>>>>>>                  "footprint-value": ["192.0.20/24"].
>>>>>>>>>>>>
>>>>>>>>>>>>              },
>>>>>>>>>>>>
>>>>>>>>>>>>              {
>>>>>>>>>>>>
>>>>>>>>>>>>                  "footprint-type": "ipv4cidr",
>>>>>>>>>>>>
>>>>>>>>>>>>                  "footprint-value": [["192.0.21/24"]
>>>>>>>>>>>>
>>>>>>>>>>>>              }
>>>>>>>>>>>>
>>>>>>>>>>>>          ]
>>>>>>>>>>>>
>>>>>>>>>>>>        }
>>>>>>>>>>>>
>>>>>>>>>>>>      ]
>>>>>>>>>>>>
>>>>>>>>>>>>    }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have another proposal  that is the following: instead of creating a new footprint type that requires a change in RFC8006 as well, why not just changing that statement that looks strange and almost faulty.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -remove that faulty statement in Appendix B.
>>>>>>>>>>>>
>>>>>>>>>>>> - create a new section 5.x about “footprints” and add a new statement (or just add that new statement in Appendix B) like the following:
>>>>>>>>>>>>
>>>>>>>>>>>> ”Several footprint constraints can be given of either the same type or not.   The uCDN MUST consider the resulting footprint as a set of geographical areas constrained with a set of IP address ranges if any. If several geographical areas overlap then the coverage zone corresponds to the cumulative areas.”
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Examples
>>>>>>>>>>>>
>>>>>>>>>>>> -          E1: a set of address ranges
>>>>>>>>>>>>
>>>>>>>>>>>> "ipv4cidr", ["192.0.2.0/24", “192.0.2.1/24”]
>>>>>>>>>>>>
>>>>>>>>>>>> “ipv4cidr”, [“192.0.2.2/28”]
>>>>>>>>>>>>
>>>>>>>>>>>> "ipv6cidr", ["2001:db8::/32"]
>>>>>>>>>>>>
>>>>>>>>>>>> -          E2: a set of geographical areas
>>>>>>>>>>>> "iso3166code", ["ca", us-ny]
>>>>>>>>>>>>
>>>>>>>>>>>> -          E3: a mixed of geographical areas and address ranges
>>>>>>>>>>>>
>>>>>>>>>>>> "ipv4cidr", ["192.0.2.0/24"]
>>>>>>>>>>>>
>>>>>>>>>>>> "ipv6cidr", ["2001:db8::/32"]
>>>>>>>>>>>>
>>>>>>>>>>>> -          "iso3166code", ["ca", “us-ny”]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Guillaume
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Guillaume BICHOT, **Principal Engineer, Head of Exploration*
>>>>>>>>>>>>
>>>>>>>>>>>> [phone] | [e-mail]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *From:* CDNi [mailto:[e-mail]
>>>>>>>>>>>> <[e-mail]>] *On Behalf Of *Nir Sopher
>>>>>>>>>>>> *Sent:* Wednesday, December 23, 2020 6:19 PM
>>>>>>>>>>>> *To:* [e-mail]
>>>>>>>>>>>> *Subject:* [E] [CDNi] New Internet Draft:
>>>>>>>>>>>> draft-sopher-cdni-footprint-types-extensions
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We have submitted draft-sopher-cdni-footprint-types-extensions
>>>>>>>>>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dsopher-2Dcdni-2Dfootprint-2Dtypes-2Dextensions_%26d%3DDwMFaQ%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DXniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM%26m%3DTs5uj_nZmoHgi7pPldjWKsDPgmeeiO_RkotsI8zZD-E%26s%3DoWZZ4TjWJsq7Ao899RmyOUwUgAjNYeVlksfkKAy-UeA%26e%3D&data=04%7C01%7Cguillaume.bichot%40broadpeak.tv%7Cf6b67a86cc4b44ff6b7a08d8a83b82a1%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637444320869999346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YxIzX3bst5GAicrOxFI%2BqfRZYO65%2Fwh07pDTwoYrrJg%3D&reserved=0>
>>>>>>>>>>>> that extends RFCs 8006/8008 in order to address the following issue:
>>>>>>>>>>>>
>>>>>>>>>>>>    - Sections 4.3.5 and 4.3.6 of [RFC8006] specify the
>>>>>>>>>>>>    "IPv4CIDR" and  "IPv6CIDR" footprint types, respectively, for listing IP
>>>>>>>>>>>>    addresses blocks.  Using Footprint Objects of these types, one can define
>>>>>>>>>>>>    an FCI Capability Advertisement Object footprint constraints that
>>>>>>>>>>>>    match IPv4 or IPv6 clients. Also as described in section 5 of RFC 8008, the
>>>>>>>>>>>>    FCI Capability Advertisement Object includes an array of such CDNI
>>>>>>>>>>>>    Footprint Objects. The array of Footprint Objects has a "narrowing"
>>>>>>>>>>>>    semantic that prevents the usage of IPv4/IPv6 objects together in order to
>>>>>>>>>>>>    create a footprint constraint that matches IPv4 clients together with IPv6
>>>>>>>>>>>>    clients.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In the submitted draft:
>>>>>>>>>>>>
>>>>>>>>>>>>    1. We add a new usecase of dCDN advertising a footprint
>>>>>>>>>>>>    that consists of both IPv4 and IPv6 client addresses, by defining a new
>>>>>>>>>>>>    "IPv4v6CIDR" Footprint Type.
>>>>>>>>>>>>    2. We also add support for ISO3166Code Footprint Type,
>>>>>>>>>>>>    based on ISO 3166 country codes and regions definition. This Footprint Type
>>>>>>>>>>>>    allows the dCDN to advertise a footprint based on a specific region, for
>>>>>>>>>>>>    example a state in the USA.
>>>>>>>>>>>>
>>>>>>>>>>>> We would highly appreciate it if folks can review and provide
>>>>>>>>>>>> any feedback.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks and Happy Holidays,
>>>>>>>>>>>>
>>>>>>>>>>>> Sanjay & Nir
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> CDNi mailing list
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> CDNi mailing list
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>>>>>>>
>>>>>>>>>>>