Re: What if? [was Re: Extension Header Insertion]

"Darren Dukes (ddukes)" <ddukes@cisco.com> Tue, 10 December 2019 22:04 UTC

Return-Path: <ddukes@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2EF120233 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 14:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SQN8CluJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0Qim5m8t
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 jK7b7nMAPvt9 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 14:04:14 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E7C1201EF for <6man@ietf.org>; Tue, 10 Dec 2019 14:04:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32449; q=dns/txt; s=iport; t=1576015454; x=1577225054; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JYKNma04Ri63oyEmWAXu04PbJgSC6Y/rqjxDXxk/kPQ=; b=SQN8CluJGnCIWfJvqO9yIKoBmNTTB0Gfm56Lw6g97XsEYBudhaGis57D 3oPYS++t3WZAmCi9EtRn5VgXZlDIyGfcpzGwE6YNCuBv0Orz6pHtc2kB9 OZRfU8FWiy5hZRh51vU8H9Zdp1yB7iQOt585zECcvT0rQDVpax8U8RKHh k=;
IronPort-PHdr: 9a23:Z5HlyRzS5E2HBwDXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuJBVD4IeXCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AuCwB0FfBd/4wNJK1lHQEBAQkBEQUFAYF+gRwvUAVsWCAECyqEA4NGA4sJjDqOK4FCgRADVAkBAQEMAQEYAQoKAgEBhEACF4FsJDgTAgMNAQEEAQEBAgEFBG2FNwyFXwIBAwEBEBEdAQEsCwEPAgEIEiYHAwICAh8GCxQDDgIEDgUigwABgXlNAy4BAgyjOAKBOIhhdYEygn4BAQWFGQ0LghcDBoE2jBgagUE/gREnIIJMPoIbSQEBgTwPRYJjMoIsjTqCboVTiVSOVkMKgi+MU4R9hCAbmjiZJo9VAgQCBAUCDgEBBYFpIoFYcBU7KgGCQVARFIxmCRqDUIUUhT90AYEni02CQQEB
X-IronPort-AV: E=Sophos;i="5.69,301,1571702400"; d="scan'208,217";a="390462031"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 22:04:12 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAM4CM6004210 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 22:04:12 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 16:04:12 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 16:04:11 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 17:04:11 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AH5ep8OmCyaBTOpqKwdpthH87p0f/YqGyXvCfvT/o33miws1LzlzYshcu5e8oHnzWBMVcYcdLy0W3muAuMSr1VbfT+f3H9sWPb85tAseuMNyoEmlJlgNfkC9WHE9NXyqMvaY7qfvHH6D0Oqv6ok1O6YigM1Xm8aMiMzh8lotPKJfoEo/T/bd4qUyo7Xnsi5DF+UKfMTCXdbbI0uJRqX8tKAMuY/rpCSZqsKw4eC0AuI53jDprfYMzBIBYI9aLvXUod93rjFh23/3EEsTVXn8rdO2npFncFnOiWKj1pKiMyjn+dKYOShzGBEzTYl+ZlxmND2XyHsdqhsGWcSpZ4bKDg==
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=JYKNma04Ri63oyEmWAXu04PbJgSC6Y/rqjxDXxk/kPQ=; b=SS7hGPHTYxGNvLqy0sjIrzRsbD3dP8VGEzCFuD0CJmNJ/fBDSVyPXskhy3Gcdc3bgO8pN5AJjte0BnID4iW2FMN8bvULPgCJE7zjpLFiN7+rOBnh1H6nDbLAfmM4NdgSf8azVEiQrwWB1MeRsF9ZKPL6ITbK/Rb3sfbqMnqR5XwH5yB6nuU6E2ZgAAoL1VIJXhiLJ8zHb+iyPdDgLrRYj2BSSrv8C/UHzfNOD9fh2+nsBYCqVYW0wkMNI0OIVSoWZistcusRH1RxPC3PP6GNEwq01TfJ192+8r2igkpN8qD58/d9W94ODM4JVyqYaSuvvgU1eJ95znLqZWuyE02keA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JYKNma04Ri63oyEmWAXu04PbJgSC6Y/rqjxDXxk/kPQ=; b=0Qim5m8tGnHsv87/u1eWCQfQQDpgeGyrCdPWFsYVwPl9vzzXXI7gLeQQ5l5pLt8oWaymN43A3K+vDlnIPlppTItlhr8BesfGyC3p0n1mvXFgDfWxtBuz07eKj2Hmz6jA/8OIejgEs/4uIHH/dSljzMFjM+zGQvrqZI4YBFbrn3M=
Received: from BN7PR11MB2594.namprd11.prod.outlook.com (52.135.246.159) by BN7PR11MB2739.namprd11.prod.outlook.com (52.135.252.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Tue, 10 Dec 2019 22:04:10 +0000
Received: from BN7PR11MB2594.namprd11.prod.outlook.com ([fe80::c72:fa12:757e:cca3]) by BN7PR11MB2594.namprd11.prod.outlook.com ([fe80::c72:fa12:757e:cca3%5]) with mapi id 15.20.2516.014; Tue, 10 Dec 2019 22:04:10 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Fernando Gont <fernando@gont.com.ar>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 6man <6man@ietf.org>
Subject: Re: What if? [was Re: Extension Header Insertion]
Thread-Topic: What if? [was Re: Extension Header Insertion]
Thread-Index: AQHVrvglDJogcV4Yl06htxW3YJv7vaezDKwAgAC1CYCAACvXAA==
Date: Tue, 10 Dec 2019 22:04:10 +0000
Message-ID: <A5439DC7-5B11-40E9-BC32-6E675E2EDC20@cisco.com>
References: <BN7PR05MB5699D9BA988F96E2F41CD390AE580@BN7PR05MB5699.namprd05.prod.outlook.com> <00dc01d5ae73$c361b450$4a251cf0$@olddog.co.uk> <dbcdeb1a-0091-da2b-20df-d991e6c06091@gmail.com> <9bc47200-4fea-37ce-0ede-cbf6a5f70ea9@gmail.com> <99e4bdd0-711d-7406-d3bf-786b0238c1e7@gont.com.ar> <44e6225f-97bc-37ba-c13e-b7bafa446fcc@gmail.com>
In-Reply-To: <44e6225f-97bc-37ba-c13e-b7bafa446fcc@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ddukes@cisco.com;
x-originating-ip: [2001:420:c0cc:1008::9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b9aaff74-0c36-4f72-fa0d-08d77dbce295
x-ms-traffictypediagnostic: BN7PR11MB2739:
x-microsoft-antispam-prvs: <BN7PR11MB2739264181A3F3A51D9A7FFFC85B0@BN7PR11MB2739.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39860400002)(199004)(189003)(478600001)(33656002)(66446008)(966005)(2616005)(2906002)(86362001)(6916009)(5660300002)(316002)(54906003)(6506007)(53546011)(186003)(71200400001)(66946007)(6486002)(8676002)(81166006)(91956017)(4326008)(6512007)(81156014)(64756008)(66556008)(66476007)(76116006)(8936002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2739; H:BN7PR11MB2594.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5BoApQpjwVkBMbiZt+L3tZnkye1PXOnB5cJm8X9yafEoOvoyGaW1NYkx7EFX+QLokDh1XMEtHl79IeQOrSaxVMmeDO//PbLMWqic2O9ZRyUkRGIrCC+Zx69yk4wy/DYAKLn2YZxJqiJrU2tPPlqvFwMYDetcFQcKuvH9p186PSI8mkVl3G758kITO3pSPCqhq+RHDDPMxC6ZDiBnmCrBMOASrYORG/fdepVAsd1H3uN0wEgfY701akd3uaonY1EJCE83mVp4XV48751ZrM9YJco8MzUPuqp8laF+0cGiS5FNg0Hm7gMCyVJGab+kJkofLJth/ILGx7CO0qtHP41is70fQHQFKPep+4UyupnXQNMn1+5EbXw4qqCxj2nTe+ed+F7TZM9VufubYMg7Jps82feez4xZjQYrfYbmLdPCGvVG9Ya+S8LXdXgYzFlVqbnjWiu2DRLTuvy+8H2BkgV80cm95tQ+YzuDAcYtQpzXOXY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_A5439DC75B1140E9BC326E675E2EDC20ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b9aaff74-0c36-4f72-fa0d-08d77dbce295
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 22:04:10.3408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: APkC4b66qzvnoMT++C/icVQNVvd2oAaLPJIp3D1/yH0i8JpEYyx3AFJFJmn1NSWvHtW4JEtWHelojHgukmPrHQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2739
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PGLx4rYHkkZWCLHu49nuatOsEkY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 22:04:17 -0000

Hi Brian.

I do believe that “assumption” you mention in draft-ietf-spring-network-programming is to be removed as a result of the last call discussion on spring@.

As I mentioned in a separate thread, RFC8200 states "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times”, the ‘assumption’ could been seen as a reminder of that requirement, but I don’t think thats necessary either.

There is no draft adopted by SPRING nor 6MAN that proposes multiple SRH be added to a packet.

If 6MAN intends to adopt a standards track definition of SRH insertion, then that document would need to fully describe the possible ramifications, including this one.  This we know, and are having much lively discussion on it.  I think we are safe to never have it ’sneak in’ without 6man having a say :)

Darren

On Dec 10, 2019, at 2:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:

Hi Fernando,

On 10-Dec-19 21:39, Fernando Gont wrote:
Hi, Brian,

On 9/12/19 20:21, Brian E Carpenter wrote:
So, let's assume that two consecutive SRH headers are allowed in the same packet.

Part of the problem with all these discussions is that folks seem to
assume that there is no rationale for the existing rules, and they
insist on changing them without providing any analysis/rationale.

RFC8200 contains what should be considered a recommendation (at the very
least) against multiple routing headers.


A RH is meant to convey some sort of information about the path that a
packet can traverse. So two SRHs would mean that the same packet should
follow two different paths, at the same time. That doesn't seem to be
much sense to me.

I agree. That's why I am seriously asking whether we should recall
draft-ietf-6man-segment-routing-header-26 from the RFC Editor in order
to resolve this. Either (a) there MUST be at most one SRH in a packet,
or (b) the semantics and conflict resolution for multiple SRHs need to
be specified.

At the moment we (6MAN) are on track to publish a Proposed Standard RFC
that leaves this ambiguous, and SPRING has a draft in WGLC that assumes (b).

  Brian




So the first one (an example from draft-ietf-6man-segment-routing-header-26) is:

      Segments Left=2
      Last Entry=2
      Flags=0
      Tag=0
      Segment List[0]=S3
      Segment List[1]=S2
      Segment List[2]=S1

and the second one is

      Segments Left=1
      Last Entry=1
      Flags=0
      Tag=0
      Segment List[0]=S4
      Segment List[1]=S5

I made that up and it's obviously nonsense, but if this is allowed why aren't the rules for processing conflicting SRHs described in draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the RFC Editor queue to be fixed?

It is clearly recommended against.

However, the very draft-voyer-6man-extension-header-insertion doesn't
even provide a rationale for EH insertion in the first place, let alone
for this specific case that you (reasonably) raise.

Unfortunately, when operating in a mode where analysis is discoraged,
and "why?" questions are dismissed, I'm not sure there is any other
possible alternative outcome than this -- documents with lots of
unspecified stuff, violating specs at will, and designs try to cover up
what seem to be sub-optimal design choices (like using 128-bit labels
for what are expected/supposed to be limited domains) by screwing up the
architecture to save bytes that were wasted elsewhere.

Thanks,


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------