Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

"Darren Dukes (ddukes)" <ddukes@cisco.com> Thu, 12 March 2020 06:22 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 BA8FB3A08AE; Wed, 11 Mar 2020 23:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.599
X-Spam-Level:
X-Spam-Status: No, score=-14.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OytXybMr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S58NMGdJ
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 bJyWXG1yko-J; Wed, 11 Mar 2020 23:22:22 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2276A3A10D9; Wed, 11 Mar 2020 23:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48439; q=dns/txt; s=iport; t=1583994142; x=1585203742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QROIZIYddFzygYO70eO/nQg3XuTwIxKoiJk+lMdH110=; b=OytXybMrHs/UmUTZbfyVSXpQjRI8U1aheFX7k8hBbEZ4wCxHnBJTmzJc 1fdQ3ES4G/6sviono+jw3VTrcOXcYOUefX2vt2nvHEiWyC2knCuFJBhTF yDpQAVBI2nHwtWicv0Lj7mLtHqtYrvoCMIKlbETmLiBcL/Up56AKjvo98 8=;
IronPort-PHdr: 9a23:UVw+0xcMAtMeT3HoGftg6UKmlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/YyAnH8lZfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DgBwCx1Gle/4kNJK1lHAEBAQEBBwEBEQEEBAEBgXuBJS8kLAVsWCAECyoKhAuDRQOKb4I6JYljjjKCUgNQBAkBAQEMAQEYAQUPAgQBAYRDAheBdiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECAQEBEBEdAQEsCwEECwIBCBEBAgEBASEBAgQDAgICHwYLFAMGCAIEAQ0FIoMEAYF9TQMOIAEOn3wCgTmIYnWBMoJ/AQEFgS8Bg1kNC4IMAwaBOIwsGoFBP4E4DBSCTT6BBIEXSQEBAoFRKQkNC4JZMoIsjXSCd4VzmRFECoI8h1aKXoQ4HYJKiCWQTIRKijSIfoIxkCUCBAIEBQIOAQEFgWkigVhwFTsqAYJBUBgNjh0MDAsVgzuFFIVBdAKBJ4wiAYEPAQE
X-IronPort-AV: E=Sophos;i="5.70,543,1574121600"; d="scan'208,217";a="445965913"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2020 06:22:19 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 02C6MJVv012339 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2020 06:22:19 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 01:22:18 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 02:22:17 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Mar 2020 02:22:17 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ey6OgjksatagHtQfep5tu0pnzXRWwtHvwf/XnFijsQWuQAAkUWPFusSpff+kecPawuSx6JtHLS+r/hnlV5o4jsMMfTMB8drv0QUGq2dE/smqSIAvggFKjxsgyHBw6rB4xhJKw/ecDxhzYDUL3bH7mFoTYzoXIr9srEWrHsWB2jdyBtjDj/0b9YNkcB4KRNuvybr+YkwGIvoTbPyFyZtVULLhsziUgTL/2zni61VrohWJ3aB3hTJ6K+zj92lpek2Na3VXsaMKaE/KYgoFW0q8MMQpUk6UxbHcQkN//w+iuazYRt2swKQuDrzSSTA9zfmPvmYdCtqJ8g0NxL7y0imXxQ==
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=QROIZIYddFzygYO70eO/nQg3XuTwIxKoiJk+lMdH110=; b=J2aB6SiVijGfqoRA6oBvislt+zJJY/kMcKuODTOUpHeMZHqivnFEKgYvHCZYNxXfT2TDXJEJA2yteXoAgispcJW7jui7KE3mRAkyzGmli/CFJ1Jp+ugVB5w/WWW9u/maKQBE3UNs7GA225Lhbm+VSXP5tR3wVFrHXtT3PQnXZRSKFGylN/aOCUpZizbVVV6rLx7H1uS/SnH2gdKmG+ZSHnVootYbpEhGzF/IrNqqJt7Kk0PQj0gCRfkX+VFfNvmgUG2O0Fbe/8cnXvAFvFbdFd996w4wHuqiBeBOlxwbr8n689lcutWBiCeaVPQzkFsxkme5zpkPhb56A+Lm6yJohw==
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=QROIZIYddFzygYO70eO/nQg3XuTwIxKoiJk+lMdH110=; b=S58NMGdJKChygNbGEUaflcS34+2ZV+nXk4K7Lm1KkkcTDNavwwPouhuXIvxrN2UIBvcVbUE1y2tssL2FcTKJP+k7hll3MySHef5k5QNBmkfG0lZb0rfK+8NyA3/kLeZDvjD6TUr2djI7LWU60fJwLb4V6PCoeWAqbWJHPcHewIo=
Received: from DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) by DM5PR11MB1820.namprd11.prod.outlook.com (2603:10b6:3:111::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.14; Thu, 12 Mar 2020 06:22:16 +0000
Received: from DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::4d47:30fc:1b10:3db8]) by DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::4d47:30fc:1b10:3db8%12]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 06:22:16 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Andrew Alston <Andrew.Alston@liquidtelecom.com>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
Thread-Topic: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
Thread-Index: AQHV9+xRbXFEXTQbXEq8V5FM9D3NLahEfU0A
Date: Thu, 12 Mar 2020 06:22:16 +0000
Message-ID: <200E06CF-0589-4BBA-A025-D891BFA3CFD3@cisco.com>
References: <4F4FF5EC-690F-4C09-9101-98AB2DDFDE0C@liquidtelecom.com> <a38c3197-2513-4af6-cb4f-a0a96c082cb9@gmail.com>
In-Reply-To: <a38c3197-2513-4af6-cb4f-a0a96c082cb9@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: [198.84.207.201]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 522f7fd5-3091-4a04-79b2-08d7c64db638
x-ms-traffictypediagnostic: DM5PR11MB1820:
x-microsoft-antispam-prvs: <DM5PR11MB182066364C0A1D972FD8268CC8FD0@DM5PR11MB1820.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0340850FCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(376002)(396003)(136003)(199004)(6512007)(2616005)(81156014)(86362001)(186003)(6506007)(6486002)(8936002)(8676002)(81166006)(53546011)(966005)(5660300002)(26005)(478600001)(71200400001)(2906002)(316002)(33656002)(66446008)(36756003)(76116006)(91956017)(66476007)(64756008)(66946007)(66556008)(54906003)(110136005)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1820; H:DM5PR11MB1818.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A: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: uCr76pnqOoAkNHA6MyTmWkLYOuQK/WY6TOnQkjuEn7SfiTybGfs8RMuFwxmozDC3vIUmvz5a4a3bwO3KYM9buf6F+X/qsIjG47j92HSgz/WASaGWmaOK4zGW8u874w+xMHCcCbFMh9A4OoBXKfjfeBnuwcnn3RL/7X+GBE4McQx4pC1W/ythg4+tMXetyqZTY373CVKoIuMcxhEjjDYvaIDb1xwD4BofS3Gk10jz3ohoz39Cgx6oWFlk2BS/5FUOMNj6ivFj7bQPAiIbOlgtgcLjpxqP685Zrzlm37+iyPJw1WKN1XTFwBcmnW9FgAxA8AXKKo9L1dVO3C3tBb0ihXNU9nbPzpUBDkTsb4WMbEcrme4PIlKF6HYy1J3ugCjoMOlzvitEbwhe7q+g/11NTcxFSM1kcBIEWB/UlDoRDGIR/hReG4TwNA3pD1FiTqs30c2STd8lWxSQxDX536MwnKIpOqZ7h6NCOdMpYOJVfxnDinZpmN9owFVm3cBsGn0DJuUy3E71CZ1WVrz+a04g5Q==
x-ms-exchange-antispam-messagedata: TLfAPwVY8nl0CWB2sZb3YR8XdSFyFs6YTFsZBgHDOFW9mn0NWVyEC1r/zhoZi/jpwMdJPVM706vv4RzXjlaOJRfo1p1bXums/US+5mtTCnPD3/0VphhlVZmGhvQNPTgMTJGnHfxLJgYdWszngknWdw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_200E06CF05894BBAA025D891BFA3CFD3ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 522f7fd5-3091-4a04-79b2-08d7c64db638
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 06:22:16.6541 (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: iFxVzMXeOH8z73fIy4AF1L9RlMby+LzDdnS/InvPCdK4G3H5dF/qa5j9A0qbpUJ9XWDKP0TBJfVtbL+q5PVu0A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1820
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pcGVi3rXcM3_rCtYdmznHSPQYq0>
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: Thu, 12 Mar 2020 06:22:26 -0000

Hi Brian, I agree with your statement re operational practices.
Indeed this was mentioned on SPRING in the past, and at that time a couple RFC examples were given RFC6059, RFC7599. I'm sure there are others.

Andrew, are you providing any new technical information?

Darren

On Mar 11, 2020, at 5:30 PM, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:

On 12-Mar-20 09:53, Andrew Alston wrote:
Hi Spring WG



On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming draft – and I would now like to raise those issues in the context of that draft – and the fact that draft-ietf-spring-network-programming violates the address semantic specifications of RFC4291.

I really think that this is subsidiary to RFC 8402 (a Proposed Standard):

  SR can be applied to the IPv6 architecture with a new type of routing
  header called the SR Header (SRH) [IPv6-SRH].  An instruction is
  associated with a segment and encoded as an IPv6 address.  An SRv6
  segment is also called an SRv6 SID.  An SR Policy is instantiated as
  an ordered list of SRv6 SIDs in the routing header.

I don't see anything in the SRH draft or the network-programming draft
that is not within that definition. Whether RFC 8402 contravenes RFC 4291
is worth discussing, I guess. The latter says:

  IPv6 addresses of all types are assigned to interfaces, not nodes.
  An IPv6 unicast address refers to a single interface.  Since each
  interface belongs to a single node, any of that node's interfaces'
  unicast addresses may be used as an identifier for the node.

However, I can't find anything in RFC 4291 that forbids addresses
having semantic meanings rather than being pure locators. It goes
against one of my design prejudices, but I can't find anything
resembling "Encoding semantics in address bits considered harmful"
in the RFCs.

In reality, there are lots of operational practices that amount to
giving semantic meanings to address bits.

  Brian




Can we please have a proper discussion on this



Thanks



Andrew





*From: *"Darren Dukes (ddukes)" <ddukes@cisco.com<mailto:ddukes@cisco.com>>
*Date: *Wednesday, 11 March 2020 at 22:03
*To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
*Cc: *Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>, 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>
*Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?



Hi Ron, I made no comment in this thread on draft-ietf-spring-network-programming.



Darren



   On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org> <mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote:



   Darren,



   Didn’t we agree to close issue 66 because draft-ietf-6man-segment-routing header contains no text regarding SID/IPv6 address semantics. If that’s the case, how can you say that closing issue 66 implies WG consensus around SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming?



                                                                                          Ron







   Juniper Business Use Only

   *From:* ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org> <mailto:ipv6-bounces@ietf.org>> *On Behalf Of *Darren Dukes (ddukes)
   *Sent:* Tuesday, March 10, 2020 12:07 PM
   *To:* EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com> <mailto:Andrew.Alston@liquidtelecom.com>>
   *Cc:* 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org>>
   *Subject:* Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?



   Hi Andrew please see issue #66 for the closure record.



   https://trac.ietf.org/trac/6man/ticket/66 <https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$>



   Darren



       On Mar 9, 2020, at 3:18 PM, Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:



       Hi Darren



 Hi Mark, the working group discussed the

        > association with RFC4291 and closed it with

        > the text in the document.



       Can we get a reference to these discussions please - would just be useful to back and refresh memories and wasn’t able to find them



       Thanks



       Andrew




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