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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 22 May 2020 03:53 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 2BB5B3A0E51; Thu, 21 May 2020 20:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.587
X-Spam-Level:
X-Spam-Status: No, score=-9.587 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, T_KAM_HTML_FONT_INVALID=0.01, 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=He3rvMNA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WBGAFLBH
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 b61SgdU11juJ; Thu, 21 May 2020 20:53:15 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE44A3A0E50; Thu, 21 May 2020 20:53:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20556; q=dns/txt; s=iport; t=1590119594; x=1591329194; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ggMkCzEh630KuOGguWft7l485n3goy0NIrXC8FcSWMA=; b=He3rvMNA0YXdntBOfZQS8m5dxaLlHiewZtPHsybaCWzWWatnmqXdJqeX S11Ri7Wi9wFFl+kJJAzQuMqBZAFBjHbu9AQju4hk3eipOfcqKNaZggqri wyqLFHiv3fFX1G9dZN7Pz1X0Ns6xbE6Tv19Lqs5DQKwXP7d0f7LI7nuQ6 Y=;
IronPort-PHdr: 9a23:aBMWchQVBUjAedUftZ8vQaL0Jtpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFxoIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUBQC+S8de/4sNJK1mHAEBAQEBAQcBARIBAQQEAQGCB4ElL1EHb1gvLAqEGoNGA40/iXmJXIRmglIDVQsBAQEMAQEYAQoKAgQBAYN/RQIXgXskOBMCAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAgEBARARChMBASkDCwEEBwQCAQgRAQMBASgDAgICHwYLFAMGCAIEDgUIDAcHgwWBfk0DDiABDqQTAoE5iGF2gTKDAQEBBYU9DQuCDgMGgTiCY4lfGoFBP4ERQ4JNPoIeSQEBAoE6KysJgl4zgi2ORoJhATyGJIp9j1ZKCoJTk3qEdYJiiHySF4UDl36RJAIEAgQFAg4BAQWBaSKBVnAVO4JpUBgNkECDcoUUhUJ0AjUCBgEHAQEDCXyJC4E1AYEPAQE
X-IronPort-AV: E=Sophos;i="5.73,420,1583193600"; d="scan'208,217";a="772776732"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 May 2020 03:53:08 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04M3r893023628 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 May 2020 03:53:08 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 21 May 2020 22:53:08 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 21 May 2020 23:53:07 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 21 May 2020 22:53:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U+J/4IyupF4JjIjtM66fGSGslGGJ9lXotnGcbeL42B9gBjuF4HSFhqwUQt6LXx+2GtaP0/5U4Xn/w/kJTspt/IYwb+NdTYrqlEPRy97c0IKSPkMPs6SLk4SWzcmFPZdW26iVpTSOZoLLxYz1QmXzQYMSZGwiRLGq1Pbmr1uStXzMlHnUsosR9R9L4AILS1k9FsrksGL4GCMkw5nYdqIxNfUQAwoSnfP8L8ypZmB51JRc2lUHns2MxsiLq9C5OUVNuuLnqwPrh1exdS843JmNGguY0KdtJGkXK75xm/2u4iJpI27j7yGq3tExUqNBOWkNWoYUwlJXrtZRi2BU7wsb1g==
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=ggMkCzEh630KuOGguWft7l485n3goy0NIrXC8FcSWMA=; b=DF+cr5PXH/s9VHsuSP5y/uWfioLMTr8uWsrOD782cVtDmfKPsKzkMqm18sA/JRFZ9VdngAyKIO4hwAt3o7kQhe474o72k9kNNYVcDjUnWAdjWTU/6cm0+MxpsNnowECCRRTOWavYG8fJNSjszkvApz1XWb6rYLPKzNPtj5jfpIef6WhrdmGQ4Y6ptBQIrBmhuhV4iDLy0ONgjEdOVok3JdxM/RqyWR5oD6xN8S9B+TpF1ZyXpE3gb+3oyaQkiThc1n/dutWXZBVsNZ1v+sg4P9yEtiyXX0LvZPr8WE4b9D1oLv+lz3VRkaNknz8JMLkC/R16Gfw3WC/IA6sZIMIYmw==
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=ggMkCzEh630KuOGguWft7l485n3goy0NIrXC8FcSWMA=; b=WBGAFLBHMCLjfHedJifItM9jwnhUTQ+UUD//uiD3Z8Tg28p8wjJI05yeBxg2avne+p9zhX6SSDKiu//5ehEzsbRPbeWap3wtbcFRphIUeFE7qWpx5+UXAz9k13g7RaBFQTr2bhyjMiK4BN3VZ73slGqOHXj52dR03EdT+ie//0I=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4700.namprd11.prod.outlook.com (2603:10b6:303:2d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Fri, 22 May 2020 03:53:06 +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.020; Fri, 22 May 2020 03:53:05 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Brian Carpenter <brian.e.carpenter@gmail.com>, Ron Bonica <rbonica@juniper.net>, "Chengli (Cheng Li)" <c.l@huawei.com>, "Zafar Ali (zali)" <zali@cisco.com>, Robert Raszuk <robert@raszuk.net>, "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: AQHWL4VxmYvkCvDoNEmQ3Xkat3whdqiytyCggAALHOCAAAWDcIAAXREAgABKZfCAAAVCgIAAAypA
Date: Fri, 22 May 2020 03:53:05 +0000
Message-ID: <MW3PR11MB4570485EEDBADEF3B193BB82C1B40@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>
In-Reply-To: <5F062FA6-9E2D-46BB-A3D6-257D374D8F92@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d316db3-4d64-46d4-db31-08d7fe03a271
x-ms-traffictypediagnostic: MW3PR11MB4700:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW3PR11MB47007CE5D85FA2E19EA1049FC1B40@MW3PR11MB4700.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04111BAC64
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: B9tMQtOQM8xJG12ZJn630nC+gYTkhBY0JTnhFDwyNhx6xthB4ofHIT++rz/fqhfYkUUftk0xo9LqxCahz6iRZQwwwZB/zbBuUAlljYeWmDC61OmyPVTK4UmZ9vn/33KM+/LAomt/J1LlOpdnDP0wETUR/pR6Z1RrEdrBIfaBIe+WlIa0zMyz+CTx1PwP5OPYqZauCEXqtWkuY24cpQy3JIvLBLsIHrFYnktCIz1zYGjgdI0NAqsOrz2MbfZtOuzVbOXlmXCU9twghNfxwMwQeLAXhPMfFJSfKBz4g60IoWIgfaelKJSeLbDUEsPnc0+OsB6ZBSdx3IhPrqLbXmmdTlHOQ8QSzvGzGUKjsJcWZGGbfklEyH9jewnsJQh+dBmGoriGDVu9zqPEs2C8lgpTrQ==
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)(376002)(346002)(366004)(39860400002)(396003)(136003)(66946007)(33656002)(316002)(6916009)(2906002)(66556008)(52536014)(9686003)(76116006)(66476007)(55016002)(64756008)(166002)(4326008)(6506007)(66574014)(66446008)(53546011)(186003)(7696005)(966005)(71200400001)(5660300002)(54906003)(8936002)(26005)(9326002)(86362001)(8676002)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: WTvEb6m2r/w7npWrqsoJnpBvnocpdOFbEgkrH967zuGuLurNd3XsRjM/JunqhCISYobe+PdLy4sGAH8xgEsVU3Ynsgj/zTBTBzZCbfNGHt3TdY6YQ21Sv5G86GfJDpKqrFO5NpfRe0IoWF7pNi2tXIEkEzk8uRknkF0GuToThe4gqeG4A7PNk+ZAMGCm93quV5y7Eh9F7rDyxur1UL+YF6GfVIIm7DqHNAvWohZm3cTGz2sd1F58yhEWyf5eInRbmzhGbx8G6KG1KpELaNTN+yZG3/nix9kqONCgtpWDFN9BuAXcsKBs14yBYkyApJKS3WbHyr/Ur1QR8KRFX0X8NWOmkHPbEpoa9xUcShMHe+tBqJ/O/6Qp92RiCjd/RYk/L0R+FUFr1jREe44Jv9rapP8Qxm4jF75Kc+I9ucPPl03dwOiK1nYXh81/6L+S0WTtEE3t787ucHIEF1SNqyw2T43r4nVG6s0V07RM4MTT3YMuF1WkS69t1Opr79mNp/DN
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570485EEDBADEF3B193BB82C1B40MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d316db3-4d64-46d4-db31-08d7fe03a271
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 03:53:05.7025 (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: SIJhZYNkbHbaui1ncbvDuLIV6N9MiJjvAEmJAjnZRJswsD349Cc1ZmeYxsa0XL9YZd+MSkSJeRXW4AAnzDXAyA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4700
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sWzkSAIKrkIwzsLUuhz_KKyF51o>
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: Fri, 22 May 2020 03:53:18 -0000

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>; Brian Carpenter <brian.e.carpenter@gmail.com>; Ron Bonica <rbonica@juniper.net>; Chengli (Cheng Li) <c.l@huawei.com>; Zafar Ali (zali) <zali@cisco.com>; Robert Raszuk <robert@raszuk.net>; 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