Re: [spring] “SRV6+” complexity in forwarding
Ron Bonica <rbonica@juniper.net> Fri, 20 September 2019 17:09 UTC
Return-Path: <rbonica@juniper.net>
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 5B9AE1201E5; Fri, 20 Sep 2019 10:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 egp37vVarPQB; Fri, 20 Sep 2019 10:09:53 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 23C9C1200FF; Fri, 20 Sep 2019 10:09:53 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8KH9exP021443; Fri, 20 Sep 2019 10:09:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=9dzeLOe97wXC0i3nBI596TmrBAAtE993LUuHfW2bbAo=; b=Bt1aYmTtMc/HjwX/Yy4Xz23nTq42joRzlmrqEA4JfyF2TJfPloT3FeppE3LH7LFEHTKz FBvFkReQQwWZ/H60I9+yp4pDe2Bj/AZpcQkEXqN6nvG1t2zSeOJhJOAMd7Ykw1UhvM2X Eme+ZXj6qPfrqeiFUbXuyFKQAt9/aYyhjEhkhagfTsWVYu4pyEEyGXwW3pxvKKBVOKh4 t0yId2RtzQD4GNku/6mm2Z362kdBscnIBXUyC4K0FJc3WYjKG4G8MaSTDUvv+/1WX5MF qY/ipsXJHXmKfTQ3UACrdiLN2Z02RfAVsi0ATwHwgR0KG2H/rSPTKK2B3aIq3ZxICcyb JQ==
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2055.outbound.protection.outlook.com [104.47.41.55]) by mx0a-00273201.pphosted.com with ESMTP id 2v4sp90yqk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Sep 2019 10:09:39 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I5WrNoN5ZfCf1spyFyVGP23SzuFtrxZ8uOY8vV6x5H9YYU4F1B61LstP8Km3Z84Zj4fq+ccuyefDW7g0QKtupXirbLVcjHGn4N9ZYjxacUuTI5oy2DLxIyRix+AoeiHNSMpTuj505d9mtNc7rN9PVRMhiD/jjUQDQh093VokrU7Y8EztawYR5s8+Lhye0BDgDxOLoZS2upqoAbZ4hi0diFZaQLbEbLNtMpcXPt3ayXn9kCMuTxIG3fKimyMW8GRL/9MxcGBFQOBwbdtjVBx1WT4BMJd05kpL1C5Mrpb5d7DDwt0rsWWPcANIxI/0yV5l3tyNI5rh5cklynEWvChwEw==
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=9dzeLOe97wXC0i3nBI596TmrBAAtE993LUuHfW2bbAo=; b=krCy6YpsOhv6h1osa8vfownjSAcW6XMZjTVZwkPfx/xTYXp7JISntEjBKBi6tHQj3vdhQZxVsJgnioMORottCC+4wTVUyVSD9iVyoQ+vETCC2RrPiQ9aQBnh7De4MVKCKNgXxS8cdc/xnY2QPO36WdWQBWOpJLcjAI0OllAKjK6HuXi60gDq7V7/NDHOEZj1X3CyIiJsOCm9jWbvnu49Rysbyufvl60Dbqj2acPpN+WXMZe4SouDEcG4x0Vr2KueBKhDRRW90cRUiamEcATe/jTdoYCg+AsbTDzMeA9AjRY9rV/MUX+k1pjdki9ofXBUBhLn3uwnHOaFmgKFNWB4cQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from BYAPR05MB5463.namprd05.prod.outlook.com (20.177.185.144) by BYAPR05MB4519.namprd05.prod.outlook.com (52.135.202.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.10; Fri, 20 Sep 2019 17:08:48 +0000
Received: from BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a]) by BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a%4]) with mapi id 15.20.2284.009; Fri, 20 Sep 2019 17:08:48 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Dirk Steinberg <dirk@lapishills.com>, Tom Herbert <tom@herbertland.com>
CC: "Darren Dukes (ddukes)" <ddukes@cisco.com>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Robert Raszuk <robert@raszuk.net>, Rob Shakir <robjs@google.com>, Tarek Saad <tsaad.net@gmail.com>
Thread-Topic: [spring] “SRV6+” complexity in forwarding
Thread-Index: AQHVbM6iBD2vmdhhC0CHW2Z2/PIyC6cvDt0wgAJlHoCAACXNgIAAgXoAgAK3DTA=
Content-Class:
Date: Fri, 20 Sep 2019 17:08:48 +0000
Message-ID: <BYAPR05MB54634112BB290EB29B3DF4FBAE880@BYAPR05MB5463.namprd05.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> <91CBADAD-EFE6-46E1-A9D3-DAA111357179@juniper.net> <CAOj+MMGyUFRPDqCBo5SbLX486o_9GLpM6Zxf8KSt1voWiqhkGQ@mail.gmail.com> <E8D473B5-3E8D-4339-9A79-0CAE30750A55@juniper.net> <CAOj+MMFOy5PyTo=jPJkVrQOctdWjsTbD=7ix-2n89vodKzT3gQ@mail.gmail.com> <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com> <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com> <201909120857387140042@chinatelecom.cn> <1568259664564.62561@bell.ca> <CAO42Z2wQ_8GEE+=nAMFBj+ape9Vf7fARVoOwGdCiUxdffkyXgw@mail.gmail.com> <BYAPR05MB5463A04B05B4BD6AA294F7F0AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <6EA6F7C0-BEB2-4749-A6AB-62B1337213B2@cisco.com> <BYAPR05MB5463426F1668202EE5F183EFAE8F0@BYAPR05MB5463.namprd05.prod.outlook.com> <634900D2-FBCE-47CF-8907-C8B9CB3A4102@cisco.com> <CALx6S34=Tw-u4Hz-07-Rs-GjsungkqnD_fMoQnGc17u3VJhY1g@mail.gmail.com> <CAFqxzqYr7g2jzwJrhvjL_DXYZsDzbzqx01cy0zB1aBweDde1XQ@mail.gmail.com>
In-Reply-To: <CAFqxzqYr7g2jzwJrhvjL_DXYZsDzbzqx01cy0zB1aBweDde1XQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-09-20T17:08:45.9427309Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=1ee49fb1-b043-4f06-9a3c-389099fdecb4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [108.28.233.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 02a582a4-59f0-4e7d-4734-08d73ded33cc
x-ms-office365-filtering-ht: Tenant
x-ms-traffictypediagnostic: BYAPR05MB4519:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR05MB4519A33D29A9F0CD82BB06FBAE880@BYAPR05MB4519.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0166B75B74
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(199004)(189003)(51444003)(256004)(186003)(229853002)(476003)(11346002)(64756008)(6436002)(53546011)(446003)(7736002)(478600001)(66446008)(66556008)(486006)(71190400001)(71200400001)(66066001)(9686003)(14454004)(2906002)(8936002)(55016002)(6116002)(6306002)(81166006)(54896002)(236005)(86362001)(81156014)(606006)(5660300002)(4326008)(33656002)(26005)(66946007)(76116006)(66476007)(790700001)(52536014)(966005)(3846002)(6246003)(102836004)(76176011)(99286004)(74316002)(316002)(25786009)(54906003)(110136005)(6506007)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4519; H:BYAPR05MB5463.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sOR9Kv9A4sM3OTBJKjPDxXi9O8qUoUV3zUGCl50INwEEcZx8+uIi8ELXH1FDS6S6UA0mUv8ZvA1LTfmDUfbt8g94A+FikAUG8UXESYLofw8++LSonhEtCba6+C2GBbJE4M77WTMPDbHumxBbse9rfGr0Hcj03RrzZinj5OSvXcxcCl6UiyiOVm0BFY1Be+65Elz/Cm7xWq3QicVfR4Ee6GVT2jyqSSVKsFIWu7XW9kJPXko3Bio374nETB5lZgQKR0uTLn9cvu3HNU6qJLZq9GM36pIAbmQnsnHMyZAt9Bfm7dmWzMH0P5fH1fE9UhA49DDf1omBdkb43X42Pd1vWmJPpBmxI2rxrYaww5xOQwh6vI0dE9TCFbIK7kpIRv6Y1x7G+wNE9jApY9UX+7M9n8C30535bJWXZ3U68gOKWA4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB54634112BB290EB29B3DF4FBAE880BYAPR05MB5463namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 02a582a4-59f0-4e7d-4734-08d73ded33cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2019 17:08:48.0466 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8mM7FYeDr+JfVs93bd3v67WQTN55oA+r/9DObk3eK2gb6AGvhre8uauCL0p8R3rrqg3pKOWM/cmDWvOoGJXVzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4519
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-20_06:2019-09-20,2019-09-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 bulkscore=0 adultscore=0 clxscore=1015 impostorscore=0 priorityscore=1501 spamscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909200148
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/YJHEj1cH8tmwK-VKUHGdgVOXA6w>
Subject: Re: [spring] “SRV6+” complexity in forwarding
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: Fri, 20 Sep 2019 17:09:57 -0000
Likewise, SP core routers would ignore the PSSI and wouldn’t even see the PPSI. Ron From: Dirk Steinberg <dirk@lapishills.com> Sent: Wednesday, September 18, 2019 7:40 PM To: Tom Herbert <tom@herbertland.com> Cc: Darren Dukes (ddukes) <ddukes@cisco.com>; xiechf@chinatelecom.cn; SPRING WG <spring@ietf.org>; 6man <6man@ietf.org>; Robert Raszuk <robert@raszuk.net>; Ron Bonica <rbonica@juniper.net>; Rob Shakir <robjs@google.com>; Tarek Saad <tsaad.net@gmail.com> Subject: Re: [spring] “SRV6+” complexity in forwarding SRv6 does not require TLV processing for normal forwarding (use case: SP core). - Dirk On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>> wrote: > > Hi Ron. > > I summarized my argument as follows: > "Regardless of ASIC capabilities there are two performance penalties you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.” > > You’ve confirmed this additional overhead for "SRv6+". Thanks. > Darren, How does one escape the performance penalty of TLV processing in SRV6? Tom > You then say "So long as the ASIC can process enough packets per second to saturate the line cards, we are forwarding at full line rate." > > Yes this is true, but we can conclude: The complexity of "SRv6+" requires ASICs do much more work per packet vs SRv6. > > Thanks > Darren > > > On Sep 16, 2019, at 9:59 PM, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote: > > Hi Darren, > > I think that your argument can be summarized as follows: > > > SRv6 requires only two FIB searches > SRv6+ requires 4 or more FIB searches > Therefore, SRv6+ cannot possibly forward at line speed > > > Have I summarized your argument correctly? If not, please set me straight. If so, please read on. > > First, SRv6+ never requires more than 4 FIB searches. The DOH that precedes the CRH contains, at most, one PSSI. Therefore SRv6+ requires four FIB searches, at most. > > Second, SRv6+ only requires 4 FIB searches the following case: > > > The packet contains two instances of the DOH. (Most use-cases require only one.) > The processing node is configured to process the PSSI. (Many ASIC-based devices, because of their role in the network, won’t support any per segment service instructions. This nodes will be configured to ignore the PSSI. That is why it is optional.) > > > So, in most use-cases, SRv6+ requires only 3 FIB searches. > > So, you might now argue that: > > > SRv6 requires only two FIB searches > SRv6+ requires three and sometimes four FIB searches > Therefore, SRv6+ cannot possibly forward at line speed > > > Here, some slightly deeper thought might be required. A platform has two relevant resources: > > > A route lookup ASIC, that can process some number of packets per second > Some number of interfaces, that can forward some number of bits per second > > > So long as the ASIC can process enough packets per second to saturate the line cards, we are forwarding at full line rate. So long as a platform has a sufficiently capable ASIC, it will be able to forward at line speed. But it’s a matter of how the platform is designed. If the ASIC is not sufficiently capable, of course, it will not forward at line speed. > > In your email, you say that I have been asked several times to report on the state of Juniper’s SRv6+ implementation. While I cannot provide details, you can assume that we wouldn’t be working on this if we thought that performance was going to be sub-optimal. > > You also suggest that Juniper’s is the only implementation. Are you sure that this is correct? > > Ron > > > > > > Juniper Business Use Only > From: Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>> > Sent: Monday, September 16, 2019 4:38 PM > To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> > Cc: Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>; EXT - daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca> <daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca>>; xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Rob Shakir <robjs@google.com<mailto:robjs@google.com>>; Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> > Subject: “SRV6+” complexity in forwarding > > Hi Ron, I agree ASICs are always improving, indeed this is evident in the number of successful SRv6 deployments and multiple vendor implementations at line rate on merchant silicon, and multiple vendor ASICs. > > Is “SRv6+” (PSSI+CRH+PPSI) implemented and deployed at line rate? > You’ve been asked this several times. Since you’re the only implementor(?) and one operator is claiming deployment or testing, I am curious. > > Regardless of ASIC capabilities there are two performance penalties you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups. > > Requiring all segments in a CRH segment list to process an arbitrary length DOH+set of PSSI’s and other options is always very expensive. > - It is expensive in SRAM as previously discussed in these threads. > - It is expensive in parsing logic to know and process a set of TLVs in any ASIC or NP. > > Spreading PSSI, CRH, PPSI operations in multiple headers and multiple identifiers you now have multiple lookups at a node. > 1 - lookup destination address > 2 - lookup one or more PSSI and future destination options. > 3 - lookup the CRH label or PPSI label. > 4 - lookup new destination address > > Compare this with SRv6. > 1 - lookup destination address > 2 - lookup new destination address > > While ASICs are more capable and will continue to be more capable, these technical performance problems you introduce with PSSI+CRH+PPSI will not go away. > > Darren > > > > On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote: > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org<mailto:ipv6@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-RGWVqzi$> > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-Z5e9NFo$> Juniper Business Use Only
- [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