Re: [dtn] BPbis rules for future extension blocks

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 23 November 2020 15:10 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924503A0FF1 for <dtn@ietfa.amsl.com>; Mon, 23 Nov 2020 07:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ericsson.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 00glMBEc6lf6 for <dtn@ietfa.amsl.com>; Mon, 23 Nov 2020 07:10:14 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80080.outbound.protection.outlook.com [40.107.8.80]) (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 E9D1E3A1021 for <dtn@ietf.org>; Mon, 23 Nov 2020 07:10:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nfVj3cC8hNDFApogcPva3TZ3RWmkCyrZ6YMbMJZjCDbthK/RnAvTSPZqyPC6zSpf4xAif103Y4W92Zn7S7Pq7AK7xHu/HfqCYnhqn9W+ZkyQXo4ZUAlR1agF6cvD5UHGrHKv3wXzJrI/RxHO440A4rVLr30g68YK07Kdk6AILAL/yneBpYdOoFvYWVPyUkRTqjvgbPnYqtHROqrF5VXmsYorQlx4NlwFBDNxlrgnUhUOOq5du/oT90x/OmZbEdzGA3aPdYkTwPJlINa7JFoNgu+zvIlKtgXoCqZMTt2n3Okp+mKr4U2h0mP92UFDu1dFaF33ekm18H7rec4990ZSXQ==
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=Z0wwr17/Nq6Afku3wl0liVBYwlwffVbM4iiKIksWUJw=; b=TuX5S+x2Ov4VszaRn5nRrXqOHy4iq18zFZx3QIFGwGtRZ+TkKZ114ZZtuU0ah3pYLvwkmgAr1h1adeHRs/MQysBibPIZ12oGbMwKLm7XrbbuxCeATgrC8cfAuKwkn9JrKjDK237ueTOenh3FSKfaKt0OIhTQVNgIlYpqdiHeV1nr1wExvEPqOQ5LnvG2RvNWeDKF8mQrS2jHQzhHjamNN3vlsCXi5hPUanfaFiuXLotLTcGWsejJoKLiu0IpA/KloWfsvmpqNiqLBT3FN5DZrifxYU/4ChRZ6WtsCinTUrSxmQY3XSLqJpEAzKKvxM3MqW2pQdm9LsufG/2WSz6qUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z0wwr17/Nq6Afku3wl0liVBYwlwffVbM4iiKIksWUJw=; b=b0Fwvpd2JX9FztYZAmMNkDjemML5pZfBUybAfLQr8f/GnBuVfB9XBG/aOoqVQYPpL5Hhzpwy8vrSLCiQKLezkRNV0qJT7iXnb9dEcFXeTQ62YQJKV+yyW2oWQIV49L3/1vAloV9aNIGn006iPKOmUEX5eRdsNvlnrObvBC2m/jY=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2457.eurprd07.prod.outlook.com (2603:10a6:3:74::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.18; Mon, 23 Nov 2020 15:10:06 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::f006:1e1e:83a1:e5d2]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::f006:1e1e:83a1:e5d2%7]) with mapi id 15.20.3564.035; Mon, 23 Nov 2020 15:10:06 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org" <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: BPbis rules for future extension blocks
Thread-Index: AQHWv003l8SJtEoS7kGU84euBT+wganRJHdggASvy5A=
Date: Mon, 23 Nov 2020 15:10:06 +0000
Message-ID: <HE1PR0702MB37723E63295CCFB354167AC895FC0@HE1PR0702MB3772.eurprd07.prod.outlook.com>
References: <a7ff8839c9715e8d08d4d3b68688e4e75cf09564.camel@ericsson.com> <26b1c1159d534da6891829edde5328ab@jpl.nasa.gov>
In-Reply-To: <26b1c1159d534da6891829edde5328ab@jpl.nasa.gov>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cd1c8024-941d-4109-5d37-08d88fc1dc6b
x-ms-traffictypediagnostic: HE1PR0701MB2457:
x-microsoft-antispam-prvs: <HE1PR0701MB2457B46B82F88A3AB670BA4395FC0@HE1PR0701MB2457.eurprd07.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: XZD5KyGocUMWkXQ0PnxhWUm1vKbZfuwv0A4xEJAQL18nadTbDMaQ6/ZfZaZCCu0i7ucaVprFwx1OL8B/9e8gkgrHkXxWaI91tQ0dFFsg5ToNPfS02qrE/cBBasCs2mdTzsy5mRCyA8bt2JSUJihRpxSIZwOxq4Ej5WFU8nuzLMoo8ORzRu9CF53vsXezlHV2pEQx/c8ph/miMSjfKQALBnCYk0UX4V5bvG+tQF0GSESZ1ZAewhSJLXuB8Wv+sRpEsPW6wsCmbxsdAWjw7Uunchb5/itV0VjEMbK/LplAZYeZhN3TBPQ/jgIhSHvlFzxuKlgHQZJTbS8/N61UCBfvDA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(39860400002)(346002)(396003)(136003)(2906002)(8676002)(83380400001)(8936002)(76116006)(186003)(33656002)(26005)(99936003)(86362001)(53546011)(6506007)(66946007)(110136005)(316002)(478600001)(66616009)(66446008)(55016002)(9686003)(52536014)(64756008)(44832011)(66556008)(7696005)(71200400001)(5660300002)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?aExyT2pZNVEvS0JyZWg5N3NNc2RJbHN1d3hDUzVFclpvSHB2YjE1VlpCWnBT?= =?utf-8?B?Z3NvOTFRWDN4M2hTZ2d4cDZybnpNc24rcitORkZHL0pqQVQ5QlhxbVVpUGkz?= =?utf-8?B?ejRyTmI1QU9icDljeGpMK2xIM3k4eDZBMC9BeHVuMzhJdlplREtUc0tybUh2?= =?utf-8?B?bW9IZWdRMmFZL3BRNDBpbmlNWk1ucTFCRU82bnJRSHN5ZG5DbUxCc3Jpejd5?= =?utf-8?B?Y3libjRRWXJxRDhwMTRGQ3JHeml5MHh5NmJrTmlXQ1BPTFZBZ2RNUks5MGl6?= =?utf-8?B?L1d2V3U2Rjh4SmxZdzUxRDIwNkpzSjFOVkpIMVIvRmlrL2tJUEhaODNkeXdV?= =?utf-8?B?ci96d01xY3JtQU04dzNOSXJiVW1rL0NoczNqR1o0MmlienhkUlowVEJtZjhj?= =?utf-8?B?Yk5wa0NFQkRwMGtyUWhoR0UxTHF1NWV4eFAzSlNINDl6Rmw5Y1Q2TWlreU1s?= =?utf-8?B?WnZoSGRpZ3Y2anRPUW1RRUFIUXdqN3JjVlVDSmEyMnpYbnB2aFBGYko3QU5B?= =?utf-8?B?K0JnSFFlZWZBWS9tbUMyVkI4RUY3WGUvY1JRZnBtSkRqSk9tVkx0R0hpcm9J?= =?utf-8?B?VzhTMUxmMnhBbmt5a0JwQWNVaGJCU3YxK0ZES2tIdjkwU2RCUHN4NzRhWUFJ?= =?utf-8?B?UkRQaURkYUZkOXN4NnBzU0JMbEU1T3NIZ1N1Y1U2THRQZjdmQStGVjNTZExH?= =?utf-8?B?Y2NGeG5IZXhQMDJGdUVLczIvS0h4K0FDcHcrZzJyVTFOMGdtc0drV0s3S0Jw?= =?utf-8?B?QTFOUFJTZ2lTUmJ6UHFUMEZxbzYwWkRLYWlvbEFiV09RYlRtdHhEdFk3Qnda?= =?utf-8?B?eFQyL2NkSnR3U1VqOG9kQlY5TzJueFFRUERWcG9rTkJ5YnZXQzU4SklCSzgv?= =?utf-8?B?T0hCdGl3YmNaa0RUVFh1UFl3R01NL2YrV1lNcjZpMUR2RWU0ZXRDZFBMQ1BN?= =?utf-8?B?UzB1VWVwemtDL1NRemVhdWoyMnJwOTVXbjJ5L0RpdnFSaVVJQ0pTbnhQYVZZ?= =?utf-8?B?RGlMLzJKcWhUUk5WM2plS041QzQzUU1DVUc0SGpadVQzNC9BdHFpWTA0Ukgv?= =?utf-8?B?YmVrVHc3blJyaGpqWEUrTXBpeC9oREg5b2lDbmYwOEYzYi8yWFVrVjRQcjJs?= =?utf-8?B?blY0T3JUc1hxaXRhcHRIelo3aUU1OGFLb1FCOFQ4YVdVYnI1OHRmMUFhVDd6?= =?utf-8?B?NFR0YThUZjhrR3R6WTZ3RkxSL0lwQ3pMSi85RzVBclduY1JVRHh2YnZ0ZTVv?= =?utf-8?B?a2VuQ1kvWGFKRnUwRDFsb1p5WUhBUkJBMGhBQ0lTZzdKMG1zaVBNUThHK1lv?= =?utf-8?Q?8m7WA9iOTO2uQ=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_002C_01D6C1B3.19B5A610"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd1c8024-941d-4109-5d37-08d88fc1dc6b
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 15:10:06.1439 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DgtI+FAaMnOpVhmP1oUIjxdnqD34kkhtFbefMOTaoDiusVNpfYJfSsPzwMbuQEmCbvvhXdwj04rnbyzHsnsLfjZ5BJDUFxw/UOCnPGtp4RM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2457
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/GoVLqavXbiUOVCU6I9jDdKCxCbc>
Subject: Re: [dtn] BPbis rules for future extension blocks
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 15:10:23 -0000

