Re: [spring] Beyond SRv6.
Reji Thomas <rejithomas.d@gmail.com> Wed, 04 September 2019 19:04 UTC
Return-Path: <rejithomas.d@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 5CEAF120C07; Wed, 4 Sep 2019 12:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 3UFtcUSEyryh; Wed, 4 Sep 2019 12:04:06 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 45A92120B83; Wed, 4 Sep 2019 12:04:00 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id w195so11878279vsw.11; Wed, 04 Sep 2019 12:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GL3Se9nwVOxTAHiXaZAVHJpweW+kQgD8Bw3VtG5len4=; b=ihbrssg8G+9bMNCxZgHCnzOMfoYd5URIcXyb63PcxMqiUOnkDebq7Ea/jh3J8lUcMC EickLKRoQTrY8QutHolbyMNgUqX4o2+8KvIEO6EKjtfCCWYDmxF6LvLoOXEwhJFOyGCu OIRWfh4LdFJZae7s8r0YGXWcfDpqkQjGdUxy9fHzBWDO1mG5ytmkE8AeXourDzCgHYE6 2/72bPdw4+G4OgMbtSx7aEYVYOIcWF0ja8Dny9ioawwtRfSEN8SRIUhLi6uQaDr1jNTo i8he7tRJeCXr7shWqvvtVPiW6tzfH88S+TTRh/tBj8eAhPH91ibFH67UiAAnu3O+jhs/ rDdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GL3Se9nwVOxTAHiXaZAVHJpweW+kQgD8Bw3VtG5len4=; b=AS4K+21VN5OBkFyDE58KmD5dfqPuML/t8DwpCJPNer0/5Kx6TNQYjp84tg/kD2sHVI 5BOv0qzuNidaIfeOvJ2kERcecwTbMtdyz8n1cP+0t9rVL2ayugKsqklUdoDqGTwvq0v1 yW/kepQMny7gFMPgciNfQDUjUmgoJEeeu3fjT9rpAhmLMpkLQJdyfVaRWQzfAHz0ppPu gkJaPNiRlsNdVPJTHkLPKx6yPKSUHaqmv4N1eeZpjptae8EEgSoG8PuaSLeeAJSyUggx 65M4cIfVcAR+TZRHcJjNXGa6ZqV7hj9mRbXzB8E6iz4RYy/iBXonQX++v7g2BLWqxp99 veXQ==
X-Gm-Message-State: APjAAAXeEwqclwtcDgAiWAbP8iZEK1zCTan1ibRYcu6rj5NetygLb14n zdcwzJRDgjYz7V7A3HBvPO5gObVoySDxEcvmvP377nhA1g==
X-Google-Smtp-Source: APXvYqz7oFz18j05Oj6WktRPK+teEZ8qgtaMBIIkVGCFUYkrXhNwi5zbTBvtXQCILDSRtO7LGVlk48Igmf3pAzIPl84=
X-Received: by 2002:a67:1a41:: with SMTP id a62mr6195277vsa.54.1567623838952; Wed, 04 Sep 2019 12:03:58 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.3390.1567532921.9648.ipv6@ietf.org>
In-Reply-To: <mailman.3390.1567532921.9648.ipv6@ietf.org>
From: Reji Thomas <rejithomas.d@gmail.com>
Date: Thu, 05 Sep 2019 00:33:47 +0530
Message-ID: <CAA8Zg7Evkud=hTDpVJVzP=HxF52U7qumoUHJ=bfABUpggGFDhQ@mail.gmail.com>
To: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ff1be0591bede63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/AV5RX1NQS2c0B8lq4Gh-X1kAOQY>
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, 04 Sep 2019 19:04:13 -0000
Hi WG Folks, Its not clear on why the SRv6 has to alter the address semantics and push the service functions into v6 address space. Maybe rationale on why this was done would help to appreciate why this path was chosen. >From my understanding the SRv6+ spec shows these defined service functions are best represented by destination options and is in line with the IPv6 architecture document leaving the address space semantics intact. In SRv6 the SID is defined as LOC:FUNCT:ARGS. It is not clear on why this fixed address space would be sufficient for arguments. I believe if the same cannot fit in 128 bit address space it needs to be overflown into another SID or into a TLV. Doesn’t this semantics suggest that TLV is the best place to encode this information and should be in a destination option header in first place? It also seems that the TLV space in SR header might turn out to be a catch all block wrt SR. For example In-situ OAM IPv6 Options for Srv6 are getting pushed to SR TLVs whereas for generic V6 I see there is another draft ( https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-02) which pushes them into destination options/hop-by-hop. With the dilution of semantics of headers are we looking at more conflicts of SRv6 model with generic V6 features in future?. HMAC TLV is used to protect the SRH. It not clear on how the same would interoperate with AH. When AH is included are we going to end with both AH and HMAC TLV ? The uSID draft for reducing the SRH overhead seems to be a hack at present and its still not clear on how the same is going to be used with function semantics. SRv6+ confirms to the V6 architecture, explains the rationale behind the design and is non ambiguous to start with. Till now there has not been any valid shortcomings brought forth with the Srv6+ design. I saw a mention that SRv6+ needs to distribute the SID to address binding and hence require extensions to protocols which is not what was intended by SR. Considering at a bare minimum we would need a software/microcode update to support even the SRH parsing, I didn’t understand why protocol extension and mapping for SR support with V6 is a bad idea. Please correct me if there is a gap in my understanding. In view of the above ,I support SRv6+ work to continue in the SPRING WG. Regards Reji > From: spring <spring-bounces@ietf.org> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> > > Date: Monday, September 2, 2019 at 9:23 AM > To: Rob Shakir <robjs=40google.com@dmarc.ietf.org>, SPRING WG List < > spring@ietf.org>, "6man@ietf.org" <6man@ietf.org> > Subject: Re: [spring] Beyond SRv6. > > Rob, > > There may be an elephant in the room that needs addressing?. > > Over the years, the IPv6 community has specified a very tight architecture > that encodes some information in IPv6 addresses, other information in > Routing headers, and still other information in Destination Options > headers. SRv6+ adheres strictly to this architecture. Because it reuses > IPv6 machinery, its specification promises it be painless and its > deployment promises to be safe. To date, there has been no significant > technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and > good enough. (Both of those claims may require scrutiny). > > By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 > architecture. It encodes things in IPv6 address that have never been > encoded in IPv6 addresses before. It attempts to encode everything else in > the Routing header, as if the other IPv6 extension headers didn?t exist. It > frequently tests the limits of RFC 8200 compliance. > > This creates a situation in which each variance from IPv6 orthodoxy > requires another. For example, because SRv6 encodes instructions in IPv6 > addresses, draft-ali-6man-spring-srv6-oam is required. And now, > draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 > orthodoxy. OAM information is encoded in the Routing header and the Routing > header must be examined, even when Segment Left is equal to zero. > > I invite everyone to consider how TI-LFA an uSID will interact. > > So, why would the IETF would want to prevent work on the more > conservative, SRv6+ approach? This brings us to the back to the elephant > in the room?.. > > Until very recently, relatively few router vendors have supported IPv6 > extension headers in ASICs. If an IPv6 packet contained any extension > headers at all, it was sent to the slow path. > > SRv6+ encourages router vendors to support both the Routing and > Destination Options header in ASICs. This sets vendors on a path on a path > towards more complete implementation of the architecture that the IPv6 > community has developed so carefully over the years. It encourages vendors > to commit more and more of RFC 8200 to ASICs. > > SRv6 encourages router vendors to support the Routing header in ASICs, > while doing everything possible to mitigate the need to support Destination > Options in ASICs. This may be a necessary expedient for many platforms. > However, it should not be the only approach, or even the long-term approach > for the IETF. > > > Ron > > > > > From: spring <spring-bounces@ietf.org> On Behalf Of Rob Shakir > Sent: Sunday, August 4, 2019 5:04 PM > 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< > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ&e= > > > ? uSID -- > https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01 > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ&e= > > > > > During the IETF week, two additional drafts have been proposed: > ? > https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00< > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=XWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-CrKs&e= > > > ? https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03< > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&e= > > > > > 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 > o 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