Re: [spring] A note on CRH and on going testing

"Bernier, Daniel" <daniel.bernier@bell.ca> Thu, 19 September 2019 15:36 UTC

Return-Path: <prvs=158426171=daniel.bernier@bell.ca>
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 D6E7512012A for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 08:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gfaozGnYgZnm for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 08:36:14 -0700 (PDT)
Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 BD446120144 for <spring@ietf.org>; Thu, 19 Sep 2019 08:36:13 -0700 (PDT)
Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG1MBX01-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 19 Sep 2019 11:36:12 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX01-WYN.bell.corp.bce.ca (2002:8eb6:120b::8eb6:120b) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 11:36:12 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca ([::1]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::39a2:98d1:477c:3365%22]) with mapi id 15.00.1473.003; Thu, 19 Sep 2019 11:36:12 -0400
From: "Bernier, Daniel" <daniel.bernier@bell.ca>
To: SING Team <s.i.n.g.team.0810@gmail.com>
CC: 'SPRING WG List' <spring@ietf.org>
Thread-Topic: [EXT]Re: [spring] A note on CRH and on going testing
Thread-Index: AQHVbv1yBp9qOug3bUqxg3rQMHPVi6czIfSA
Date: Thu, 19 Sep 2019 15:36:11 +0000
Message-ID: <20625BDC-2D90-4E35-96E3-2BC4B723C06E@bell.ca>
References: <1568906072231.1bkuswxveutxvlrzmmzkgs2g@android.mail.163.com>
In-Reply-To: <1568906072231.1bkuswxveutxvlrzmmzkgs2g@android.mail.163.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.e.190909
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.1]
Content-Type: multipart/alternative; boundary="_000_20625BDC2D904E3596E32BC4B723C06Ebellca_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4E11BDGlwvEIzRikz_CAQwVpP8w>
Subject: Re: [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 15:36:17 -0000

+1

This is what we did on our multi-cloud trials.

Encap with Binding SID to avoid inter-domain mapping + I don’t need to have some sort of inter-domain alignment of PSSIs

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org> on behalf of s.i.n.g.team.0810@gmail.com<mailto:s.i.n.g.team.0810@gmail.com>> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston<mailto:Andrew.Alston@liquidtelecom.com> wrote:
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


_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/Spring