Re: [spring] “SRV6+” complexity in forwarding

Andrew Alston <Andrew.Alston@liquidtelecom.com> Tue, 17 September 2019 17:43 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
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 653DB12086C for <spring@ietfa.amsl.com>; Tue, 17 Sep 2019 10:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 Ci7HbfnJ-Jtw for <spring@ietfa.amsl.com>; Tue, 17 Sep 2019 10:43:04 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC798120864 for <spring@ietf.org>; Tue, 17 Sep 2019 10:43:03 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2057.outbound.protection.outlook.com [104.47.14.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-15-QvLBydFzOIyY1LGDOWmyFg-1; Tue, 17 Sep 2019 18:42:58 +0100
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5190.eurprd03.prod.outlook.com (10.255.78.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Tue, 17 Sep 2019 17:42:56 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::fd1a:fcdd:6a6d:1409]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::fd1a:fcdd:6a6d:1409%5]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 17:42:56 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Darren Dukes (ddukes)" <ddukes@cisco.com>
CC: Rob Shakir <robjs@google.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Robert Raszuk <robert@raszuk.net>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, Tarek Saad <tsaad.net@gmail.com>
Thread-Topic: “SRV6+” complexity in forwarding
Thread-Index: AQHVbM6oRpgVWBK/tUuHKLM4QbpaPKcvHWUAgAE6GQA=
Date: Tue, 17 Sep 2019 17:42:56 +0000
Message-ID: <C8A5898E-CF37-4B0A-AFCC-516EDEC8044C@liquidtelecom.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54632F09C712ADB30138CFA9AEBE0@BYAPR05MB5463.namprd05.prod.outlook.com> <BYAPR19MB3415D21403394F8129A4BAD8FCB90@BYAPR19MB3415.namprd19.prod.outlook.com> <30491F13-C652-45C3-AB2B-95F765FBB4EA@juniper.net> <65C5CB04-3A2F-4F83-A7C8-2045154F93AE@cisco.com> <BYAPR05MB5463EC3250F2A303A3641839AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <91CBADAD-EFE6-46E1-A9D3-DAA111357179@juniper.net> <CAOj+MMGyUFRPDqCBo5SbLX486o_9GLpM6Zxf8KSt1voWiqhkGQ@mail.gmail.com> <E8D473B5-3E8D-4339-9A79-0CAE30750A55@juniper.net> <CAOj+MMFOy5PyTo=jPJkVrQOctdWjsTbD=7ix-2n89vodKzT3gQ@mail.gmail.com> <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com> <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com> <201909120857387140042@chinatelecom.cn> <1568259664564.62561@bell.ca> <CAO42Z2wQ_8GEE+=nAMFBj+ape9Vf7fARVoOwGdCiUxdffkyXgw@mail.gmail.com> <BYAPR05MB5463A04B05B4BD6AA294F7F0AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <6EA6F7C0-BEB2-4749-A6AB-62B1337213B2@cisco.com> <BYAPR05MB5463426F1668202EE5F183EFAE8F0@BYAPR05MB5463.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB5463426F1668202EE5F183EFAE8F0@BYAPR05MB5463.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
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-17T01:59:12.1392774Z; 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=3dca3a38-fef0-4171-8438-7d7fdc0809a7; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-originating-ip: [197.155.81.37]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 40342a05-3317-4ff0-de37-08d73b96798f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DBBPR03MB5190;
x-ms-traffictypediagnostic: DBBPR03MB5190:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DBBPR03MB51908C604C2BB65CA015CFA2EE8F0@DBBPR03MB5190.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1728;
x-forefront-prvs: 01630974C0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(189003)(199004)(606006)(6306002)(54896002)(256004)(3846002)(236005)(476003)(25786009)(6246003)(6486002)(4326008)(5660300002)(229853002)(6436002)(86362001)(76176011)(6116002)(99286004)(71200400001)(71190400001)(66066001)(11346002)(446003)(58126008)(53546011)(6506007)(2616005)(102836004)(316002)(6512007)(186003)(966005)(81156014)(81166006)(26005)(14454004)(54906003)(110136005)(7736002)(486006)(33656002)(478600001)(66476007)(66556008)(64756008)(66446008)(10916006)(36756003)(91956017)(76116006)(8936002)(2906002)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5190; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: QQo4IDqMZPYQGxWb4RHYy43CfV3qD7VYNVktrhX0xhftYGIxhzGeBQ5zuy4NbHP8LnWRUni4i8gAMmBEt/InJFc/U7WEImYdRxCc65MLT/nml3Agh55tgWQbgUjU7AhMpMmtz2NNEfFkQqOvLUO+6V4Du4RGjXPnVsXiO6k1aOZK+V1TXMrDRpwWZaS6NYQMDS4xpcDIC/90qVsPiwNkAMOP9NGsPEakTbcmT8CwX1OpU0azpofTmY1ZeCyf1fAznKZhb3Swi1NLBBuTzLSYC+/prUegG1NPTFTUMfcok1fYb4D4z6NPQP15XT2sSxlkdWA0AHqkoneo1PlL9ckspXBx35EM3qhmn8ERrNYc+o18rOPjZ2kz5WC9qNR0YdVrrD3uwOqLXIpp4Nfv85bd34i5cyUqMD25vJrKsd1UqXY=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 40342a05-3317-4ff0-de37-08d73b96798f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 17:42:56.3901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4RZ/EzB90sMxnO009ufmTwOlFM2IBczXCE9AyDx8FNonu3WQlu2BN1vap/GAhYMMp5k6qwx6FQ/43xXdsoOh/z3htSfiagIARqQhpcWEHiU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5190
X-MC-Unique: QvLBydFzOIyY1LGDOWmyFg-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_C8A5898ECF374B0AAFCC516EDEC8044Cliquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/yI0LuB7hAJyjl7KotYLXF2QbIwA>
Subject: Re: [spring] “SRV6+” complexity in forwarding
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: Tue, 17 Sep 2019 17:43:07 -0000

