Re: [spring] Beyond SRv6.

Ron Bonica <rbonica@juniper.net> Sun, 01 September 2019 21:10 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4BB1200B3; Sun, 1 Sep 2019 14:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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
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 C7n4VYBtMhWt; Sun, 1 Sep 2019 14:10:42 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 E2F7512008A; Sun, 1 Sep 2019 14:10:42 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x81LAQ5m028547; Sun, 1 Sep 2019 14:10:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=QNyWraz141Iy9wgMd7BS1z65btGbsT1He54eADCvG6w=; b=HReatA7mwoT8NS3sBY217UG9WheMhC4TJHBcG4o9lW4otaGFMBOrHp7pLsfcgWnjNeYp 6xK7+Y/v6PVi7KQqvG+ZLj5uMtf7EdFSMcYwcBb5Wh1S1xKFOCyC7Vmx9msSK45gSHOr H6z1uHv8RtISwtFsdA3Z1jm7Y3G0IGe4xjWkVBhH94BMX8CJ1oKNQTtlpueupKo+LxAw asi2XGj3xtKZx5/xPA77I0BfLKbSTUXfqUvCTH5aAStlBS/7LXRhwnFKJ4oxZRDEiUHg C5tSZKO+th+uMESI1N6/1piAbAyppD/nStFSfNgEXChLnf9gz+dxbptDJRCXS6GSLVK+ zg==
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2055.outbound.protection.outlook.com [104.47.49.55]) by mx0a-00273201.pphosted.com with ESMTP id 2uqqwn1trp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 Sep 2019 14:10:36 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NNkg5W7VVZaryQLen6fwLkfvT0x2v2YCbNnNdIDGsVJ03OEakuUa9vy70pkDBbPM/Rp8oMYEb50CGd9ses35yeFoQ9dFhBhJ0NNWOfLNuW4vZ4GDBYnxu3NAIHwxDAtCvtivk1Ux/I6dy6mLVkw+KZbjk66IfsI86NJ/aBzVbEiRtBxckZ4pVMcc39QQGHXdnthZcyCyYdIrfUP8ZCnLY0xuiuMJ1i7oFl7wuM/bFVQAHxHg118mdHraueOwQoN5J9wzZqEArkmHyehVBdaQmN3lYYy4C8zXVuiqFLUt8hVn4oaePu76yX4Fy0C/jqO1wQcl0Rl4jUUcl3uMSTS9Sg==
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=QNyWraz141Iy9wgMd7BS1z65btGbsT1He54eADCvG6w=; b=BjXqV1729MSD4072HCP/atiEzShYQ9G3Bs3a3SQK/rstOFo752at0qw03QLBQ7cC4ShjWqvzDrIlotFrmVfNRxBSQFwAREIhgBLE5f7KN20P8ezc7uWm8ddGoy4A2RiLV6ATZhcdFb4zucp9QM36pwFI4R0+/ffEEBsMPvVi/Gq7bx7FxU/h5XFI46s6QcG536ofsS0xN3tTvBcI6BHdvzPCTIdiA2PQvjtJWaTVBSJ9fGe6kM5dy/ywpzsigriMOFAje5nTTYOQ34rsshgTmIV8JLfSBD2HHcqsIxWvoqtwlbD0soSS+hqeUZBDhYKj7/8HHBFnGgreqF3klVcdSg==
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
Received: from BL0PR05MB5458.namprd05.prod.outlook.com (10.167.235.207) by BL0PR05MB5410.namprd05.prod.outlook.com (10.167.234.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.5; Sun, 1 Sep 2019 21:10:33 +0000
Received: from BL0PR05MB5458.namprd05.prod.outlook.com ([fe80::b141:6d9:9b50:f0b3]) by BL0PR05MB5458.namprd05.prod.outlook.com ([fe80::b141:6d9:9b50:f0b3%6]) with mapi id 15.20.2220.020; Sun, 1 Sep 2019 21:10:33 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Fernando Gont <fgont@si6networks.com>, Rob Shakir <robjs@google.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwgt98swpc9VGEiHCF6pCt7E6qcVwfowgAAkGwCAAY+IsA==
Content-Class:
Date: Sun, 01 Sep 2019 21:10:33 +0000
Message-ID: <BL0PR05MB5458C00081B05584E77DB19DAEBF0@BL0PR05MB5458.namprd05.prod.outlook.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54630831722DE1D3E6C7F872AEBC0@BYAPR05MB5463.namprd05.prod.outlook.com> <abded144-7557-1093-874c-0f9ca708af6a@si6networks.com>
In-Reply-To: <abded144-7557-1093-874c-0f9ca708af6a@si6networks.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_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-09-01T21:10:31.6676821Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e6528dc8-9509-4dc0-b6bd-e134d92b8597; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 16b80f67-cdea-4574-5a59-08d72f20d3b5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR05MB5410;
x-ms-traffictypediagnostic: BL0PR05MB5410:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <BL0PR05MB541098E84F7579CF0CEB1FD3AEBF0@BL0PR05MB5410.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0147E151B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(39860400002)(136003)(366004)(13464003)(199004)(189003)(74316002)(3846002)(76116006)(7696005)(8676002)(81156014)(86362001)(81166006)(66476007)(66066001)(52536014)(229853002)(26005)(2906002)(6246003)(55016002)(25786009)(5660300002)(6306002)(53936002)(66446008)(64756008)(9686003)(30864003)(66556008)(33656002)(478600001)(186003)(14454004)(53546011)(6506007)(102836004)(446003)(476003)(11346002)(14444005)(256004)(71200400001)(71190400001)(486006)(2501003)(966005)(110136005)(99286004)(316002)(76176011)(8936002)(66946007)(6436002)(305945005)(7736002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB5410; H:BL0PR05MB5458.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yYA8ukNhXunarbOkdVTOZlcUpzOtDDPIua1sYlckVsDEPYbq9/Qdw8oRnV/obuqe2GwEsSeqQ00SpgYFL4nwfRWWVz5RJnJvczobaaCCTiz4ReWDQzKWm57gysJ0rxdASEZmUXIy5uwqI2xSZw3XQJGOoWVMpeYY0qys5fDW7+5JzzEWqEs4NhFL27u0OdpYAV3bJuoz/gkSgMPM1dKVfMBOCWL44FjqrXgeZgFplI/8b7zs5oJT9ucMPYteHhgGk/E/ItAEDptGzYzWzdKD3Nc1dx7DC0ghmPLm7CJ94L10o68hqVw05rOnFRxLk3IHcoXPHMykMb5wUoJuCHcX4p3i4ajhRe+p8NmAM+OoKJQU/DwQYBtd4KXvcoqfNXZeQwH4Wt4noKhEQwwm1YEhBaeg044prpsFhfD64rFr8EE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 16b80f67-cdea-4574-5a59-08d72f20d3b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2019 21:10:33.1532 (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: Kbr59+BHVlHi3nSkXFh07nKPcRQYRavDGARpgvYE+e5aCLnI7wX9xmYIR3jd9DNY+1KrnBcLRobPQh4DtQKZig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5410
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-01_07:2019-08-29,2019-09-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 mlxscore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=999 malwarescore=0 spamscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909010244
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/qHaIDVDohwA-C6zI7BU7XJBKZ58>
Subject: Re: [spring] Beyond SRv6.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 21:10:46 -0000

Hi Fernando,

6man participants should look at the following:

- https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 (In particular, Sections 4 and 5)
- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

                                                                                             Ron


Juniper Business Use Only

-----Original Message-----
From: Fernando Gont <fgont@si6networks.com> 
Sent: Saturday, August 31, 2019 4:53 PM
To: Ron Bonica <rbonica@juniper.net>; Rob Shakir <robjs@google.com>; SPRING WG List <spring@ietf.org>; 6man@ietf.org
Subject: Re: [spring] Beyond SRv6.

Hi, Ron,

For those 6man-ers that have not been following the sprin work, could you please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly RFC2460), so I'm curious if there are any documents trying to do the same, or what.

Thanks!

Cheers,
Fernando




On 31/8/19 23:33, Ron Bonica wrote:
> Rob,
> 
>  
> 
> The following are arguments for proceeding with SRv6+:
> 
>  
> 
>   * Efficient forwarding with deep SID lists
>   * Operational Simplicity
>   * SRv6+ work may finish before SRv6
> 
>  
> 
> Efficient forwarding with deep SID Lists
> 
> ----------------------------------------------------
> 
>  
> 
> SR customers have stated a firm requirement to support SR paths that 
> contain 8 to 12 segments. They have also stated a requirement for 
> implementations to forward at line speed  and without consuming 
> excessive overhead bandwidth.
> 
>  
> 
> SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot 
> satisfy these requirements. In order to support an SR path with 8 
> segments, SRv6 would require a 128-byte SRH. Even if ASICs could 
> process such a long SRH at line speed, the bandwidth overhead would be prohibitive.
> 
>  
> 
> Therefore, one of the four solutions  that you mention below is 
> required to make SRv6 deployable. While 
> draft-ietf-6man-segment-routing-header is close to maturity, the four 
> competing solutions mentioned below are equally mature and should be given equal consideration.
> 
>  
> 
> The four solutions are SRv6+, uSID, draft-li and draft-mirsky.
> 
>  
> 
> Operational Simplicity
> 
> -----------------------------
> 
> Network operators strive for operational simplicity. By loosely 
> interpreting (and sometimes bending) the requirements of RFCs 4291 and 
> RFC 8200, SRv6 introduces architectural quirks that introduce 
> operational complexity. The following are architectural quirks of
>  draft-ietf-6man-segment-routing-header:
> 
>  
> 
>   * The Segment Routing Header (SRH) serves purposes other than routing.
>     Therefore, the SRH is sometimes required for packets that traverse
>     the least-cost path from source to destination
>   * The SRH and the IPv6 Authentication Header are incompatible.
>   * The IPv6 destination address determines whether an SRH is valid and
>     how it is processed. For example, if the IPv6 destination address
>     contains one locally instantiated value, the SRH might be processed
>     in one particular way, while if the IPv6 destination address
>     contains another locally instantiated value, the SRH might be
>     totally invalid.
> 
>  
> 
> Draft-ietf-spring-srv6-network-programming  promises more 
> architectural quirks. For example:
> 
>  
> 
>   * Segment endpoints can insert and/or delete IPv6 extension headers
>   * An IPv6 packet can contain two Segment Routing headers
>   * IPv6 packets are no longer self-describing. For example, the Next
>     Header Field in the SRH can carry a value of No Next Header, even
>     though the SRH is followed by Ethernet payload.
> 
>  
> 
> Other emerging drafts promise still more architectural quirks. For 
> example, in draft-ali-6man-spring-srv6-oam, implementations need to 
> examine the SRH even when Segment Left equals zero. This is because 
> the SRH has been overloaded to carry OAM as well as routing information.
> 
>  
> 
> Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid 
> requires network operators to obtain address space and number their 
> networks in a particular way to make routing work.
> 
>  
> 
> SRv6+ Work May Finish Before SRv6 work
> 
> --------------------------------------------------------
> 
> SRv6+  has been implemented on LINUX and is being implemented on JUNOS.
> Implementation experience demonstrates that specification is fairly 
> complete. For example, there is no need for an SRv6+ OAM document. 
> It's just IPv6 and IPv6 OAM just works.
> 
>  
> 
> Furthermore, the SRv6+ specifications adhere to a strict 
> interpretation of RFC 8200. Therefore, as they progress through the 
> working group, they won't need to overcome the objections that are 
> inevitably encountered when stretching the interpretation of a 
> specification that is so fundamental as RFC 8200.
> 
>  
> 
>       
>                                                                                                
> Thanks,
> 
>                                     
>                                                                      
> Ron
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Rob Shakir
> *Sent:* Sunday, August 4, 2019 5:04 PM
> *To:* SPRING WG List <spring@ietf.org>
> *Subject:* [spring] Beyond SRv6.
> 
>  
> 
> Hi SPRING WG,
> 
>  
> 
> Over the last 5+ years, the IETF has developed Source Packet Routing 
> in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) 
> and
> IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in 
> UDP or GRE.
> 
>  
> 
> These encapsulations are past WG last call (in IESG or RFC Editor).
> 
>  
> 
> During the SPRING WG meeting at IETF 105, two presentations were 
> related to the reduction of the size of the SID for IPv6 dataplane:
> 
>   * SRv6+ / CRH --
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=BN2DF-66SUZSxAadboFqg1MP1Drk_9bHoYZhGq8jZXE&e= 
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ&e=>
>   * uSID --
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=uAESJj-OvK22RpEy_P4-T9kubYyJm55Q4ba3mX4KDhY&e= 
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
> tml_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D
> 01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82si
> r-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieI
> C4dD_FL6s&s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ&e=>
> 
>  
> 
> During the IETF week, two additional drafts have been proposed:
> 
>   * https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=8cKoeToYaFKfdgCZAYjwm4PItthfOAV0YkfhL46p4e8&e= 
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=XWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-CrKs&e=> 
>   * https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=MAEp0tdnu5Q7Cs7V5XNblNjEKByN7mucnnDwiwKEqS0&e= 
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
> tml_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63
> rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2Efp
> HcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7
> FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&e=>
> 
>  
> 
> As we expressed during the meeting, it is important for the WG to 
> understand what the aims of additional encapsulations are. Thus, we 
> think it is important that the WG should first get to a common 
> understanding on the requirements for a new IPv6 data plane with a 
> smaller SID - both from the perspective of operators that are looking 
> to deploy these technologies, and from that of the software/hardware 
> implementation.
> 
>  
> 
> Therefore, we would like to solicit network operators interested in SR 
> over the IPv6 data plane to briefly introduce their:
> 
>   * use case (e.g. Fast Reroute, explicit routing/TE)
>   * forwarding performance and scaling requirements
> 
>       o e.g., (number of nodes, network diameter, number of SID required
>         in max and average). For the latter, if possible using both SRv6
>         128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would
>         typically be different (*).
> 
>   * if the existing SRv6 approach is not deployable in their
>     circumstances, details of the requirement of a different solution is
>     required and whether this solution is needed for the short term only
>     or for the long term.
> 
>  
> 
> As well as deployment limitations, we would like the SPRING community 
> to briefly describe the platform limitations that they are seeing 
> which limit the deployment of SRv6  In particular limitations related 
> to the number of SIDs which can be pushed and forwarded and how much 
> the use of shorter SIDs would improve the deployments .
> 
>  
> 
> For both of these sets of feedback if possible, please post this to 
> the SPRING WG. If the information cannot be shared publicly, please 
> send it directly to the chairs & AD (Martin).
> 
>  
> 
> This call for information will run for four weeks, up to 2019/09/03. 
> As a reminder, you can reach the SPRING chairs via 
> spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>and ADs via 
> spring-ads@ietf.org <mailto:spring-ads@ietf.org>.
> 
>  
> 
> Thank you,
> 
> -- Rob & Bruno
> 
>  
> 
> (*) As expressed on the mailing list, a 128 bit SID can encode two 
> instructions a node SID and an adjacency SID hence less SID may be required.
> 
>  
> 
>  
> 
> Juniper Business Use Only
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTL
> AQl7WlS4Dqso6C1dMTkxeio0&s=HzZWo8ryJvwtuP_GEiM0Hy52ogBtiaiDML21sxVzf1k
> &e=
> --------------------------------------------------------------------
> 


--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492