RE: [spring] Beyond SRv6.
Andrew Alston <Andrew.Alston@liquidtelecom.com> Fri, 06 September 2019 08:40 UTC
Return-Path: <andrew.alston@liquidtelecom.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32135120B3C for <ipv6@ietfa.amsl.com>; Fri, 6 Sep 2019 01:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gE_N2lRHvZyE for <ipv6@ietfa.amsl.com>; Fri, 6 Sep 2019 01:40:18 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.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 8D4D31200B8 for <6man@ietf.org>; Fri, 6 Sep 2019 01:40:17 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2053.outbound.protection.outlook.com [104.47.8.53]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-215-HRzl-jTfMAKgcg6koyq77Q-1; Fri, 06 Sep 2019 09:40:06 +0100
Received: from VE1PR03MB5422.eurprd03.prod.outlook.com (10.255.112.208) by VE1PR03MB6125.eurprd03.prod.outlook.com (20.179.31.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Fri, 6 Sep 2019 08:40:05 +0000
Received: from VE1PR03MB5422.eurprd03.prod.outlook.com ([fe80::c456:2d7a:c516:486c]) by VE1PR03MB5422.eurprd03.prod.outlook.com ([fe80::c456:2d7a:c516:486c%3]) with mapi id 15.20.2199.027; Fri, 6 Sep 2019 08:40:05 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Robert Raszuk <robert@raszuk.net>
CC: Ron Bonica <rbonica@juniper.net>, Srihari Sangli <ssangli@juniper.net>, Tarek Saad <tsaad.net@gmail.com>, Rob Shakir <robjs@google.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: [spring] Beyond SRv6.
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwgx1C0+06fAOEubArDypHiFT6cYjQIAgAHM44CAAA+hgIAD7CKAgAAESACAAAWUAIAACQDQgAAT4oCAAAemgIAAAPvw
Date: Fri, 06 Sep 2019 08:40:05 +0000
Message-ID: <VE1PR03MB54221A9263F35AEBFD50A437EEBA0@VE1PR03MB5422.eurprd03.prod.outlook.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54632F09C712ADB30138CFA9AEBE0@BYAPR05MB5463.namprd05.prod.outlook.com> <BYAPR19MB3415D21403394F8129A4BAD8FCB90@BYAPR19MB3415.namprd19.prod.outlook.com> <30491F13-C652-45C3-AB2B-95F765FBB4EA@juniper.net> <65C5CB04-3A2F-4F83-A7C8-2045154F93AE@cisco.com> <BYAPR05MB5463EC3250F2A303A3641839AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <9CCE1F5C-A886-4B06-8B97-D0645CFFE5E2@cisco.com> <PR2PR03MB541913FD25718B80EF1C9110EEBA0@PR2PR03MB5419.eurprd03.prod.outlook.com> <CAOj+MME7knoTq3qUOshwdUejbOEKsYD_vDQYBfDNiwRNGAt81g@mail.gmail.com> <FA94F6B1-16CE-48CE-AF45-9E35A5F129DF@cisco.com>
In-Reply-To: <FA94F6B1-16CE-48CE-AF45-9E35A5F129DF@cisco.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: c2aa8869-8a9a-4c09-73c3-08d732a5d12f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR03MB6125;
x-ms-traffictypediagnostic: VE1PR03MB6125:
x-microsoft-antispam-prvs: <VE1PR03MB6125854AF6EEAEE1C2903B96EEBA0@VE1PR03MB6125.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:989;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39860400002)(396003)(136003)(366004)(376002)(189003)(199004)(64756008)(66446008)(66476007)(66556008)(53936002)(316002)(476003)(76116006)(486006)(4326008)(6306002)(229853002)(11346002)(71190400001)(2906002)(5660300002)(52536014)(790700001)(66946007)(25786009)(55016002)(99286004)(14454004)(76176011)(53546011)(6506007)(3846002)(7736002)(102836004)(6436002)(6116002)(66066001)(71200400001)(10916006)(74316002)(110136005)(8676002)(7696005)(81156014)(81166006)(186003)(6246003)(33656002)(54896002)(54906003)(478600001)(9686003)(236005)(446003)(256004)(8936002)(26005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1PR03MB6125; H:VE1PR03MB5422.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /cMo3Rvbe/UL1S5C3185uhvnB39QOkBqWML3ONI4d3EH5yry9nOrRKkX5ru3IdzmxgoiFPtlXCvh1A1sQUNHDpdvIqUyzOqVHL8EYT5xL8h7Zs7x1Xom+QcvAq7EsXTCoc2hIluY51YpvaJ8XAsZH4ZzlVZbVQx8ffkwbKrD1VzvEIZWqYaS//HbZvZsb/SUbqqlfxKVoavqBDLUCtqoiA3lrBUZetTtKwTrxB5meXFgPe7NeoOWctnCe1hmse7mp1p5CALF6iEPFfuqFeTgq2MVRViBKlIVtLCcyw4chP17SuER6SgQ41P9abFSnFhy6g41XcvxXsQyoZGc1zUXYAAhot2SQwuwo04brUAsfOJFIKz6Ie7mXBIzuDIfw4BiSIt4Bxtqb2yRZbISJQCyy7Wb7z6G+GzqtnvMHw1LI0A=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2aa8869-8a9a-4c09-73c3-08d732a5d12f
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 08:40:05.4906 (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: vLX8W/uNLxgNidgWwADdJ2WJyMF902109QdqGtJNO4pJGdsBmBw1YPeQ2agE+1OrtEo4etVFrUFvxwfM+qSwJ6Bkvc6W0eJiw3GkoRarJeE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR03MB6125
X-MC-Unique: HRzl-jTfMAKgcg6koyq77Q-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_VE1PR03MB54221A9263F35AEBFD50A437EEBA0VE1PR03MB5422eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XJwTQpoaNI9O5orxK4WtSxkkcjo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 08:40:26 -0000
An Zafar – I told by those words – I am pragmatic though as an operator. I know that srv6 in some form or another is coming – I stated as much on various blogs. I am not fool enough to believe that I am not going to be forced into a situation where I am going to be made to run some variant of this – because I have been told very bluntly by certain vendors that mpls style development for v6 will cease at a control plane level – and we are already seeing situations where despite sr-mpls working just fine – certain vendors have actively chosen to not support this with IPv6. That has put me in a position where I have to be pragmatic – because – as an operator with a massive network – I have to be able to continue to well, operate. That leaves me needing something that finds a common ground between those who want MPLS to die – and the MPLS usage which is present, real and necessary in the world in which I operate. That leaves me with needing a version of SRv6 which is usable, does not impose insane overhead, and does not fundamentally rewrite the IPv6 protocol. I have been extremely open and honest about this – I will however say – that the added functionality through the network programmability – all of which is catered for in CRH without the need to rewrite the IPv6 specification to do it – does have other use cases – and hence – CRH actually works for us – very very well – because it retains that which I need – while adding some really nice advantages on top of it. But again – we have asked – multiple times – for the technical problems behind CRH – and the ringing in my ears is deafening from the silence. Andrew From: Zafar Ali (zali) <zali@cisco.com> Sent: Friday, 6 September 2019 11:28 To: Robert Raszuk <robert@raszuk.net>; Andrew Alston <Andrew.Alston@liquidtelecom.com> Cc: Ron Bonica <rbonica@juniper.net>; Srihari Sangli <ssangli@juniper.net>; Tarek Saad <tsaad.net@gmail.com>; Rob Shakir <robjs@google.com>; SPRING WG List <spring@ietf.org>; 6man@ietf.org; Zafar Ali (zali) <zali@cisco.com> Subject: Re: [spring] Beyond SRv6. Hi Andrew, I agree with Robert. CRH is nothing else than IPv6 over SR-MPLS. In the vast majority of the deployments (single SP domain), one can deploy MPLS. In a minority of cases where some MPLS discontinuity in the domain could exist, SR-MPLS over IP/UDP is an adopted and deployed solution. As you stated in your original response” “Now – in that case SR-MPLS would have been just fine and frankly speaking – we were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t see much of a use case for SRv6 at all.” I can see why you liked CRH. Thanks Regards … Zafar From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> Date: Friday, September 6, 2019 at 4:01 AM To: Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>> Cc: "Zafar Ali (zali)" <zali@cisco.com<mailto:zali@cisco.com>>, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>, Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>, Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>, Rob Shakir <robjs@google.com<mailto:robjs@google.com>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, "6man@ietf.org<mailto:6man@ietf.org>" <6man@ietf.org<mailto:6man@ietf.org>> Subject: Re: [spring] Beyond SRv6. Hi Andrew, I can say that I may even agree with some of your points. But one question I asked which no one responded still stands ... SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. Both require mapping, both require changes to OAM, both require IGP extensions, both can use the same forwarding hardware and logic, both require almost identical operation etc .... As you know even main author of SRv6+ agrees with all of this in the notes sent to the list. So please help me to understand why entire industry who wants to be good IETF citizen and Industry player should now invest a lot of resources in development, testing, shipping and support of a solution which is just a poor mirror of something which is already available ? Yes some folks were allergic to MPLS in the past and some are still allergic to MPLS. But as someone who have worked since Tag Switching early days on that piece of technology let me tell you that vast majority of those folks do not even understand the difference between MPLS used for transport and MPLS used as forwarding demux for the applications. They just treat it the very same way like an evil or devil protocol which does nothing else other then demonstrate their complete ignorance of the subject. Yes MPLS to be used as a transport is a mistake. It was not a mistake in the past as when we rolled out services which required encapsulation most platforms in the field just could not do line rate IP encapsulation. But those days are gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a transport would have never succeeded. Then of course there was more mistakes TDP later by IETF collaboration became LDP was a mapping protocol - yes another mistake instead of making up front domain wide labels and extended IGPs and BGP for that. Well the thought was that working on single protocol will be easier then extending ISIS, OSPFv2 (and v3 on the radar), RIPv2, EIGRP. But this is MPLS transport which in spite of little group of folks still selling it around believe it or not it is going away. But nothing is wrong about using 20 bit labels as demux for applications and services. Packet carry bits. Nowhere in the packet even if you decode it carefully it says "I am MPLS" ... forwarding on the boxes also uses bit lookup and if you ask your vendor they can paint it and abstract all the MPLS legacy in the CLI for you so you never see it. Bottom line is that I see no reason at all to adopt a solution which walks like a duck, quacks like a duck and only carries a label "I am not a duck" Best, R. <snip>
- Fwd: [spring] Beyond SRv6. Gyan Mishra
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Andrew Alston
- RE: [spring] Beyond SRv6. Parag Kaneriya
- RE: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Reji Thomas
- Re: [spring] Beyond SRv6. Sander Steffann
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. sthaug
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Ca By
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Gyan Mishra
- 答复: [spring] Beyond SRv6.(CCDR Proposal) Aijun Wang
- Re: [spring] Beyond SRv6. 松嶋聡
- Re: [spring] Beyond SRv6. Dirk Steinberg
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Andy Smith (andsmit)
- RE: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6 Alexandre Petrescu
- RE: [spring] Beyond SRv6 Ron Bonica
- Re: [spring] Beyond SRv6 Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: Re: [spring] Beyond SRv6. xiechf@chinatelecom.cn
- Re: Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Bernier, Daniel
- RE: [spring] Beyond SRv6. Xiejingrong
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Bernier, Daniel
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Brian E Carpenter
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Xiejingrong
- RE: [spring] Beyond SRv6. Bernier, Daniel
- “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- RE: “SRV6+” complexity in forwarding Ron Bonica
- Re: “SRV6+” complexity in forwarding Andrew Alston
- Re: “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Dirk Steinberg
- Re: “SRV6+” complexity in forwarding Gyan Mishra
- Re: “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Gaurav Dawra
- Re: [spring] “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: “SRV6+” complexity in forwarding Fred Baker
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Srihari Sangli
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- RE: [spring] “SRV6+” complexity in forwarding Chengli (Cheng Li)
- Re: [spring] “SRV6+” complexity in forwarding Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Stewart Bryant
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- RE: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- RE: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] =?utf-8?Q?=E2=80=9CSRV6+=E2=80=9D_?=… Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra