[spring] A note on CRH and on going testing

Andrew Alston <Andrew.Alston@liquidtelecom.com> Thu, 19 September 2019 09:49 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 5562F120803 for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 02:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 eqQUggbgRmLr for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 02:49:29 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.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 F1DCF1200C4 for <spring@ietf.org>; Thu, 19 Sep 2019 02:49:28 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2056.outbound.protection.outlook.com [104.47.13.56]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-22-eQGx9wKjOTi977S9X9_2-g-1; Thu, 19 Sep 2019 10:49:25 +0100
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5461.eurprd03.prod.outlook.com (20.179.45.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Thu, 19 Sep 2019 09:49:23 +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; Thu, 19 Sep 2019 09:49:23 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: 'SPRING WG List' <spring@ietf.org>
Thread-Topic: A note on CRH and on going testing
Thread-Index: AdVuzdRMlDKEMMI0RQuelvHh3plxxw==
Date: Thu, 19 Sep 2019 09:49:23 +0000
Message-ID: <DBBPR03MB5415ED83D18E1F7B08F218A3EE890@DBBPR03MB5415.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [197.155.81.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9fa6e572-760c-4622-bb1b-08d73ce6a713
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:DBBPR03MB5461;
x-ms-traffictypediagnostic: DBBPR03MB5461:
x-microsoft-antispam-prvs: <DBBPR03MB5461DCBE378D6489F664CBAEEE890@DBBPR03MB5461.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(346002)(376002)(39860400002)(396003)(366004)(199004)(189003)(66446008)(186003)(66476007)(256004)(64756008)(86362001)(66574012)(66556008)(33656002)(76116006)(66946007)(476003)(478600001)(6506007)(102836004)(71190400001)(71200400001)(7696005)(25786009)(5660300002)(486006)(26005)(99286004)(52536014)(14454004)(6916009)(55016002)(10916006)(66066001)(9686003)(8676002)(81156014)(81166006)(316002)(6436002)(305945005)(7736002)(8936002)(74316002)(6116002)(3846002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5461; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dE+Tp5EhqAbx8f2hfQygU2E5nScNo2zHj6y9HpJNDlGPUzhJ/+eREDM5GA5DBjLjsihBBsmxquNY/eXUFLq49w6uJgBAhDIhq/K07BkjtzILMTJ1ZhUP31DQDNjNxPOdT1ikOZBS9xOuCObaw5v7HC2bZCc7W2ZP63jDSWNt7jYWMUMez6k0H5ecGGOD8k3wSY+uXpdo/lo38dLUlsMCqqcW9lnf+GR3rtXllZhoBBxGIjsui6j0OQDx1p9S5zTAaSgH2WNn9g7YYngP4aWAjp92hDZj6PAgg5D9/haKxG4/QpB9czYlIn9SM/G/HBziN7HGniiWJT+mWxlKDINf+hSGxHybnl76/MxHRA4Or/0K1vXKlAsp6Hm3CmlOSJR4lpKl/YgPPPDcCavrfu+s0v+DOXJxxBuEBfzJosS5ZmU=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fa6e572-760c-4622-bb1b-08d73ce6a713
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 09:49:23.8517 (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: xLxnw4oAbAF5M4V2sTl44yO6QpXtCyhFbVyLMq/hJO/lTUdH6eU/Ym3pM17rIqt522EPdrA6Y0XxVOa3k2OOzY8PkN69ZWDbBF/9gY0BRxQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5461
X-MC-Unique: eQGx9wKjOTi977S9X9_2-g-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/KeWOkXeN9JPv8acD1oC99qjdsxU>
Subject: [spring] A note on CRH and on going testing
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: Thu, 19 Sep 2019 09:49:32 -0000

Hi Guys,

I thought this may be of interest in light of discussions around deployments and running code - because one of the things we've been testing is inter-domain traffic steering with CRH on both our DPDK implementation and another implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 -> S6
3 systems in a lab on the other side of the world - no peering between the networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, with the relevant mappings from the CRH SID's to the underlying addressing (S2 had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.  

What this effectively means is that if two providers agree to share the SID mappings - it is possible to steer across one network, out over an open path, and across a remote network.  Obviously this relies on the fact that EH's aren't being dropped by intermediate providers, but this isn't something we're seeing.

Combine this with the BGP signaling draft - and the SID's can then be signaled between the providers - work still going on with regards to this for testing purposes.  Just as a note - there would be no requirement to share the full SID mapping or topologies when doing this with BGP - the requirement would be only to share the relevant SID's necessary for the steering. 

I can say from our side - with various other providers - this is something that we see *immense* use case for - for a whole host of reasons.

Thanks

Andrew