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

SING Team <s.i.n.g.team.0810@gmail.com> Sat, 21 September 2019 03:46 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 BDB3A12004A for <spring@ietfa.amsl.com>; Fri, 20 Sep 2019 20:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level:
X-Spam-Status: No, score=-1.738 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 a7yDcRuGQkBN for <spring@ietfa.amsl.com>; Fri, 20 Sep 2019 20:46:21 -0700 (PDT)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 312CE12003E for <spring@ietf.org>; Fri, 20 Sep 2019 20:46:21 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id z12so4932273pgp.9 for <spring@ietf.org>; Fri, 20 Sep 2019 20:46:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:cc:to:date:mime-version:message-id:references :in-reply-to; bh=m523MLfPFpoU0L9vG0Rgf/tzl113ekGmH2aNsxyCIjE=; b=TuEFzAqyBZAQhs24CrbA8UamdCMu4H3ggqtJ8NskYCwgt8sc3tOVMn1lErcFZAJG0A 5sUjj1Gkxy+Ol6+txjlHk70qHtuewpnuH4YiHyhVhNB7R5oGaBDxd3YDnNcOhnoNHnUF VwuLGXIBUdBw30uDXLPd/BB4ekBuCcpp3NKVPxaNWPS+pnQ5lTf9zkPtUUHPBk1hwXEi xsCMCjznXTvLEl08Q4JtcL4jUWPS+EMSAwdHTMUDHVbe7ZhH+hStp+mWLVC6DN/8IeSb 5VmOUFq6/KRxdXFsoGeUPZPgaT3EWkdosejr2Ydw2e3J9KS2H1XJ6K4rK7WvqJBJPBn4 alLw==
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:to:date:mime-version:message-id :references:in-reply-to; bh=m523MLfPFpoU0L9vG0Rgf/tzl113ekGmH2aNsxyCIjE=; b=IN70M14zOsiwpe4qJyArcUEIE+soo454w1Xh3utkVN1uphn8YvUiuz0FhLXqxniV+L Avnos6On03PR7X1xlOYjH9OWx34+Ys4SdPwHpjNkuw69xINC3nS2jXSYo25qVlZohFL9 8c9sig95SmD4hLhbhhYNQ3vouHw+r/5QsTpmI2MkdKlFszaIMl7bQKBK0znS2RZ1fiRA K7QV8vvTvA9Ed2g6wYDwoAfFpg3ghXJYB2DdxOalAwedG402YJwHr/x9CYGQQvFWX5OB +aTnwY4INExU9p/ZpYbRAR//obtQE9wxPEuuCQ6I1AMJkdEtb95mChczpb7Ekfs5GmD7 3Ttw==
X-Gm-Message-State: APjAAAUdoiZ/xcK5yHIGP58XMihJ4svMxQxYvHyvBUIxVZzJsoSLLlGj wbnqGRdti2HqS/U3t/pvz9s=
X-Google-Smtp-Source: APXvYqyEPF4kGoAQT+byUBa2dAKiooeu77heCa3d4H7VhKcWV0gXgnB01kD7xqeNi6E6wS+V9FXtFg==
X-Received: by 2002:a63:6803:: with SMTP id d3mr18138179pgc.183.1569037580593; Fri, 20 Sep 2019 20:46:20 -0700 (PDT)
Received: from localhost ([103.129.252.46]) by smtp.gmail.com with ESMTPSA id b5sm5874207pfp.38.2019.09.20.20.46.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Sep 2019 20:46:19 -0700 (PDT)
From: SING Team <s.i.n.g.team.0810@gmail.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "Chengli (Cheng Li)" <chengli13@huawei.com>, "EXT - daniel.bernier@bell.ca" <daniel.bernier@bell.ca>, SPRING WG List <spring@ietf.org>
To: Ron Bonica <rbonica@juniper.net>
Date: Sat, 21 Sep 2019 11:46:18 +0800
MIME-Version: 1.0
X-Priority: 3
Message-ID: <1569035481440.mlhhmijcsgraco5tapifot4m@android.mail.163.com>
References: <1568906072231.1bkuswxveutxvlrzmmzkgs2g@android.mail.163.com> <20625BDC-2D90-4E35-96E3-2BC4B723C06E@bell.ca> <C7C2E1C43D652C4E9E49FE7517C236CB026DDDBE@dggeml529-mbx.china.huawei.com> <FC493433-BCDD-4080-9400-61481E7ADEF8@gmail.com><BYAPR05MB546372D1E0559F75D7DA5F61AE880@BYAPR05MB5463.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB546372D1E0559F75D7DA5F61AE880@BYAPR05MB5463.namprd05.prod.outlook.com>
X-CUSTOM-MAIL-MASTER-SENT-ID: MailMasterAndroid-2598-1569037573722-6f219f15-82c3-4c93-b7ef-8af22392fbee
Content-Type: multipart/alternative; boundary="__MESSAGE_BODY_PART__1_-5923043402659574946"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/hMkm126gj7NMyBwhgSNEmBo8VoY>
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: Sat, 21 Sep 2019 03:46:24 -0000

Hi Ron, Yes I believe both Binding SID is an important design for inter-domain signaling, and it is easy to add some mechanisms for SRv6+ to achieve similar function of Binding SID.  :) But I’m not sure if it is feasible to bind one IPv6 address to ‘BSID’ in SRv6+, because as shown in draft(spring-srv6-plus): “In SRv6+, an IPv6 address always represents a network interface”, and not represents an instruction/function on a node as SRv6 does. And, as the way you presented, interface IPv6 address 2001:db8::1 is mapped with SID 123, and bind to one SRv6+ tunnel. So, does it mean if we need to advertise many tunnels outside at one border router, we need to initialize many virtual interfaces(e.g. loopback) in the router? If does, I’m not sure this is a good idea to achieve inter-domain service tunnel signaling with security. Because in contrast to SRv6, it just need to simply add one route/sr-policy. How do you think?  :) Best regards, SING Team Moonlight Thoughts SING Team. Guangzhou, China Signature is customized by Netease Mail Master On 09/21/2019 02:09, Ron Bonica wrote: Hi Jeff,   It would be easy enough to add a binding SID to SRv6+. Given customer demand, I would not be averse to adding one.   However, there is another way to get exactly the same behavior on the forwarding plane without adding a new SID type.   Assume that on Node N, we have the following SFIB entry:   SID: 123 IPv6 address: 2001:db8::1 SID type: prefix SID   Now assume that was also have the following route on Node N:   2001:db8::1 -> SRv6+ tunnel with specified destination address and CRH   This gives you the same forwarding behavior as a binding SID.                                                              Ron       Juniper Business Use Only From: spring <spring-bounces@ietf.org> On Behalf Of Jeff Tantsura Sent: Thursday, September 19, 2019 10:53 PM To: Chengli (Cheng Li) <chengli13@huawei.com> Cc: SING Team <s.i.n.g.team.0810@gmail.com>; EXT - daniel.bernier@bell.ca <daniel.bernier@bell.ca>; SPRING WG List <spring@ietf.org> Subject: Re: [spring] A note on CRH and on going testing   There’s number of solutions on the market that extensively use BSID for multi-domain as well as multi-layer signaling.   Regards, Jeff On Sep 19, 2019, at 19:49, Chengli (Cheng Li) <chengli13@huawei.com> wrote: +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 on behalf of 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 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   _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring