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

[Nir Sopher <[e-mail]>]

Hi all,

Following the discussion I just released a  v4 of the draft
<https://datatracker.ietf.org/doc/draft-sopher-cdni-footprint-types-extensions/04/>
-
moving from "FootprintObject" footprint-type to "FootprintUnion".

Best Regards,
Nir

On Tue, Jul 27, 2021 at 3:56 PM Kevin J. Ma <[e-mail]>
wrote:

> Hi Nir,
>
>   I think we want the names to be descriptive.  For the original types, it
> made sense to name based on content; for this, it may make more sense to
> name based on function.
>
> thanx.
>
> --  Kevin J. Ma
>
> Sent from my iPhone
>
> On Jul 27, 2021, at 3:12 AM, Nir Sopher <[e-mail]> wrote:
>
> 
> Thanks Kevin,
> I also don't like the name "footprintobject". Thought about "compound
> footprint".
>
> The issue however is that I tried to follow the same flow of defining
> other footprint elements.
> As I understand it, the "footprint type"  is a name (e.g. ipv4cidr,
> ipv6cidr, asn, countrycode) describing what kind of elements
> the "footprint-value" list is going to hold.
> In our case, the list is built of footprint-object to create a composition.
>
> Maybe I understand it wrong and the "footprint type" is the overall type
> of the footprint object and not of the individual elements within the value
> list?
>
> Nir
>
> On Tue, Jul 27, 2021 at 4:09 AM Kevin Ma <[e-mail]>
> wrote:
>
>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>