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

Ron Bonica <rbonica@juniper.net> Thu, 28 May 2020 16:55 UTC

Return-Path: <rbonica@juniper.net>
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 761623A1010; Thu, 28 May 2020 09:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=zvX04Ukz; dkim=pass (1024-bit key) header.d=juniper.net header.b=gSGJeaX5
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 tP-hng6kwSf4; Thu, 28 May 2020 09:55:52 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F913A0FD7; Thu, 28 May 2020 09:55:51 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04SGlXWb002510; Thu, 28 May 2020 09:55:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=BRCL7c3q2BdwFTYSjZjmmKz64kASFTXEy7NSIRdvnPM=; b=zvX04UkzmfOvvMQrwrFe+gCg39vAb6r7ngVsrWqbCNCDzPqSDFilRGxKuWzLSO0ongDN R4g4s6NaB1E1OnJr/xpG1ltfv9gHLC7SyurN0Z7wcmYafjtnyIVsz+yxj+763/QXAxqI uibM6lHpJmcx8cEw1r8dR74uNJSDOa2dp9h/NCTaIJOg4aSMt5GBS1APBPURPpXAss5+ X+lV7Cyuy0ye4QbsOpC/WwGMm6UHMgiOlbIEs5L9RBe0b258RS7M6iBl8jn2fI5sOTNO JifNDAYXTcfoUvi7a5DYw+cqLhp5CxvkAdjPmoq0ucYDiAzFojWjnLZfDo5pVndtLo9j JA==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2050.outbound.protection.outlook.com [104.47.37.50]) by mx0b-00273201.pphosted.com with ESMTP id 319w1gsu9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 May 2020 09:55:49 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z5j5wTDHDIsREQkOsmQ83ZAGExtUyUpJLvW0HvgMcCneBCA3WA6qMLg7e7gj6n7d85BqPI58NT0Um1EWOBoPKf+zvQyfbR5qlYGyh9pTxroOQok4uTUCUJFIec3XCgPaNN1/u+StYJceQQIo9PzlHIVi2Q+aKcAwx+m93BDcyMwK8R0xKn8SJTjapC8T9DqpuaGfiY37d729E69JvCgMIt3gYpt49oww/msNnYeLPi9gDRAU6aX/DCgZrv5EXE8wPaYWkjvcTwXwhSZWz09a1aEIXpjUQU8AQ4Uw/vbyeLgu5qrt2cEobVzRYUsS3gid3xwuza+0tAe+7YkqMjakbQ==
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=BRCL7c3q2BdwFTYSjZjmmKz64kASFTXEy7NSIRdvnPM=; b=FibDqBmvEIbGJOzklI9juZqwrIPgPpsLD9zRAiXCy9o94dbu4XJigwoRRyz/nE376r3gdAfdm7Dk7UjouEMYV/CiKTrvzHCQ1vJxHnovufop/Yk0Z+GTabshyy6Nu7eF08PDI9VOBgukv2vpOPp6YIQPHsIS1d1d8fg2OyTXAvqVET21wNG2o37todN1e8fe5QMRFYX9f+pKOn3QthURN7c5/W7Fb9M2TxpvaZv4JG+9PFY7Ag8FmJUQ5PosAUGrgcLAYqccGwyybeexW6qhttyePY9YhO9KUh9rEidYl9q1rYH+Hs1+Cm6vobIsC0FJAsFNbYSNgjZdS8vn5JN9vg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BRCL7c3q2BdwFTYSjZjmmKz64kASFTXEy7NSIRdvnPM=; b=gSGJeaX5SZstY5St6AZR+ZGgGRQn/fcOHBosFyfJcB0FzAVWW2vgYqh5otSciafy01HsWc9bGnLyf+YqHjpmCYyRnMHInxmWhJ2Rz6J38uUZ91n/2o46OC8UH9SXcSXCl/ut5Gs49jnJpfs7HlFTbOs/x0+MlhmrIinVAfMUTjQ=
Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB4939.namprd05.prod.outlook.com (2603:10b6:5:ff::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.7; Thu, 28 May 2020 16:55:47 +0000
Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.3045.018; Thu, 28 May 2020 16:55:47 +0000
From: Ron Bonica <rbonica@juniper.net>
To: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@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: AQHWL4VxmYvkCvDoNEmQ3Xkat3whdqiytyCggAALHOCAAAWDcIAAXREAgABKZfCAAAVCgIAAAypAgAANNoCAAAvxgIAAnLwAgAKNblCAAWx9AIAAV42QgAB2TjCAAw9dsIABloqAgAAlunA=
Date: Thu, 28 May 2020 16:55:47 +0000
Message-ID: <DM6PR05MB6348EBA8F4E6C889393B5269AE8E0@DM6PR05MB6348.namprd05.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> <MW3PR11MB4570FD37ED32519C677F5E59C1B20@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR05MB63486B842CD9DF5BE57FC1A5AEB30@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB45706D51FBE6CD63B58CDF15C1B30@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR05MB634848BE997686F212FF9E49AEB30@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB457006B3ECAF2E812CD2E721C18E0@MW3PR11MB4570.namprd11.prod.outlook.com> <df0b518a11734e8f91dc2c0902f46df5@nokia-sbell.com>
In-Reply-To: <df0b518a11734e8f91dc2c0902f46df5@nokia-sbell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-25T03:32:27Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fce2e8ee-c77f-4352-852c-4509f560098b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
authentication-results: nokia-sbell.com; dkim=none (message not signed) header.d=none;nokia-sbell.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 9250eb98-03c5-4511-f715-08d80327f858
x-ms-traffictypediagnostic: DM6PR05MB4939:
x-microsoft-antispam-prvs: <DM6PR05MB4939333DF433CA9F9BE293C7AE8E0@DM6PR05MB4939.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bZjMELmUVmjg7cY8lleE4xsLwdrCFfudcrGy8DQdTJCKjPkX10qL34DAL4ulR1XvSk9I/mBVlpDTFL44KUWFCP4491K2jtrYW7+aOG7gvxaVUsX6PTepfGPjP7BWNTFdGc/MEJlklpbzJlGNONBiJb30njZlDnSoqlbnd6wlLtqFhKFcR2hOeNlvkX6GtqCNPTNcxCb5t4Ve+id5m59TLKLe5ATRoCxYO1Cy46BmKPZP6CI3S/wvC6yWiNV67mgyoj96aoum8MdAmc/lMQPSaYNJVK991P5WWk8g3jwF8r0z3y8g88HhUj5yKfdHrNTX9J8ALyVgiUgB88C4nf0ItMNJDunQT5GxHTT6gW4X0EPC86vo3JZZBRI9q0bqtzpgXRM6GA3vE6xBgRVAnB5x5A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(26005)(966005)(7696005)(54906003)(110136005)(316002)(53546011)(6506007)(5660300002)(33656002)(86362001)(71200400001)(2906002)(9686003)(66946007)(8676002)(66476007)(66556008)(64756008)(66446008)(52536014)(76116006)(55016002)(186003)(83380400001)(478600001)(4326008)(8936002)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xi7yPSd9FYH2btnGDkfgZIpFG5bRw4TqAugIdZHTRjLI8YfM0Vsm5nv4qf47xcHOHVpJlY967A+P0jMWBz35pkAV36fY0laBQuyFbXLxQ2ZRivtjLHDInRV5RHU3gnHRLQdlU6GqjMXKnkcnAPeM+QhBwss7u9UAbUlwAk5NHaXTyOoDOR/cIRVnM41UJLEUeJCXpUkMNfpmU3UaQqZ+C4sISLbKsuvdPjkcwIL3nIXq5Pul4WObeSCFMafZ8ER5Z6qeaxyw/XjbTJ4g1XanqvXMBQMyDjFdbhtKWfA6cEZcWlPaOxLGozSKuqc44Y+R1x5A7jqAziBXK15UjvifX/UCk4AiNnHzq9BcnVflsOGTuI+BaTFfTd42BNjmJPpevTK/bDh09/Q22uadjWJbU9Z+mMMtPC8swp5lvwbY6AuqcjRTjRn/MWLXNJ8ODLBylpzV21Ypii0ikR35tfh1wL+3faG+Cv5naD5EKe61AMps+RmrYGHRZ3Vbdfaa1Q8c
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348EBA8F4E6C889393B5269AE8E0DM6PR05MB6348namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9250eb98-03c5-4511-f715-08d80327f858
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 16:55:47.6583 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: C9r3rHdidp7EUaaL0+OBGWCKoE+kljamfachYZDzzQEjO6d+eWHEdtuYfFiWVM7ta+R4Q2pX5aaKmQHScZSFLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4939
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-28_03:2020-05-28, 2020-05-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 adultscore=0 clxscore=1011 suspectscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 cotscore=-2147483648 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005280116
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/h1cs4W_ndAZWaLcMla-eiiCkr8I>
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, 28 May 2020 16:55:56 -0000

Weibin,

Inline…..

                     Ron




Juniper Business Use Only
From: Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>
Sent: Thursday, May 28, 2020 10:35 AM
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Ron Bonica <rbonica@juniper.net>et>; Joel M. Halpern <jmh@joelhalpern.com>
Cc: rtg-ads@ietf.org; spring@ietf.org; 6man <6man@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]

