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

"Chengli (Cheng Li)" <chengli13@huawei.com> Fri, 20 September 2019 02:49 UTC

Return-Path: <chengli13@huawei.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 E12441200C5 for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 19:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 LBm7jnyJQ94Y for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 19:49:37 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1A27C12003E for <spring@ietf.org>; Thu, 19 Sep 2019 19:49:37 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 747B2621819E84A6D2D0; Fri, 20 Sep 2019 03:49:35 +0100 (IST)
Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 20 Sep 2019 03:49:34 +0100
Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 20 Sep 2019 03:49:34 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 20 Sep 2019 03:49:34 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.58]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0439.000; Fri, 20 Sep 2019 10:49:26 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: "Bernier, Daniel" <daniel.bernier@bell.ca>, SING Team <s.i.n.g.team.0810@gmail.com>
CC: 'SPRING WG List' <spring@ietf.org>
Thread-Topic: [spring] A note on CRH and on going testing
Thread-Index: AQHVbv3Xlk2MR63jbkCBydINl8HjY6cym9WAgAE+RPA=
Date: Fri, 20 Sep 2019 02:49:26 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB026DDDBE@dggeml529-mbx.china.huawei.com>
References: <1568906072231.1bkuswxveutxvlrzmmzkgs2g@android.mail.163.com> <20625BDC-2D90-4E35-96E3-2BC4B723C06E@bell.ca>
In-Reply-To: <20625BDC-2D90-4E35-96E3-2BC4B723C06E@bell.ca>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.185.75]
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB026DDDBEdggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DjPiCKhcuHoTTW8znE7MzahYbR0>
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: Fri, 20 Sep 2019 02:49:40 -0000

+1.

As I mentioned before, Binding SID is not only for shortening SID list.
We should see the important part of binding SID in inter-domain routing,  since it hides the details of intra-domain. Security and Privacy are always important.

Since the EH insertion related text will be removed from SRv6 NP draft, I don’t think anyone will still say we don’t need binding SID.
Let’s be honest, Encap mode Binding SID is very useful in inter-domain routing. It is not secure to share internal info outside a trusted network domain.

Cheng


From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team <s.i.n.g.team.0810@gmail.com>
Cc: 'SPRING WG List' <spring@ietf.org>
Subject: Re: [spring] A note on CRH and on going testing

+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