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

Guillaume Bichot <Guillaume.Bichot@broadpeak.tv> Mon, 11 January 2021 22:35 UTC

Return-Path: <Guillaume.Bichot@broadpeak.tv>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80623A140A for <cdni@ietfa.amsl.com>; Mon, 11 Jan 2021 14:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.657
X-Spam-Level:
X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadpeakshare.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmbNjqw78SIu for <cdni@ietfa.amsl.com>; Mon, 11 Jan 2021 14:35:52 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40119.outbound.protection.outlook.com [40.107.4.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2DD3A1405 for <cdni@ietf.org>; Mon, 11 Jan 2021 14:35:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jc4+tzrVMyP2XGEEr9Hh3OWxZvhX/GtUKG+2APf0pljoactXfkvInpblmpw9gb3plNLd6nHti5U+2HBYiMPRhXOIkbt1D2p6hbHvsHmmm/c1zv89wssQU3Lc7tlG+JVIKcbCJjIgdmeWQ0OsT+oos04KD3UbItu619BBknKXJYNSrLMSLYLhph52RMBWPZHP74EhRt/Ky1rgFHB5gKzAAGK3Vco6SSXJwoU/ikqvCSKFOtE4l2V3T4257rSBvcuGbH0DemubGUTUTmq6uemFWmBH1WSh45TuZSA4+h0y+VfbjEo/3Y1WGE/lkkIZ1qtyZvxCRUY4iPR2lQZQgq2+JA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1U+8OTzFk88qsMdOVPkKmclwIOLEmZHJoiGRsVj38b8=; b=U534XDojbwPzPS6uP+xNAX/SYhNGP3eO8NnXUGh2tos+QYMzoPdakHlaqUFqMC1+yRElNS3DIubUldG1v+uIOZoUyeesGwfVEWGFKvmd3s1OxQBjfAYkb5cFBItCHbv4saAQ0HbNnVFL+Y9Wz8qbOQi4n2y+4Ct0oVZXAnoDmduqLMJEyAoI1FEVe7Oi4D82Er+woe0Mz0s2YPwDw4eYtrhUdM2YdMY0mqdkLekP/wvDUBg2y1D0tPO+L7jLyb1gv8IcLyib1RgOreUeWYmxH62NrSqEeSdMneomNOck7dBxtdJRJHOnggtrmsZtYYtvMOXxDRCWW0gDx+kjoNZdjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=broadpeak.tv; dmarc=pass action=none header.from=broadpeak.tv; dkim=pass header.d=broadpeak.tv; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadpeakshare.onmicrosoft.com; s=selector2-broadpeakshare-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1U+8OTzFk88qsMdOVPkKmclwIOLEmZHJoiGRsVj38b8=; b=fSur502iNvV6Kk35FSIVfPr17lxX3ij5rmZDxVrN0/2PweVJCF9WQeBUa9uKdDUCF2GyAvtwkuXgYHaBCdpxGopAVXEuvYQXf9Gz5VS5Y/Syh+pKkyzpAkITcJUtgYbFUTSXRrIAGo8u3figEK2OKBVCbWOZu/bbrBQ2W0o3B4Q=
Received: from PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:96::6) by PR3PR10MB3883.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:40::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 22:35:48 +0000
Received: from PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM ([fe80::d4a4:28e4:4e6d:afa0]) by PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM ([fe80::d4a4:28e4:4e6d:afa0%5]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 22:35:48 +0000
From: Guillaume Bichot <Guillaume.Bichot@broadpeak.tv>
To: Nir Sopher <nirs@qwilt.com>, Kevin Ma <kevin.j.ma.ietf@gmail.com>
CC: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions
Thread-Index: AdbaJFhYCZ8Eh0AgSD253QQBmUr/JQNeLJ6QABBbpwAAFq0MgAAJIXDQ
Date: Mon, 11 Jan 2021 22:35:48 +0000
Message-ID: <PR3PR10MB4239287F95B7E3BA38614EAAE1AB0@PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM>
References: <97e045b4b8ae42738a43f3dc0e3e1ca1@tbwexch02apd.uswin.ad.vzwcorp.com> <PR3PR10MB4239816DC20211300DC4EE49E1AC0@PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM> <CAMrHYE2QM8+G2Z0BJ5O3iLej7qsxB_ZWY_8G9jHsrwVX0-1u8w@mail.gmail.com> <CA+ec=9paJQYpTQRc9v7C_WqekynApA-mNY90746uXc+_+mHs-g@mail.gmail.com>
In-Reply-To: <CA+ec=9paJQYpTQRc9v7C_WqekynApA-mNY90746uXc+_+mHs-g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: qwilt.com; dkim=none (message not signed) header.d=none;qwilt.com; dmarc=none action=none header.from=broadpeak.tv;
x-originating-ip: [109.190.30.25]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f201807-a17a-425a-c5db-08d8b6813e51
x-ms-traffictypediagnostic: PR3PR10MB3883:
x-microsoft-antispam-prvs: <PR3PR10MB3883B67BAEAEE9218567C613E1AB0@PR3PR10MB3883.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X+yzaXYC2DDECZvnawaBgMfFQy4YoiztPY7LRKkijCD7HFdvvfS0ZtxMh+KJU03EtWKhUSBNleMPRJHjhirh47H8zzg4QEhVT6pJLGapRq6EScB5POtsIUvQJvoImlEoYQ4ukzK9uB1odOEh6Zp+LfqztbCnjn8iEi5QO+lbS2u5o0P53VE8XQ6RoQmoC+szPskq/5WvjZ3vh8LSB+GK3CwVR00W7XLdz6invb/+d/pPo9B5n3iHwGFuU+8KFTaR2eHM68TNCOWtiXKVZ3dL40xwQ+ld+auiJyN5RlsGpF+UgCS7EL7bW3bKPMxDJIpdNwQ4zxlJVRgAna4Fjo6Y6q5QZiDCBdEKTagKdMdvLX7hRcDgpl/sdGQG55HAPP4yg+RKiyw/gE8TD6rSrAAtlvU/3FngoSkA8CGaOLvqavQCR0xPHal+qyRTW+zM6bYz5TcLrjAiC94pbzqPXh9VjA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(376002)(366004)(136003)(346002)(396003)(2906002)(186003)(66574015)(52536014)(966005)(66946007)(6506007)(478600001)(8676002)(9326002)(55016002)(71200400001)(5660300002)(166002)(55236004)(53546011)(33656002)(64756008)(8936002)(76116006)(110136005)(66556008)(66446008)(4326008)(316002)(9686003)(66476007)(86362001)(26005)(7696005)(83380400001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: UaZGvq62bojFKC5tN0t0axuk9goEFc+aS+rqTYnmwqgdsHEpX8Ls0ea/XRvdQPt6+dWOfJPdzVJJ670vY8E+HguVRC2xgPKJkjNbXOp7IMxYahs/eyNkbOsZWfheSumBwzTrrvD+P5ROjSwobdakHPkaO/RyZTrWAnDfNsFT+JhyWQEFqx2jsR+KXomhsWrG/b/BlZpnmnQqqJ76a29B1gDtO0YcSLLMw3yHaFPKcvGhQh2lCisg5DXkr4Sl0bZxKUp6fmQilskUCDm2F4Z804IoQgqSfMM7H77Nh0x2fHy49fyEu/unQ1MduhX9qE7x3r2yioUBhrPzSA8wVl3icjnBBDt0VXmZRiHrRxhtdBFPfE8kmb8wZKv9Qgkj3hgfYAV6rz1zWE3qmeATdkUF81U8Mx8ycgwNaI01MipmUz60ukvMnBXv7PWladw24pCJIXc87deam3XRMH/OuC2BCjDAi35Cmq6OX1Kei3W+PYPAZ3E3pniWoCSGmoY3A0PkHcgqjBoNgXX4/1BuFEwC/mREkZ+Hf3QrHQDd0No6OvF1dp9+byFG4A0/eEGgErFiQx4RmxUZOL2n989URcoI9tUcCa4n7MayseDvT268A0ABTJVUT2SWgG8dUXfOtZh/5292gja/sOdwQ9aPNhP8e7bIa7xsXXRr8OXJahbwLaPV8bq76z0HpwsRHau1oJ16isXCtE6Td6jnoAeS/aa9vxdSLFdMP1CWPZOOK1s0N4R5HAdXOW9aNWwrx961r8Z9hzT66jLUnxW73EB3jF304oszHLhjMoPabeQp9KaRrCCq9yFiG1Ky6RQ+fD5qiKIw45jNIZHig6uhWv89odSsab3v5YmpRlhzkZFMeMWdoPVX8B/VoRqyOqHBdO9gW3nc9U3mr6WTV5914Ax0vAl0n4tC9FRwrYpSHuoTpbv8ujGRt31OeZZGajWBfPApDGbNBBWsO7a7l+JOw5JorOAmDLprh5J59XInm2uLn8mMggE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PR3PR10MB4239287F95B7E3BA38614EAAE1AB0PR3PR10MB4239EURP_"
MIME-Version: 1.0
X-OriginatorOrg: broadpeak.tv
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f201807-a17a-425a-c5db-08d8b6813e51
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 22:35:48.4243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0ebe44ea-c9c9-438d-a040-7e699f358ed4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Q4wclRyAwjknnd0YvIAF8AsEGrXeUoj+sHKaRUz+0K8XW2e55dVXsTjs8/mKEiPyH1gmBLlzPrr2QIjkHd4Q+HsSorR3YXFf3DuWNrVn/Eo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR10MB3883
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/w5us9GLyxgtckZQsiBnKCFf4M6k>
Subject: Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2021 22:35:57 -0000

Hi Ni,
What your proposed below goes into the same direction that I thought of except that it brings changes in the protocol adding modifying the MI.Footprint object structure with this new footprint class. I proposed to just change the semantic without touching the syntax. So  I thought my proposal simpler to deal with.

However I realized that it is impossible to indicate two different IP address ranges/blocks, each constrained by a different geographical area or vice-versa.
So what we need is may be something like this.


         "footprints": [

             {

                 "footprint-ip-type": "asn",

                 "footprint-ip-value": ["17192"]

                  "footprint-geo-type": "iso3166code",

                 "footprint-geo-value": ["ny"]

             },

             {

                 "footprint-ip-type": "asn",

                 "footprint-ip-value": ["18345"]

                  "footprint-geo-type": "iso3166code",

                 "footprint-geo-value": ["wa",]

             }

         ]
May be this will never appear though and in that case I would favor an approach that not touch the existing syntax.


Guillaume

Guillaume BICHOT, Principal Engineer, Head of Exploration
+33 (0) 6 8559 7666 | guillaume.bichot@broadpeak.tv<mailto:guillaume.bichot@broadpeak.tv>
broadpeak


From: Nir Sopher <nirs@qwilt.com>
Sent: Monday, January 11, 2021 5:46 PM
To: Kevin Ma <kevin.j.ma.ietf@gmail.com>
Cc: Guillaume Bichot <Guillaume.Bichot@broadpeak.tv>; cdni@ietf.org
Subject: Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

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:

     *   ipv4cidr
     *   ipv6cidr
     *   asn

  1.  Footprint Class: geo
Grouped footprint-types:

     *   countrycode
     *   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 <kevin.j.ma.ietf@gmail.com<mailto:kevin.j.ma.ietf@gmail.com>> 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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ma-cdni-capabilities-04%23section-2&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473835824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=80AKZbxTCmE%2BEPJ9BS0nzyT5N67Kc0e3YMTZ3mvYte0%3D&reserved=0> and https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-3.2<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ma-cdni-capabilities-04%23section-3.2&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473845779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qu9p49G%2FgjUZL%2FbJyJHlZWmp07SWhTIDPYMPq3g2YjQ%3D&reserved=0> .)

  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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-sopher-cdni-footprint-types-extensions-01%23section-2.1&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473845779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WdTm35zpiWUOH9WPViA78UdJ8GcIqpCVYzh6zs%2BSgs%3D&reserved=0> ), 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/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcdni%2F3GVjUbBNsf2gV8fQUhcVBRID_mU%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473855737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cKgbpTM8n4dEa35J%2BIl9Xsl183pgqVU29Cs3exn4phE%3D&reserved=0> ).  All of the less relevant material was moved to appendices (per: https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcdni%2F2gLvfnlbpJjIo57bER72kIiSZsk%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473855737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9OE9ba%2F9GO2gOHYfVH%2FWUHEOSgrVwgoqGKAHN1WU4pY%3D&reserved=0> ).  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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-alto-cdni-request-routing-alto-14%23section-4.1&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9SyMTKHI9d8DN2HBKil1WDtiLVI79fe9E4m6kL2SkYk%3D&reserved=0> ).

  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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8008%23section-3&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86bPSFk1TbfWkKYZdkBkrd5yKd8RBD%2Bga8UnTzCHkU%3D&reserved=0> ), 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 <Guillaume.Bichot@broadpeak.tv<mailto:Guillaume.Bichot@broadpeak.tv>> 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<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.0%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qhDrJFd75ODqch9xfSl786j%2FU9jnxZaQXpijMMk7ulU%3D&reserved=0>", "192.0.2.1/24<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.1%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lBrFIWDHJA8xPSl2GCQOwTdpvdlP3MLPRwKTelQXZIA%3D&reserved=0>"]

"ipv4cidr", ["192.0.2.2/28<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.2%2F28&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s3kHyObYg4511FaZnuafGvrSGxOo22oeQkzbIjOBCFU%3D&reserved=0>"]

"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<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.0%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d01Jf1JDgKB8bmG9soVi6I6oBQpZK%2FOmc9tWGZjKNmo%3D&reserved=0>"]

"ipv6cidr", ["2001:db8::/32"]

-          "iso3166code", ["ca", "us-ny"]



Guillaume

Guillaume BICHOT, Principal Engineer, Head of Exploration
+33 (0) 6 8559 7666 | guillaume.bichot@broadpeak.tv<mailto:guillaume.bichot@broadpeak.tv>


From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Nir Sopher
Sent: Wednesday, December 23, 2020 6:19 PM
To: cdni@ietf.org<mailto:cdni@ietf.org>
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%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473885602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MlGQ01iXtJTpEtAq%2BYBBKioAXJ8LP93cPjv5RUN2IKE%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
CDNi@ietf.org<mailto:CDNi@ietf.org>
https://www.ietf.org/mailman/listinfo/cdni<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473885602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=83I1fHiglY1ep%2BLAllbVfNpUNqUduGNCkv19G2iuV7M%3D&reserved=0>
_______________________________________________
CDNi mailing list
CDNi@ietf.org<mailto:CDNi@ietf.org>
https://www.ietf.org/mailman/listinfo/cdni<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473895560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XDmIu2LYZkGwG81pOrJPLct3tO%2BN7Xf3wxdWT%2FZ40Q4%3D&reserved=0>