Hi,

Scott, thanks for the text proposal. I am still thinking that the last 
paragraph of your proposals do raise the question if there is need to define a 
"MUST NOT be removed" flag for the block control flags. WG please think this 
over. I understand that there might not be any intermediate usage of this 
flag, but adding it later might be far from trivial.

Cheers

Magnus

> -----Original Message-----
> From: Burleigh, Scott C (US 312B)
> <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
> Sent: den 20 november 2020 17:01
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>om>; dtn@ietf.org
> Subject: RE: BPbis rules for future extension blocks
>
> Thanks, Magnus.  As a starting point for this discussion, here is the text 
> that I
> would propose to use in place of the current first paragraph of section 4.3:
>
> <start>
> "Extension blocks" are all blocks other than the primary and payload blocks.
> Three types of extension blocks are defined below.  All implementations of
> the Bundle Protocol specification (the present document) MUST include
> procedures for recognizing, parsing, and acting on, but not necessarily
> producing, these types of extension blocks.
>
> The specifications for additional types of extension blocks must indicate
> whether or not BP implementations conforming to those specifications must
> recognize, parse, act on, and/or produce block of those types.  As not all
> nodes will necessarily instantiate BP implementations that conform to those
> additional specifications, it is possible for a node to receive a bundle 
> that
> includes extension blocks that the node cannot process. The values of the
> block processing control flags indicate the action to be taken by the bundle
> protocol agent when this is the case.
>
> No mandated procedure in this specification is unconditionally dependent on
> the absence or presence of any extension block.  Therefore any bundle
> protocol agent MAY insert or remove any extension block in any bundle,
> subject to all mandates in the Bundle Protocol specification and all 
> extension
> block specifications to which the node's BP implementation conforms.  Note
> that removal of an extension block will probably disable one or more
> elements of bundle processing that were intended by the BPA that inserted
> that block.  In particular, note that removal of an extension block that is 
> one
> of the targets of a BPsec security block may render the bundle unverifiable.
> <end>
>
> Scott
>
> -----Original Message-----
> From: dtn <dtn-bounces@ietf.org> On Behalf Of Magnus Westerlund
> Sent: Friday, November 20, 2020 6:56 AM
> To: dtn@ietf.org
> Subject: [EXTERNAL] [dtn] BPbis rules for future extension blocks
>
> Hi WG,
>
> So in the discussion of BPv7 Extension in todays meeting some people did
> draw some parallels to IPv6 Extension headers. Ben Kaduk reminded me that
> there is one important aspect of that discussion that can hint at an issue. 
> If
> you are following 6man and/or Spring WG you would know about the big
> discussion related to addition and removal of some IPv6 extension headers
> by anything other than the endpoints that IPv6 Segment routing proposal has
> caused.
>
> So the existing Extension headers are all being changed interally and at 
> least
> "received from" will be added by a forwarder which isn't the originating
> endpoint.  So the question to the WG and especially the authors. Is it 
> really
> clear that Extension bundle blocks MAY be added by any node? Which nodes
> MAY remove a Extension bundle block? What controls if a Extension Bundle
> Block can be removed by an intermediate node. I do note taht the Block
> Processing Control Flags do not have a flag for "MUST NOT be removed, even
> if not understood".
>
> I would encourage the WG to think if there need to be any clarification of 
> this
> now. If we are missing a control flag I think it is easier to add it now. 
> Also to
> clarify what the general rules are for Extension Blocks so that this 
> discussion
> don't show up a bit down the line here.
>
> Cheers
>
> Magnus
>