Re: [spring] Beyond SRv6.
Yuji Kamite <y.kamite@ntt.com> Wed, 07 August 2019 10:29 UTC
Return-Path: <y.kamite@ntt.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 E841A120131 for <spring@ietfa.amsl.com>; Wed, 7 Aug 2019 03:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttcomgroup.onmicrosoft.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 BkkUFn2f7PhS for <spring@ietfa.amsl.com>; Wed, 7 Aug 2019 03:29:02 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410043.outbound.protection.outlook.com [40.107.141.43]) (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 63E7012002F for <spring@ietf.org>; Wed, 7 Aug 2019 03:29:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d4xb1+e6cn4kVTkBkL+g4ziHC3UF3qeC9WBVuFTNFkGVsvkIO0jaEw0hvc/gSn1fDByygBqJsGJfjx8ABXCM9F0fVI26j/WX8ppVBrlewOv7GLl7yM5JUiu1rZfCnHj4bNxHCLKOoNLFXLn7xjRIJjiY73pFgPeBDy1BZXwJnrWVhZaYJvGwZYlH/Mvx39Cmk4K38bj48GvpctjiAOHSAWEBCDtZj3OxKvsywMza1ggZXfiYOAU2taSm7vEhSegrPvf6yI17DJL11sbWpeQyKaNz2Q4VtBfQrm/4CkCmiPoaEOyzqoUppFtbiZFA56Bv7ZETipke/x5xcxNi/Hk9wQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWkJaslAsDgPi4xqjH2Do4LXApqzelFFVW2Qx93F8F4=; b=jO9kvn1uompar2zYuhyyuTB+8WC8auwAlIar3sR/E70fOw8Ckl3Vw+6FLIKxl8U+NcU3o6VPJ3ONIORwbMg4Sm4rdwKSYzfOwUpL+SCazvtzgPGeH5Avo/UyETm9f2SvzMPLhxOjlihjIYlbvQQn8ApgoUUcsS9zcmbenEEWr8uGzfePAbF8h1BH6M0HJ5IBO/HqVgaiMGJWbO7tJb8aZZcLxRhglEA5AZi5pQZBHLeTZTdx8tXPZEWWXavbgoatlxM6+kzuc4T9daZaUdcpKq3o5VGKXV9vKRMzuIPPP1c+WgnBZOuJXVbqu23nAqWqIv3UdBOxAmV97I69pldOSg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ntt.com;dmarc=pass action=none header.from=ntt.com;dkim=pass header.d=ntt.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttcomgroup.onmicrosoft.com; s=selector2-nttcomgroup-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWkJaslAsDgPi4xqjH2Do4LXApqzelFFVW2Qx93F8F4=; b=RKDriDkxAygPnU35S4CZj1XXmQfkuCeTNJXMnDGwh1mmlZmKMt3gaxa7YGAXUNFzGUjMp9jjESKk/Sdi5P6W4rVpQwhScJTte+PMvrilEneovc2/i/leU6NdE17zoY5imDUXenTqPdNXUB42T5hx+6XdCR2rZffkbhIObiBPWek=
Received: from OSBPR01MB1701.jpnprd01.prod.outlook.com (52.134.227.14) by OSBPR01MB5157.jpnprd01.prod.outlook.com (20.179.181.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Wed, 7 Aug 2019 10:29:00 +0000
Received: from OSBPR01MB1701.jpnprd01.prod.outlook.com ([fe80::7d23:461d:5531:8b3a]) by OSBPR01MB1701.jpnprd01.prod.outlook.com ([fe80::7d23:461d:5531:8b3a%3]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 10:29:00 +0000
From: Yuji Kamite <y.kamite@ntt.com>
To: 'Rob Shakir' <robjs=40google.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwguzIkwBiG3jUe+pTxRbSEUJ6bvZKTQ
Date: Wed, 07 Aug 2019 10:29:00 +0000
Message-ID: <OSBPR01MB17013A02024DBC06CE60006493D40@OSBPR01MB1701.jpnprd01.prod.outlook.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com>
In-Reply-To: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com>
Accept-Language: en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ccmail-original-to: robjs=40google.com@dmarc.ietf.org, spring@ietf.org
authentication-results: spf=none (sender IP is ) smtp.mailfrom=y.kamite@ntt.com;
x-originating-ip: [210.160.228.240]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdc7116e-ac84-44b7-5b31-08d71b220fc4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:OSBPR01MB5157;
x-ms-traffictypediagnostic: OSBPR01MB5157:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <OSBPR01MB51572B65590AB411338880B993D40@OSBPR01MB5157.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01221E3973
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(199004)(189003)(7736002)(53936002)(85182001)(33656002)(66446008)(446003)(486006)(236005)(55016002)(71190400001)(9686003)(54896002)(102836004)(6306002)(478600001)(2906002)(81166006)(74316002)(25786009)(64756008)(6116002)(86362001)(66946007)(66476007)(81156014)(186003)(3846002)(66556008)(26005)(11346002)(76116006)(52536014)(110136005)(316002)(99286004)(5660300002)(6506007)(53546011)(6246003)(476003)(68736007)(14454004)(66066001)(8676002)(8936002)(256004)(7696005)(966005)(6436002)(606006)(14444005)(71200400001)(229853002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:OSBPR01MB5157; H:OSBPR01MB1701.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ntt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Yo7QmhI1yU7UNqaB4kqtwMDJX44h1OtNcsChdmDu3vevuWKc4S+J4kohfe7p3InM5MjeLOvkOkIseJchMrYlE2bQbElrvigsYvAT4qf+ouZE3lxp0ajFqK7vlqwMbe2BC7ta/htknYaT+VD9/w+XfFL32bzx4vlp+lfSE+lre8yEUpgDLNer73gaWxIN2axXVK8muzgbOLFpo0EbxzI3IDRfwiD2lfOODKUfGsuclFZKX0zdSi+nVfsE07di6g1Q7Ktnt2K+v956NQR60R29sbhvsUh0f0C2vKkKjYpbVk+J9c91pt0BBtTTAKIpz+bMx3rnfZXB1tAFr7rg45KWg6guTCY+PxDrzN5FZw2D22a5siIrb8jn1BU1Zk+1EQRv6GMMytEmHxqRN0IGXgUSgr+kriM54rmR+Xleo8OSMeo=
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB17013A02024DBC06CE60006493D40OSBPR01MB1701jpnp_"
MIME-Version: 1.0
X-OriginatorOrg: ntt.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bdc7116e-ac84-44b7-5b31-08d71b220fc4
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 10:29:00.1600 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a629ef32-67ba-47a6-8eb3-ec43935644fc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FkDSjMMOSjKQGECW9eLX2OLp3eh07Zg9pPyEZQ+Gx4NxDA4KCsJdo57iZ6HPhghAn8A1ggvS+3JY8udKH7bh6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB5157
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8HHTjG5tZFznFCpQ9CeQjyahxAA>
Subject: Re: [spring] Beyond SRv6.
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: Wed, 07 Aug 2019 10:29:06 -0000
Hi folks, Let me post the feedback of requirement as an operator. Best regards, -Yuji --- Use Cases: 1. Explicit Routing(TE) – replacement/successor to the existing MPLS. 2. TI LFA / FastReroute -- same as above. link and node protection 3. VPN service -- same as above. EVPN and/or IP-VPN. 4. NW Slicing -- separate network logically, depending on traffic characteristics, with more fine-grained manner. 5. Service Function Chaining -- multiple VNF/CNFs are provisioned and dynamically connected, mostly in NFV infrastructure 6. Migration from SR-MPLS to SRv6 We already have deployment using 1 to 3. 4 to 6 are also planned things. In my view, SRv6 large-scale deployment is still limited today. Requirements: 1. Number of nodes / SIDs required: Existing production network: < 5 hops in Datacenters, < 10 hops average in WAN networks As long as we use simple VPN and TI-LFA only by SRv6, supporting a few number of SID stack is still fine; however, it is obvious that other use cases cannot be realized. From now on with SR: at least 10 segments support required,.10-15 is desired, .(I think it would not be longer than 20 soon though), when considering: - Connecting various metro MEC/5G backhauling network to the center network - Connecting IPSec/SD-WAN overlay access - Service function chaining across multiple locations - Traffic metering based on different slices - With several steering hops added (for example, monitoring traffic with steering) 2. Forwarding and Performance We have two major concern about current SRv6: (a) Bandwidth consumption overhead (issue in the existing SRv6 with 128bit SID) (b) Performance of forwarding equipment (typically the limitation of chip ) (Note: (b) depends on each vendor's implementation. I cannot mention each vendor's limitation information here, but I think it is important for community to share the understanding about today’s achievable level of number of SIDs/ performance limit in the industry.) 3. Length of SIDs needed - 16bits or 32bits (note: 32bit can be considered almost the same level as MPLS-SR) 4. Network design (e.g., physical MTU design) flexibility - Operators do not want complex design of topology and MTU considering the increase of SIDs in the future. 5. Multi domain network support - Multi-Area. Multi-AS support 6. Addressing flexibility - For providers who have the existing IPv6 deployment, a solution should avoid their drastic change of their current addressing. 7. Route information scalability - Additional propagation of IGP routes should be minimized as much as possible. 8. OAM functionality - Should provide OAM such as Ping/Traceroute for troubleshooting and failure detection/isolation. - It is desired that a solution can use ordinary ICMP mechanism (partially or fully) because it is a natural scenario that non-SR capable v6 domains are included in SRv6 end-end path. ---- From: spring <spring-bounces@ietf.org> On Behalf Of Rob Shakir Sent: Monday, August 5, 2019 6:04 AM To: SPRING WG List <spring@ietf.org> Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE. These encapsulations are past WG last call (in IESG or RFC Editor). During the SPRING WG meeting at IETF 105, two presentations were related to the reduction of the size of the SID for IPv6 dataplane: * SRv6+ / CRH -- https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04 * uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01 During the IETF week, two additional drafts have been proposed: * https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 * https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 As we expressed during the meeting, it is important for the WG to understand what the aims of additional encapsulations are. Thus, we think it is important that the WG should first get to a common understanding on the requirements for a new IPv6 data plane with a smaller SID - both from the perspective of operators that are looking to deploy these technologies, and from that of the software/hardware implementation. Therefore, we would like to solicit network operators interested in SR over the IPv6 data plane to briefly introduce their: * use case (e.g. Fast Reroute, explicit routing/TE) * forwarding performance and scaling requirements * e.g., (number of nodes, network diameter, number of SID required in max and average). For the latter, if possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would typically be different (*). * if the existing SRv6 approach is not deployable in their circumstances, details of the requirement of a different solution is required and whether this solution is needed for the short term only or for the long term. As well as deployment limitations, we would like the SPRING community to briefly describe the platform limitations that they are seeing which limit the deployment of SRv6 In particular limitations related to the number of SIDs which can be pushed and forwarded and how much the use of shorter SIDs would improve the deployments . For both of these sets of feedback if possible, please post this to the SPRING WG. If the information cannot be shared publicly, please send it directly to the chairs & AD (Martin). This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs via spring-chairs@ietf.org<mailto:spring-chairs@ietf.org> and ADs via spring-ads@ietf.org<mailto:spring-ads@ietf.org>. Thank you, -- Rob & Bruno (*) As expressed on the mailing list, a 128 bit SID can encode two instructions a node SID and an adjacency SID hence less SID may be required.
- [spring] Beyond SRv6. Rob Shakir
- Re: [spring] Beyond SRv6. Rob Shakir
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. 徐小虎(义先)
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. 徐小虎(义先)
- Re: [spring] Beyond SRv6. Yuji Kamite
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Satoru Matsushima
- 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. Sébastien Parisot
- Re: [spring] Beyond SRv6. Dirk Steinberg
- 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. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Gaurav Dawra
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. James Guichard
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Joel M. Halpern
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- 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. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Darren Dukes (ddukes)
- Re: [spring] Beyond SRv6. Voyer, Daniel
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Andrew Alston
- [spring] 答复: Beyond SRv6. Lizhenbin
- Re: [spring] Beyond SRv6. Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] Beyond SRv6. li zhenqiang
- Re: [spring] Beyond SRv6. Kamran Raza (skraza)
- 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. sthaug
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- 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. Ron Bonica
- 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. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. xiechf@chinatelecom.cn
- 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. Ron Bonica
- 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
- Re: [spring] Beyond SRv6. Bernier, Daniel
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Stewart Bryant
- [spring] “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Andrew Alston
- Re: [spring] “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: [spring] “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Dirk Steinberg
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “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: [spring] “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 Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- 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