RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Sun, 24 May 2020 05:42 UTC

Return-Path: <ketant@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 71CC43A07C5; Sat, 23 May 2020 22:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=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=MzXvyQ/8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BqXX69WP
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 13hCz3MG3Unt; Sat, 23 May 2020 22:42:22 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019213A07C3; Sat, 23 May 2020 22:42:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14324; q=dns/txt; s=iport; t=1590298942; x=1591508542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mTfObyQy8YhFkiSvPVf6cK0rmGqbXF3eG0vsk2MQZMM=; b=MzXvyQ/8FBxOnxStSeehbuvpomIhHHc58RI/efIp0KWQbRA8qlICeUYm F6r3SQtbF4eOjO+gqcAczZCz7SnAqT6vbDfWxlmCNvhPSJtNFQASCH4vH RggYccgq+oTXOyDlrONCsiOvU005T0cKE3z8W/d42F/yDwpjVJCeaBoM3 A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AIpECIBXr5YcNQirCRROprCtingfV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+FufBDhu7WuqT4VHYGp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0QHR?= =?us-ascii?q?j7NQNxPunvHMjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWCQDeCMpe/4sNJK1lHgEBCxIMQIM?= =?us-ascii?q?bUQdvWC8sCoQag0YDjUCJeo5CgUIvYQNVCwEBAQwBARgLCgIEAQGDf0UCF4I?= =?us-ascii?q?GJDgTAgMBAQsBAQUBAQECAQUEbYUqByUMhXIBAQEBAgEBARAREQwBASkDCwE?= =?us-ascii?q?LBAIBCBEBAwEBAQICIwMCAgIfBgsUAQIGCAIEDgUIDAcHgwWCSwMOHwEBDqB?= =?us-ascii?q?bAoE5iGF2gTKDAQEBBYUzDQuCDgMGgQ4qgmSJUQ8agUE/gRFDgk0+gh5JAQE?= =?us-ascii?q?CgToPHBWCfTOCLY5IEoMMkSOPJDNKCoJUlACEeYJjiQKFCI0VhQaYApEoAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFWcBU7gmlQGA2PYV8MBRKDT4UUhUJ0AjUCBgEHAQEDCXy?= =?us-ascii?q?KFoE1ATBfAQE?=
X-IronPort-AV: E=Sophos;i="5.73,428,1583193600"; d="scan'208";a="483992877"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 05:42:18 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04O5gIuB024750 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 May 2020 05:42:18 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 May 2020 00:42:18 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 May 2020 00:42:17 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 24 May 2020 00:42:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXt8iIxRKWQwoDr5B7TKrnnHYrX6RNjtCS4f5657PKshtUnd98TrpI/PQ0J6vDdOA4cSiDNOj2rrNR+Yh87rQ32k0JGpSNzCsJ0G0wQK4MyAzlj3QKsIJ38cYq8FFdQvWPuI4fd+St2urJghSqyMLvE1i7KNcqwqAtMA2jVHsfxbwdPFQCBAWbds3M1My7S43BuECZ4xuXdF6V5jJZVJmS7c+ggwZHDKkFCnTrNN3vIGCDUrl9NYO0uI5rX5CSc17Yx+y4WKVTGxvLkQg1ewx1vNgKIneWRYmTWL0uRpRm/DX/uQZOK4a1+FLU2wuU4tt+GCl1VpX3f49AcwzIHnHA==
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=mTfObyQy8YhFkiSvPVf6cK0rmGqbXF3eG0vsk2MQZMM=; b=kq7bNNqISG+LQO9Ys++fyTWSO/R4LBOrnF67LhzBa5OB3rSv/nqPG17FIvR5DcwzJQg/sq3AhrSLysr05QHrnaAa8K+qVVggzAnz44HRs9vW3yBmAxRDUSvXJnDs59fDNRSrIG1eO5qKHh2nJ64RFnYN11NHLedjdQFnT1SGqSFJyC+fSQ/m5Dp3zd0u8TtdlXCkF3KT4X/490RwyAPN5E9HNEmWVH7104PL3c2jpIh9Kr1iPzhjc2TZHXQYD29RNhxy10gQpJ0ylVOp0ICpvCrA82/d48VZgRdwyltV9ghY3rZi06VgJ4omqRhLWUzy34jT/DnC72zhV/W2U2Te7g==
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=mTfObyQy8YhFkiSvPVf6cK0rmGqbXF3eG0vsk2MQZMM=; b=BqXX69WP6I0ZUQK2AfjgZyr/+LcJThMiLsJIhlDiFlIg+wMLOl5ADb3J3/gusQruRTxhLlNIZXhWz5sh58FSsXrhZG20uOJT1ILbCE1OaMK64tId8Fi6wacQxKiZ6RnvD/zV9H0tjZIkkhDdAuPn8t95DCc4NmVWQ10OXHMTjnA=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4604.namprd11.prod.outlook.com (2603:10b6:303:2f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Sun, 24 May 2020 05:42:16 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%5]) with mapi id 15.20.3021.026; Sun, 24 May 2020 05:42:16 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
Thread-Topic: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
Thread-Index: AQHWL4VxmYvkCvDoNEmQ3Xkat3whdqiytyCggAALHOCAAAWDcIAAXREAgABKZfCAAAVCgIAAAypAgAANNoCAAAvxgIAAnLwAgAKNblA=
Date: Sun, 24 May 2020 05:42:16 +0000
Message-ID: <MW3PR11MB4570FD37ED32519C677F5E59C1B20@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <9CF68CCE-B584-4648-84DA-F2DBEA94622D@cisco.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A2C1AE@dggeml529-mbx.china.huawei.com> <DM6PR05MB6348A22A123AFA7E7345087BAEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB457041A967A6BBDA1C7EF0FDC1B70@MW3PR11MB4570.namprd11.prod.outlook.com> <93a31c7f-a102-da59-d9a8-2585cd8e3c65@gmail.com> <MW3PR11MB4570B197EE00C5385DAEE138C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <5F062FA6-9E2D-46BB-A3D6-257D374D8F92@gmail.com> <MW3PR11MB4570485EEDBADEF3B193BB82C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <ec63e90e-19fa-cd6c-eacb-4dee44815c99@joelhalpern.com> <MW3PR11MB4570FB2397D4B28A42626802C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <3bbb28c8-0106-ad63-abf9-c9dc4e428e0c@joelhalpern.com>
In-Reply-To: <3bbb28c8-0106-ad63-abf9-c9dc4e428e0c@joelhalpern.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
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: [49.36.52.93]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 084ebb6c-6877-4f70-33c1-08d7ffa537bf
x-ms-traffictypediagnostic: MW3PR11MB4604:
x-microsoft-antispam-prvs: <MW3PR11MB460438628B03A7F339B089F3C1B20@MW3PR11MB4604.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0413C9F1ED
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JobKQ4+Z7XSrZ3kwlErdvwzRlO0LH6wGbJXjrwftVd/EPgmPHyAYyxbX4AumDIPUkxzziVYSFGpu8w2H2mReEw2x30ev6IJnrC84clwYH13c7D2LuCa3D4bZH1XyQgdodDZ8LCDr1FsMCm/UDFOTEvV+fqbj4ZyDQlkG4Cvus0qnnTcmXB9YvzQKglO0YQbAkXiy01vmM8UCj58DuNt7Abq3Ci2lD31drbCpPTrDlU0rCrBHnQZjKXmX9o4BBfwGq+zpxkU/qNPLko1aP0NIqqdosmZCRKfIwIvaNMsMucJdFUIjvxpZqUoDDhXom1Tfobc/kxB3WKgT3nTmzWLprVfClyOwIrdIGCAYDcPc+WIr1dVY9HEDEQXxr99MzH0rsQjsCawJBouEzUS0PF2AhA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(346002)(396003)(66476007)(26005)(966005)(33656002)(186003)(66446008)(66556008)(64756008)(6506007)(86362001)(66946007)(52536014)(53546011)(478600001)(8676002)(54906003)(316002)(76116006)(8936002)(2906002)(7696005)(5660300002)(55016002)(6916009)(4326008)(71200400001)(66574014)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: PMhpJMVH2GygcFe4cFevS4b9rQzrDcJpFp3tjl2WYocaBF6f4jvF9ghFTsAE1abIVQysUHR7UbSUcDZ168KcrYPFNvbO1YrMhxw097UstrYY+eF40Wu8+YR1zzx8qxeGE28jHyEu/OJbEOljYrkyrc5b9ZltwJyUrNzouU/pdyCZqZlnYBEY5AUoUDS9M5eD839CvLqMuHbWH67ZyD9SKDNpxtB4X/cm/beETvZ3h8bj/4FSKXY2JCW+w0pla8tDcDvx9T+gk5s2A8At9pNF2OXm+dDenOpuYjNUyTC3XI282XyVaUzAQxtbz68/npA4qMYx86ZJ/PqrMhHXHDVDSg0FMx4N54Hy3DUbYP+obp2TIJk2+ol97Y5+mm7NI6On9NZljBSEsLtj4wNDKG76P1ILX02Vx8EIVWiwIQZWlClCc0W/xQ3BZ/kqJg+E4+mgL2MvXkWP/wyED6wCKVJB6azRJfI9euc6GB39hCrps+4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 084ebb6c-6877-4f70-33c1-08d7ffa537bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2020 05:42:16.5322 (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: PL2xLYm9OU9ciwjanGz2zXQqezVdywC71vNPaQ2wVNn6RM2iKvskKOdNe43wd0Ai4WRohfsY5LnFo+Asu/eeMg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4604
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NU7-LE_Yk-9lmt-WbyVlHqrMmOo>
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: Sun, 24 May 2020 05:42:28 -0000

Hi Joel.

I believe the focus of the adoption call is CRH and that too in the context outside the SRm6. So I am not trying to debate SRH or SRv6 at this point - we can do that separately not to mix things up.

I am looking for explanation of the "other ways" that CRH can be used (i.e. those outside the Spring architecture). I am trying to understand from the authors what would be the applicability of that solution, it's use-cases and it's requirements. That is what, I believe, will help us evaluate the CRH proposal in the context of this working call. That will help us answer these questions like the scope of the SID, 32-bit or 16-bit or something else and what the CRH-FIB is going to turn out like.

Note that we are introducing a new CRH-FIB based on some vague definition of "SID" in the IPv6 Forwarding Architecture here. I've seen comparison of these SIDs (mapping IDs) to MPLS labels, if that so - isn't it a significant change to IPv6 Routing that needs more clarity? The CRH proposal may end up introducing a new form of MPLS into IPv6 - something that needs very close and careful consideration.

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <jmh@joelhalpern.com> 
Sent: 22 May 2020 20:06
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: spring@ietf.org; 6man <6man@ietf.org>rg>; rtg-ads@ietf.org
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

None of those documents drive the need for SRv6.    Even the problem 
statement doesn't really geet us there.

More importantly, SRH does not fully comply with those documents.   It 
has fields that are unrelated to those documents.  Heck, it still has the tag field that many of us are unable to understand.  And it has a TLV that has no meaningful use (the authentication use is internally inconsistent, as was discussed on the list.)  While wew objected to various parts on the substance, the fact that SRH is meant as a building block to support things beyond the SPRIGN archtiecture was not an objection.

Architectures are the closest the IEtF comes to building solutions. 
They are arguably not very useful.  MPLS, for example meets both the base MPLS architecture and the SPRING architecture.  And several different VPN architectures.

CRH can be used to meet the SPRING archtiecture.  It can also, has been clearly stated, be used in other ways.  There is not "an" architecture for using CRH.

And there was not "an" architecture for using SRH.  If there ere, we would have gotten the extraneous parts removed.

Yours,
Joel

On 5/22/2020 1:20 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> I'll point you to RFC7855, RFC8355 and RFC8402 that cover both the data-planes for Spring. Then the RFC8354 which is focussed on SRv6. All this body of work along with a whole lot of discussion and brainstorming happening in the Spring WG provided the architecture, use-cases, applicability and requirements for SRH (RFC8754).
> 
> It may be so that many people in 6man focussed on only the IPv6 specific aspects as is their design expertise. But there were others (in 6man, Spring and other WGs) that were able to look at the solution in a holistic manner thanks to the body of work behind it.
> 
> Net-PGM builds on top of RFC8402 and RFC8754.
> 
> To give a real world analogy, let us understand what kind of a car we are trying to build (to carry goods/passengers or both and how much/many, what terrain it is meant for, what weather/environment conditions, how much speed/performance/fuel efficiency parameters required, etc.) before we start designing tyres for it.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Joel M. Halpern <jmh@joelhalpern.com>
> Sent: 22 May 2020 10:02
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>
> Cc: spring@ietf.org; 6man <6man@ietf.org>rg>; rtg-ads@ietf.org
> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
> CR in CRH
> 
> Ketan, I am trying to figure out which documents you think were adopted and approved elsewhere to drive the 6man work on SRH.
> 
> I did find RFC 8354, which was a use case.  It is not a problem statement.  It is most definitely not an architecture.  The only architecture documents I can find are general SR documents.  Those did not justify a need for SRH.  And I (at least) did not object to SRH on the basis of that gap.
> 
> Yes, SRH normatively references 8402.  But 8402 does not drive any need for SRH.  In fact, the actual text references to SRH are fairly cursory.
>    (The most significant is some terminology.)
> 
> In fact, as far as I can tell, the ties are such that there is no 
> evidence in the documents that SPRING had any say in SRH.  (the 
> reality is more complex, I grant you.  But there was no formal 
> approval or signoff.)
> 
> As far as I can tell, there was no formal approval of anything by SPRING that can be read as a request to 6man to work on SRH.  (Do remember that the SRH document was adopted by 6man in December of 2015.)  The network programming draft did not even appear at 00 until March of 2017, 15 months later.
> 
> How, given this history, can you claim that CRH needs something more.
> We have operators asking for this.
> 
> Yours,
> Joel
> 
> On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
>> Hi Bob,
>>
>> Perhaps I will try to make my case to you (and everyone else here) … 
>> one last time.
>>
>> This is how I've seen RH work being done in 6man until now (in a 
>> matter that fits its charter).
>>
>> 1) There is a WG (not 6man) that defines the problem statement, 
>> use-cases and architecture that requires RH
>>
>> 2) The 6man being the experts on IPv6 design, either take up the 
>> document that specifies that RH (or even if it is done in another WG, 
>> reviews it).
>>
>> So 6man has always had work done in (1) to reference and lean upon 
>> when doing (2).
>>
>> My argument of the shortcut in the case of this specific adoption is 
>> that we don't have (1).
>>
>> It is not in 6man charter nor expertise to take up (1) because CRH is 
>> not purely IPv6 work. It is not meant for "Internet" but a specific 
>> "limited domain". The SIDs that it introduces is a new "mapping ID"
>> concept. It is not an IPv6 address and neither it is MPLS. This is a
>> *_Routing_* Header and part of a new Source *_Routing_* solution.
>>
>> Therefore, without (1) being made available to 6man, I believe that 
>> working on (2) in 6man is to me a shortcutting of the IETF technical 
>> review process (specifically of the *_Routing_* area in this case) 
>> for a solution and does not provide the necessary reference for 6man to work on.
>>
>> Why the rush?
>>
>> I close my arguments.
>>
>> Thanks,
>>
>> Ketan
>>
>> -----Original Message-----
>> From: Bob Hinden <bob.hinden@gmail.com>
>> Sent: 22 May 2020 09:03
>> To: Ketan Talaulikar (ketant) <ketant@cisco.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Brian Carpenter 
>> <brian.e.carpenter@gmail.com>om>; Ron Bonica <rbonica@juniper.net>et>; 
>> Chengli (Cheng Li) <c.l@huawei.com>om>; Zafar Ali (zali) 
>> <zali@cisco.com>om>; Robert Raszuk <robert@raszuk.net>et>; spring@ietf.org; 
>> 6man <6man@ietf.org>
>> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size 
>> of CR in CRH
>>
>> Ketan,
>>
>>   > On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant) 
>> <ketant=40cisco.com@dmarc.ietf.org
>> <mailto:ketant=40cisco.com@dmarc.ietf.org>> wrote:
>>
>>   >
>>
>>   > Hi Brian,
>>
>>   >
>>
>>   > Please see my previous response to your comments.
>>
>>   >
>>
>>   > My argument is not legalistic. I am not as experience in IETF 
>> work as you and Bob are. But what I understand is that the reason why 
>> we have these "legal" process of charters and BoF is to enable a 
>> proper technical discussion with the right context and details of the 
>> proposal presented for review of the community.
>>
>>   >
>>
>>   > I do not see how shortcutting them helps anyone and I wonder why 
>> it is being done in this case?
>>
>> There is no short cutting here.  The adoption call is to determine if 
>> there is interest in the w.g. to take this work into 6man.   If it 
>> becomes a w.g. draft, then the w.g. is responsible to decide what 
>> happens next.
>>
>> It’s a first step, it is not a decision to publish it.
>>
>> Bob (w/ w.g. chair hat on)
>>
>>   >
>>
>>   > Thanks,
>>
>>   > Ketan
>>
>>   >
>>
>>   > -----Original Message-----
>>
>>   > From: Brian E Carpenter <brian.e.carpenter@gmail.com 
>> <mailto:brian.e.carpenter@gmail.com>>
>>
>>   > Sent: 22 May 2020 04:18
>>
>>   > To: Ketan Talaulikar (ketant) <ketant@cisco.com 
>> <mailto:ketant@cisco.com>>; Ron Bonica <rbonica@juniper.net 
>> <mailto:rbonica@juniper.net>>; Chengli (Cheng Li) <c.l@huawei.com 
>> <mailto:c.l@huawei.com>>; Zafar Ali (zali) <zali@cisco.com 
>> <mailto:zali@cisco.com>>; Robert Raszuk <robert@raszuk.net 
>> <mailto:robert@raszuk.net>>
>>
>>   > Cc: spring@ietf.org <mailto:spring@ietf.org>; 6man <6man@ietf.org 
>> <mailto:6man@ietf.org>>
>>
>>   > Subject: Re: CRH is back to the SPRING Use-Case - Re: Size of CR 
>> in CRH
>>
>>   >
>>
>>   > On 22-May-20 05:26, Ketan Talaulikar (ketant) wrote:
>>
>>   > ...> It is the 6man charter that precludes it from defining a new 
>> Source Routing solution..
>>
>>   >> “It is not chartered to develop major changes or additions to 
>> the
>> IPv6 specifications.”
>>
>>   >
>>
>>   > If this addition was major, that would be true. But adding a new 
>> RH type is well within the scope of maintenance, IMHO. We have 
>> already done it quite recently.
>>
>>   >
>>
>>   > In any case, legalistic arguments about WG charters are really 
>> not how we should take technical decisions.
>>
>>   >
>>
>>   > Regards
>>
>>   >    Brian
>>
>>   >
>>
>>   >
>>
>>   > _______________________________________________
>>
>>   > spring mailing list
>>
>>   > spring@ietf.org <mailto:spring@ietf.org>
>>
>>   > https://www.ietf.org/mailman/listinfo/spring
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>