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

[Nir Sopher <[e-mail]>]

[Resending, with a clearer output examples]

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": "footprint-intersection",
            "footprint-value": [
                {
                    "footprints": [
                        {
                            "footprint-type": "iso3166code",
                            "footprint-value": ["us"]
                        }
                    ]
                },
                {
                    "footprints": [
                        {
                            "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 (I prefer ORs of ANDs vs. ANDs of ORs), 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 at 8: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
>>>>>>
>>>>>>