Hi Ron,

After reading through many mails related to CRH in list, I found all CRH-SIDs (allocated to prefix-sid <loosely forwarding>and Adj-sid<strict forwarding>) are of local significance in fact, its operation actually is not same as MPLS Label nor SR-MPLS label (such as domain-wide prefix SID/label), all CRH-SIDs are locally allocated by node itself based on local FIB6, independent of other CRH-SID allocated by other nodes in CRH domain; so every node (Maybe except  ingress PE of CRH domain)  has no useful to learn other SIDs allocated by other nodes by IGP-extension advertising. Its deployment must have controller (considering dynamic mechanism), the controller learn all CRH-SIDs from each node to program the source path under path calculation requirement from ingress PE.

[RB] Absolutely correct !!


I suggested you should describe more detail about how to create CRH-SID entry (in CRH-FIB) in this CRH draft, is it based on local FIB6, if it is, how to do synchronization between CRH-FIB and FIB6?

[RB] In some deployment scenarios, the IPv6 FIB and the CRH-FIB are populated by an IGP. Please review and comment on the IS-IS CRH document<https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/>s/>. I am excited to collaborate with you on that .

[RB] In other deployment scenarios, the IPv6 FIB and / or the CRH-FIB are populated by a controller. If you are interested in that scenario, again, we would be excited to collaborate with you.

                                                   Ron


