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

[Nir Sopher <[e-mail]>]

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