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

SING Team <s.i.n.g.team.0810@gmail.com> Thu, 19 September 2019 15:15 UTC

Return-Path: <s.i.n.g.team.0810@gmail.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 B04DC120099 for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 08:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.377
X-Spam-Level:
X-Spam-Status: No, score=0.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.103, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zsSCgeAk8tNS for <spring@ietfa.amsl.com>; Thu, 19 Sep 2019 08:15:09 -0700 (PDT)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFA112000F for <spring@ietf.org>; Thu, 19 Sep 2019 08:15:09 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id h195so2535637pfe.5 for <spring@ietf.org>; Thu, 19 Sep 2019 08:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:cc:date:mime-version:message-id; bh=x0JEBGzeeL4kEi9V4/2PLvFr9VBeGh7iRDZrMEs9q44=; b=U640yDqPcS9Nr87eNwlpcHdhzOJ1LaHgBlBsI7mzLZr89yVXdSOSKIse9wCfKNhJ9J qc2yeGKqxD7e0JvMX1ybDdFwBgASkZXpRjnZZq7aQF04nJUw96QbOPbfkeqM29LR6rXk Ogt8CYodC4JNa+RbO5kKVZquD/mAIWf7Sa+CKCRjTieIkadowmsq4ejzzHdublcrjciq y6IsEAukUsiYvQvxQedIXE5B6di6ufxOIaum64dbm5e/HIp1egveuBP20dG9Li2ZtGvI ixm0HWMlnabHZ20YP3jpvPEUSl/fp5FxZgMNXrVUneunIp8lNfJmmPgj91cdY6sIIXLI aHPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:cc:date:mime-version:message-id; bh=x0JEBGzeeL4kEi9V4/2PLvFr9VBeGh7iRDZrMEs9q44=; b=h9heAErwBm2qmJhGKBWTa8CXsw2ZOHNfKaMNxfOU/e9MLbs79ixWFjGWTr4578Ji35 TM+zslN7EEcuP19BlRdBLx6huVzX4GCHHp7E2zS4ssjN4DgG3VyvC1uk9PZA01dS+jVi LVgFxoZpOcpeeHcJrxYCxitrVrxQ+UZ623GEabwfBFuqGDKD+FNn9GkonwTPHuUGOguM b1cVXqbK9yxkR65SdxMBVAEAvOA0Dl160ft2ZzIa7o9VYiJCbi49CkxDmQ86HNX2Dti+ 3jl2DfBbIf6wWsJwjhUggaG+HMDoWQ3dYBlFwCAuGwIe1OhDAP3AjhpMO9gz5LMV4Ht5 roCg==
X-Gm-Message-State: APjAAAVEMA+TszsH0I2rDz0u/pGA4J5FCLYMKT/1BZoLxH03Gm+6ynjU /FwWU4vEsi10MetuJkZ7nNxyQegO
X-Google-Smtp-Source: APXvYqw23i6BYZJD7B9ek860KIAk1qZkgGcehkWt+NZj/LZm3aOPe581EvjSefvldLul0zN2D8sWYA==
X-Received: by 2002:a17:90a:26e3:: with SMTP id m90mr4288728pje.57.1568906108890; Thu, 19 Sep 2019 08:15:08 -0700 (PDT)
Received: from localhost ([103.129.252.49]) by smtp.gmail.com with ESMTPSA id b20sm18411941pff.158.2019.09.19.08.15.06 for <spring@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2019 08:15:07 -0700 (PDT)
From: SING Team <s.i.n.g.team.0810@gmail.com>
Cc: 'SPRING WG List' <spring@ietf.org>
Date: Thu, 19 Sep 2019 23:15:06 +0800
MIME-Version: 1.0
X-Priority: 3
Message-ID: <1568906072231.1bkuswxveutxvlrzmmzkgs2g@android.mail.163.com>
X-CUSTOM-MAIL-MASTER-SENT-ID: MailMasterAndroid-1565-1568906103953-1a6fb468-70ca-4599-b589-1c9418b94c0e
Content-Type: multipart/alternative; boundary="__MESSAGE_BODY_PART__1_8769928046862344648"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2sxvSMVQqXHVH02S5yvjkYGO0VI>
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:17:43 -0000

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 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  https://www.ietf.org/mailman/listinfo/Spring