<snip>


  *   You also suggest that Juniper’s is the only implementation. Are you sure that this is correct?


There is a packet capture of CRH for anyone who is interested taken from our DPDK implementation – in this case – this is from the source node of traffic – steering through nodes 3 -> 2 -> 5 -> 5 -> 1 in our lab setup.

https://www.gont.com.ar/packets/CRH.cap<https://www.gont.com.ar/packets/CRH.cap?fbclid=IwAR3gycrlv44jeEWQtRDifa189WdNG9fJ0uNpHer4hu7i_zGQfoyByObectY>

So – there is certainly more than just Juniper working on this.

Thanks

Andrew





Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes@cisco.com>
Sent: Monday, September 16, 2019 4:38 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Mark Smith <markzzzsmith@gmail.com>; EXT - daniel.bernier@bell.ca <daniel.bernier@bell.ca>; xiechf@chinatelecom.cn; SPRING WG <spring@ietf.org>; 6man <6man@ietf.org>; Robert Raszuk <robert@raszuk.net>; Rob Shakir <robjs@google.com>; Tarek Saad <tsaad..net@gmail.com>
Subject: “SRV6+” complexity in forwarding

Hi Ron, I agree ASICs are always improving, indeed this is evident in the number of successful SRv6 deployments and multiple vendor implementations at line rate on merchant silicon, and multiple vendor ASICs.

Is “SRv6+” (PSSI+CRH+PPSI) implemented and deployed at line rate?
You’ve been asked this several times.  Since you’re the only implementor(?) and one operator is claiming deployment or testing, I am curious.

Regardless of ASIC capabilities there are two performance penalties you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.

Requiring all segments in a CRH segment list to process an arbitrary length DOH+set of PSSI’s and other options is always very expensive.
- It is expensive in SRAM as previously discussed in these threads.
- It is expensive in parsing logic to know and process a set of TLVs in any ASIC or NP.

Spreading PSSI, CRH, PPSI operations in multiple headers and multiple identifiers you now have multiple lookups at a node.
1 - lookup destination address
2 - lookup one or more PSSI and future destination options.
3 - lookup the CRH label or PPSI label.
4 - lookup new destination address

Compare this with SRv6.
1 - lookup destination address
2 - lookup new destination address

While ASICs are more capable and will continue to be more capable, these technical performance problems you introduce with PSSI+CRH+PPSI will not go away.

Darren

On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote: