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

[Nir Sopher <[e-mail]>]

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