Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

"Darren Dukes (ddukes)" <ddukes@cisco.com> Thu, 14 May 2020 11:35 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 72BD83A0971 for <ipv6@ietfa.amsl.com>; Thu, 14 May 2020 04:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=c1nUJ1fc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B66Z6g7h
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 Cq7y9mUyqH4W for <ipv6@ietfa.amsl.com>; Thu, 14 May 2020 04:35:07 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EA13A0809 for <6man@ietf.org>; Thu, 14 May 2020 04:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13588; q=dns/txt; s=iport; t=1589456107; x=1590665707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sg00Er4w9bJr+F5sP5ePpLoyy0A/b05IG10k3Qm+seU=; b=c1nUJ1fclyWdhdxK7Lax+n1zHcz7orwrC90sF/TXkCw89vrYbj7YFRmt 4SA0zoKz9RBeyzoWtuv0YweS59KAGEkBAFFPHAWrw60XUXY3TXMVgSsoW sSu+eZVgqHVSZIIQAlo2nB7LcKi1IT3Ci/39aceFjPYqY6t43k2KlkR3e g=;
IronPort-PHdr: 9a23:UxS2qBDczU0pecXeQrXiUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw30g3LWojf6/tAk+fMtebrXmlTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBoHq/6T4bHg3yLwwzLePwScbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nxDIuXBPPe9RwDBl
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DaAQDJK71e/5pdJa1mGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBR4ElL1EHb1gvLIdrA408k1SEY4JSA1QLAQEBDAEBGAEKCgIEAQGERAKCFSQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcQEBAQEDAQEQGxMBASUHCwEPAgEIEQEDAQEBLicLFwYIAgQOBQgagwWBfk0DLgEOpk4CgTmIYXSBNIMBAQEFhTkYgg4DBoE4gmOJXxqBQT+BEUOBOIEVPoJnAQECgUUgK4Magi2OUIkrJZpiCoJNiB2GA4oxgl2IbIUCjH6tZAIEAgQFAg4BAQWBaSKBVnAVO4JpUBgNkEAMF4NPhRSFQnQCNQIGCAEBAwl8jkgBAQ
X-IronPort-AV: E=Sophos;i="5.73,391,1583193600"; d="scan'208,217";a="759755616"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2020 11:35:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04EBZ1iV019755 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2020 11:35:02 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.1497.2; Thu, 14 May 2020 06:35:01 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 06:35:00 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 06:35:00 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DA5+e1x+6qumXjN5i1HOVHvlsKXs+W0NIh5Popd3XwEVIE+8UdS2+1Hcn600OIsRI0tRhqiLWDdEBbn6HZPm09Z/0KgO3Ls4b/po41Yrf1VTYxOpzTYwMgaDVbLmYvxKEXyieiOxIO2SaVfq+bGsLLf1sI/xjPXX4w9qkowuMeheqeNz3Ew2xpr7F7tB8qs45pHtvdJiiF8MRsFXkrrE99PWVMpNcKY1MmbRjEFAhWx+blbpDDQJyVWBbe7smMvvlcyAkn00YogUMswU8A/bxQ/SHEmdbEIZFCJA0d8iA0Iq9209iK26A9n9sm6CgkWKNNMmwA364vm9V7pbRG8TMA==
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=q8QVxE+flbKzF3ezjHd1fDbyvkd72AykCK4TJbMdKA0=; b=Z9AMg82Y+uiFE8QyiUOo6UD98b0C78JLlAejd0a9PKEfPMTaVsokjOgTStRVWnF+tp9d4D1qemUPkV7PwouvuycEVSvQq0w5qu4clnbvlnMkT/YaPMxeF61Bjf3eKZUL2mRFuFWSQPnjZlGTARlZdnfx30ghEdot7dE7wp4p5yug+Wu0zVdFOdFs6LGY5VOUjtFZ7YdGhKU6AYdx20ZAPxjVxbEWkoll3VCrZK9+pxBKv0lT7YdwBGotscm8hoEd4M0DOBWAYvblXk4nI/SrgU/yKngwliDnJG1ILcOCRTURsDSrZCiDvT0PBfiKQKTIxamsBqMPvWl84bGPeWOLdQ==
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=q8QVxE+flbKzF3ezjHd1fDbyvkd72AykCK4TJbMdKA0=; b=B66Z6g7hDLdubq9eohcIdx/5HLNr7Zbh9+KcxlOM8M//ok1gbNrsLc1y3WJD1Iqmo4yhsEbRHQUuQzI9t6mGz3GxDjWJgGHkGpuezxeTxj2uzvxH3AnxI2TAk4fSuQnQGqEcDcCKPteoTgqYac/RKgJ9sGPNAX6EyNpgKIvwVEs=
Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6SPR00MB047.namprd11.prod.outlook.com (2603:10b6:405:4f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Thu, 14 May 2020 11:35:00 +0000
Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::c8dc:287c:17c2:28a7]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::c8dc:287c:17c2:28a7%6]) with mapi id 15.20.3000.022; Thu, 14 May 2020 11:34:59 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "6man@ietf.org" <6man@ietf.org>
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Thread-Topic: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Thread-Index: AQHWKWFd12dpatRNmUGeLhiJYsyLEaimj1qAgAAB0gCAAOGjWw==
Date: Thu, 14 May 2020 11:34:59 +0000
Message-ID: <BN6PR11MB4081C84F143879E04AEBDE7BC8BC0@BN6PR11MB4081.namprd11.prod.outlook.com>
References: <DM6PR05MB6348E9AD1E088792C2F10BB4AEBF0@DM6PR05MB6348.namprd05.prod.outlook.com> <8CC3F837-B4D6-4570-AF2F-37041839F391@employees.org> <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net> <2F73BAB3-F91D-403E-90C8-8B64F077703D@cisco.com>, <5f19625d-6004-75f5-2e86-0f39abcffeae@joelhalpern.com>
In-Reply-To: <5f19625d-6004-75f5-2e86-0f39abcffeae@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2607:f2c0:e4b8:d01:41ee:d07e:2949:24ff]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: badc7c8a-ef89-4e36-4741-08d7f7fad5f8
x-ms-traffictypediagnostic: BN6SPR00MB047:
x-microsoft-antispam-prvs: <BN6SPR00MB04789E8B382FC07553809A2C8BC0@BN6SPR00MB047.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 040359335D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 801NHuRqxjIrevgreemVii2skwVzbhyeuSxcGBQ+xDYLC75+atwValkcxDQ3Hh0/GaLTIqFWV/LAUYjg3cjKplVe2XYwpf7lPMUUGFHV2MG7gq93VWL2yUS8ua+etVJ04mzNj6y4twdFMxcysfescrA9sCtpRiQSaqd+2MDZVE7q5msHolpPFMN025dSdJweX258xH0cevW9aySPWtVMTZ4On0K4RgwjKGGsMPAwsJvqKK4m8vC7enBq47+sYzHUMzCZE8RqR1Okaw4kFTv7Bdmv16bzKMeoBqnigZCy8IP+ZrCMK4zwurGe2n5sn2bV3MU3CA8kleY463mF768BlRyDVmbI4fwYMPxptlocEY3WF6tY2d0ymR4Sk34OGiDdfwuhDCF/BetDsJs3ZarCaSRMbPgn5/CNMDBTm1HNxr7Hr5W2WYVegGrKwxwpJkOcGN+hPmzA9GbEAA4vRJYsB0yyVHFmJDF2PYtDtUXzywmhhLoZoDZMySo2VIYSW/6iyvCxEYwgTqZMnXv9klQFZg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(366004)(396003)(136003)(39860400002)(5660300002)(186003)(76116006)(66946007)(66446008)(316002)(2906002)(8676002)(66556008)(66476007)(86362001)(64756008)(6916009)(4326008)(55016002)(966005)(9686003)(478600001)(6506007)(166002)(71200400001)(52536014)(7696005)(53546011)(33656002)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: XlAVd3IcBOTiPS6HxUX3K7m3kuq3A5MoIUZwx9Z9ZKzUX3j+7hne74Vz6nk08qrM8bHdOtOKzX/XgFn3sQ8LoFVKhMny51vr2Kz/A18BF+ZzFPdtOw3ukCWgYr7YRD1NrCvKO7HwS5DsLfG36ykdSjnO2w7v2L4vNhrNbLIR9PuBZaccCIwDxIN8UauGCdMHPUTRhCo/Ek4ui0+e0extPmq99ogfMcF1pgyun6ZqlA+uHDPv3C6La5jBSUB/U2/3B7FNooX2kcpmGchWGG3E5MJ7yPJOx01zoWL2M+ynl8bLezKE6PSlU5sb+U20o/ERs2aMEy3qw7ZuSc0fG426syDRcpQ53sjkNJdeaQaBIpimnBYJE7Dg0/qlPdPvhH7RTRMe495AJ6HsN+ig44fIcpq/CfuJC97rSDJitcmGM3cFhVni0hFOslZo5WieE1Y6xcegdx/IM4WwMX82VeakziVUANgRWrVez2x+LPr3MBr4i8rDiSuU9VOp9FL2QOxTwYnt0i49JhUfaYDAhqfHTzWjiFDhPY7br+XBYIgczuLUTbzKxq7WIED4DCnZ26iT
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081C84F143879E04AEBDE7BC8BC0BN6PR11MB4081namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: badc7c8a-ef89-4e36-4741-08d7f7fad5f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 11:34:59.8258 (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: kyLsGmcyc19IYnSNXqYCoV47p7gnRgv9+sG/08uPUahP3xJ1EylYZcSCNzHgNG1Mu84DNa3Z80K+f2YPfp3Jiw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6SPR00MB047
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/emQ3Sj_l4fWXErZY_nhQAbYxr5Y>
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, 14 May 2020 11:35:11 -0000

Joel. It is not me who is recasting history. You forget that the CRH has been the routing header for srm6 up until last weeks presentation.

Last week it was presented as a general replacement for RH0 with no association to srm6.

Is it still solely the srm6 routing header?

Darren
________________________________
From: Joel M. Halpern <jmh@joelhalpern.com>
Sent: Wednesday, May 13, 2020 6:01 PM
To: Darren Dukes (ddukes)
Cc: 6man@ietf.org
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Darren, the CRH routing header has been on the table for a LOT longer
than "last week".  And has been presented at previous IETF meetings.

You have the write to ask for clarifications.  In an earlier message you
made two specific requests.  Fair.  But please do not recast history.

Yours,
Joel

On 5/13/2020 5:54 PM, Darren Dukes (ddukes) wrote:
> Hi John, my 2 cents.
>
> Last week someone came to the working group and said “here is a new routing header, it carries opaque numbers that get mapped to IPv6 addresses and some other stuff.  Please adopt it.”
>
> Now the WG is asking what this thing is, what is the author's intent, how does it fit into other work ongoing in 6MAN and other working groups.
>
> Contrast this with every other routing header defined that has come from a WG with a plan for how it is to be used and usecases for it:
> Type0 - IPNG
> RPL - ROLL
> Type2 - MEXT
> SRH - SPRING
>
> CRH seems out of place...
>
> Does CRH even fit in the 6man charter?  It doesn’t appear so, it looks to me like the tip of an iceberg.
> "It (6man) is not chartered to develop major changes or additions
> to the IPv6 specifications.”
>
> Darren
>
>
>> On May 13, 2020, at 3:59 PM, John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:
>>
>> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?
>>
>> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?
>>
>> I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:
>>
>>> Bob: Thank you Ron. I think it's too early for adoption call.
>>>
>>> Ron: What is needed to get to adoption call.
>>>
>>> Bob: I can't answer right now.
>>>
>>> Ron: Can I ask on list?
>>>
>>> Bob: OK.
>>>
>>> Ole: Related to what's going on in spring.
>>
>> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.
>>
>> Regarding the SPRING-related process stuff:
>>
>> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]
>>
>> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?
>>
>> Regarding the more general “what is CRH for anyway” stuff:
>>
>> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?
>>
>> Thanks,
>>
>> —John
>>
>> [1] https://cuberule.com
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>