Above is my understanding, if not right,pls correct me.

Wang Weibin

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Ketan Talaulikar (ketant)
Sent: 2020年5月28日 19:46
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
Cc: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH


Hi Ron,



Some of the operators may not care about the SR name, but it is clear to me that the proposal in the CRH draft is a subset of Segment Routing (i.e. a reduced portion of Spring Architecture) that only supports prefix and adjacency SIDs as indicated by the two "forwarding methods".



https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$>


   o  Forward the packet to the next-hop along the least-cost path to >>> Prefix SID
      the next segment endpoint.

   o  Forward the packet through a specified interface to the next >>> Adjacency SID
      segment endpoint.



Given the use of mapping IDs and mapping FIB, the proposal is comparable more to SR-MPLS than SRv6. It is better to do a holistic analysis of any proposal such as CRH that is introducing an MPLS label like mapping construct into IPv6 architecture - doing so should be considered as a significant change to IPv6.



Thanks,

Ketan



-----Original Message-----

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>

Sent: 25 May 2020 21:14

To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>

Cc: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto:6man@ietf.org>>

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



Ketan,



It would not be fair to say that these operators  "wish to deploy a Traffic Engineering solution using a subset of Segment Routing".



It would be fair to say that these operators  "wish to deploy IPv6 Traffic Engineering".  Some of these operators don't care about SR. Some are actively averse to SRv6. All they want is a Routing header.



                                                                 Ron















Juniper Business Use Only



-----Original Message-----

From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>

Sent: Monday, May 25, 2020 5:21 AM

To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>

Cc: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto:6man@ietf.org>>

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



[External Email. Be cautious of content]





Hi Ron,



Thanks for that clarification.



I note that you are not anymore saying "Are not interested in SR" like you had mentioned before the WG adoption call : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>



So, would it be fair to say that the operator that you are referring to below, wishes to deploy a Traffic Engineering solution using a subset of Segment Routing (i.e. a reduced portion of Spring Architecture) that only supports prefix and adjacency SIDs as indicated by the two "forwarding methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?



Thanks,

Ketan



-----Original Message-----

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>

Sent: 25 May 2020 09:03

To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>

Cc: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto:6man@ietf.org>>

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



Ketan,



Please consider an operator who:



- Wants a way to steer IPv6 packets through a specified path that includes many nodes (>8)

- Does not want any of the following:

        - A new VPN encapsulation technique

        - A new service function chaining technique

        - Network programming

        - MPLS and uSID

        - To encoding instructions in IPv6 addresses.



These operators want a compact routing header, nothing more.



                                                                           Ron





Juniper Business Use Only



-----Original Message-----

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Ketan Talaulikar (ketant)

Sent: Sunday, May 24, 2020 1:42 AM

To: Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>

Cc: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto:6man@ietf.org>>

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



[SNIP]



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.





[SNIP]

------------------------------------------------------