Re: [spring] Beyond SRv6.
Shraddha Hegde <shraddha@juniper.net> Mon, 09 September 2019 17:52 UTC
Return-Path: <shraddha@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 4C9D2120857; Mon, 9 Sep 2019 10:52:01 -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=unavailable 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 DhaTX4Pr2Lx6; Mon, 9 Sep 2019 10:51:58 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A045412087B; Mon, 9 Sep 2019 10:51:58 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x89HdcM0003231; Mon, 9 Sep 2019 10:51:51 -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=H/oMXLb+eA35mgeZR7BZEH+kaGhtXVFwIS32Ju3+aN4=; b=U58/aNalRrd44KoZrhlBGLRkTSqOiWN1iAgn4KY5YHIozcG4as6BOjlYqbHEeU0oxNQu 0sfB+1TLrwdEPyhLJJAyNHX3BBBOPXmVsatl7EUBry5nYasV1zIg4ppq/9mnxt0AKiqN kao2YsKI0QC6vTXpRgxgiEJLsOgSMtiaNDIN2/cl2UkYhqffYMgN3WMaa+cBrcyyFb3U mfqqV/WLI4R1OiXYQEbSggs/Lj2S6Z7jYwNUXK+UjxeEVUyX6Q2AWlGTd2DdcmJYFsfp iiHsqKtB4wPTAjOZgzC/9Gi/v7Xv4i0qXRFkhZGyGVOFSVA0mmzBx5ailKS9Dz0LpzbR uQ==
Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp2056.outbound.protection.outlook.com [104.47.48.56]) by mx0b-00273201.pphosted.com with ESMTP id 2uvbnwub09-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Sep 2019 10:51:50 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C9EBc2lG0AayFbQMYOhCjRD1SoGiqhIYcYPu8wTb2Pr2vZqSDL1PUrTWnoEt/451pw1qGEy81bwdD/fvOuvMJ1xjIOqLS8yAYzZLf+ydDA1nREpQ6YzQN6th3CHUAJq1O++4ybuC/c7SLurkWdLnRz+XuMOXAQparHjFSWkW/CO0YMUJsebI3WiCp8/y0WfFJrkGQ+DaHeVpqAXfq5k8CBvdQCaZuZQmeb8s3Y1MU1uLmvu6eYor0TjZekn0mXcFBgOydM6RQJn2ushY6dqWBid2WaVRg0de796utXRazF/64Rkl0g2477V7dAvI/yTtZay3fkw7X+ed4yxwX1cevw==
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=H/oMXLb+eA35mgeZR7BZEH+kaGhtXVFwIS32Ju3+aN4=; b=M7OthR2wTAUwIU7yrZcDn1bk+Xqkx8+XAD38VMIfLL8wyDdCpF0IAGaQ0xu5Xj+vP0Rj23fcZVb7GmMHcz9Oite2jG2rd1oUT1vXn9Iza7I3MwibJyENR9yYENf/Ku4IS8JTlISZlr+MeX++MN2aXEAN3ircJA3AmCjRiUkSSMkzP7Xlhl+wEPZf+dzr9xwIOaQdNrGa4DVeeX2rE/Cmn+kbv3/Wr/HFBUCMduQb8N7anZN6kOJq2rFOYE7nX8IEdnvD9GG33/0iQwvPwrLwtYOc5pHybGVIys2pj/k+DOy1UEhhANjQXGDKTSqjC9rZ7HnpQkhMC56DKVFrLRQt3A==
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 BYAPR05MB3943.namprd05.prod.outlook.com (52.135.197.146) by BYAPR05MB4136.namprd05.prod.outlook.com (52.135.194.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.10; Mon, 9 Sep 2019 17:51:48 +0000
Received: from BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::457:8593:dc3e:25db]) by BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::457:8593:dc3e:25db%7]) with mapi id 15.20.2263.005; Mon, 9 Sep 2019 17:51:48 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Andy Smith (andsmit)" <andsmit@cisco.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>, Rob Shakir <robjs@google.com>, Tarek Saad <tsaad.net@gmail.com>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwgtZntk1bljyUGhwmBQu2Uz36cYjQIAgAHM44CAAA+hgIAD7CKAgAAESACAAD40AIAAFqeAgAA2B4CAAADegIACr8IAgAIp3gCAAAQuAIAAFI4Q
Date: Mon, 09 Sep 2019 17:51:48 +0000
Message-ID: <BYAPR05MB3943B93BC6EF84C7E03DF1E3D5B70@BYAPR05MB3943.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> <BYAPR05MB54639088D4875F3002A8E66FAEB70@BYAPR05MB5463.namprd05.prod.outlook.com> <1BA5FB3D-B873-4AFA-86CE-14FAED4F9B27@cisco.com>
In-Reply-To: <1BA5FB3D-B873-4AFA-86CE-14FAED4F9B27@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [116.197.184.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7aad88b-585c-4895-4240-08d7354e6358
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:BYAPR05MB4136;
x-ms-traffictypediagnostic: BYAPR05MB4136:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BYAPR05MB413626636C38C17FA481C4C2D5B70@BYAPR05MB4136.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01559F388D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(136003)(366004)(346002)(376002)(396003)(199004)(189003)(76116006)(53936002)(8676002)(71200400001)(71190400001)(9686003)(446003)(186003)(7736002)(74316002)(6306002)(54896002)(11346002)(476003)(55016002)(33656002)(229853002)(66066001)(66574012)(6246003)(486006)(236005)(6436002)(966005)(52536014)(7696005)(99286004)(2906002)(86362001)(64756008)(66446008)(14454004)(76176011)(66476007)(66556008)(66946007)(790700001)(6116002)(8936002)(3846002)(606006)(102836004)(25786009)(14444005)(26005)(54906003)(110136005)(6506007)(81156014)(478600001)(53546011)(81166006)(256004)(5660300002)(4326008)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4136; H:BYAPR05MB3943.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-message-info: D/tTWo2l29VkYhfIeYICxiwEF9Q0jEXJJerTW7JnMgN8l2Ka1m18iyQS24axvHXgzJMFe6A2OEjSaY2fVpqZM6T2YMrXggPZ8ymWlLUIlqe7AFoCgAYUyS7xodj/DqmJh1jgPv5HySKukuglW9mr+kmEykAOENqmrCv04XNhwOlyGevMx17+evmui/Ef/Xc1H8m150ef/ldQSNhAwqVAdWgob3+POe9KayEf6iWIKbitnc+ttrHPrFRTotux81H3Vdmvtl6e2kgwE0QbbhmV6eNmCoXyupsFzDil2SxllNSr+apUxFdC1+8GebJyf1OIZNRg+SmTE/hWCS4rXDoaSTecLbKdUP5+q3Z26kmwWj4kzUcbO2iqIlns6QuyVgiXw4dpgOuyYUN6FXYzg6WxnnvDWeZK9s755WRN6MsiZR0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB3943B93BC6EF84C7E03DF1E3D5B70BYAPR05MB3943namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f7aad88b-585c-4895-4240-08d7354e6358
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2019 17:51:48.4935 (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: JKgwuDrGvm+zEgRr7GU7uA3SwIhO/3jfBcflosP8dd2lZ3YscAAzmi4cEgae/pycb0NMFYnhstcGLQQIuoTufw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4136
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-09_07:2019-09-09,2019-09-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 impostorscore=0 clxscore=1011 malwarescore=0 suspectscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909090181
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/lMnvxLYPbCAVdpwTYN5pYKOCap4>
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: Mon, 09 Sep 2019 17:52:05 -0000
Andy, RFC 6119 defines ipv6 router-id . It is not mandatory to advertise IPv4 router-id in ISIS. Rgds Shraddha From: spring <spring-bounces@ietf.org> On Behalf Of Andy Smith (andsmit) Sent: Monday, September 9, 2019 10:07 PM To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> Cc: SPRING WG List <spring@ietf.org>; 6man@ietf.org; Gyan Mishra <hayabusagsm@gmail.com>; Robert Raszuk <robert@raszuk.net>; Rob Shakir <robjs@google.com>; Tarek Saad <tsaad.net@gmail.com> Subject: Re: [spring] Beyond SRv6. Ron, Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID? So you can't really build an ipv4 'free' network. Not 100% anyway. Andy On Sep 9, 2019, at 12:21 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote: Hello Gyan, Amplifying what you have said….. There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure. So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be enabled. Ron Juniper Business Use Only From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> Sent: Sunday, September 8, 2019 3:20 AM To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> Cc: Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; 6man@ietf.org<mailto:6man@ietf.org>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>; Rob Shakir <robjs@google.com<mailto:robjs@google.com>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> Subject: Re: [spring] Beyond SRv6. As an operator of a Tier 1 provider with massive mpls networks I think our traditional bread and butter “mpls” will be around for a very very long time as is IPv4 if not longer. Most all service provider cores run greater then or equal to MTU 9000 mpls cores to account for mpls overhead shims being tacked on plus edge overhead from possible GRE tunneling or IPSEC so in general making the core the maximum Jumbo MTU supported by most vendors at 9216 is what is generally done out in the field. So for SRv6 support of multiple or many EH insertions is really a non issue for most operators. From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes. I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA. Can someone clarify that use case for me. Also the EH insertion on intermediate node what is the use case or reason for that. My guess is it’s for special use case of stitching SRv6 domains together. Please clarify. I do agree with some of the other operators on the marketing hype and push for SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if it’s not broken..don’t try to fix it..leave it alone” and I think you can definitely say that for MPLS as it has had a SOLID run for service providers since the 90’s ever since ATM and frame relay were put to rest so I don’t think that it’s going away any time soon. I think it would be a serious mistake and sad state of affairs for vendors to push SR-MPLS and SRv6 and stop development and support of MPLS as that would really pigeon hole all operators into one technology which does not fit the bill for every use case out there. The mention of SR-MPLS pulling support for IPv6 and forcing operators to go with SRv6 is a wrong move for vendors and would really limit operators with flexibility to chose based on their use case to stay with traditional mpls or go with with SR-MPLS or SRv6 only if necessary with their unique use case warrants.. I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet another tool in our operator “design toolbox” to use as we see fit or not use but not be forced into it. There are particular use cases for SR-MPLS for migration from existing LDP and the downside of having state maintained in the core is not a downside as the P and PE nodes have to be provisioned anyway so their is no savings in pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP. I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature for L3 VPNs steering without adding complexity of adding ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic. That is a unique use case and not every major service provider has that requirement so if you don’t their really is no need to jump on the SR band wagon and you can stay put with the tried and true mpls that has been around for decades and is not going away any time soon. SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS core replacement or on the public internet or for enterprise network traffic engineering of flows between data centers or access to data center and an alternative to SD WAN application based routing solutions. But here as well the use case benefit has to exist. Nobody wants to be forced into it if it’s unnecessary added complexity. My 2 1/2 cents Regards, Gyan Mishra Verizon Communications Cell- 301 502-1347 Sent from my iPhone On Sep 6, 2019, at 10:17 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote: I don't think so. In OAM packets are on purpose made huge - even up to MTU to make sure real customer packets can go through or to detect and diagnose MTU issues. So adding SRH to it is nothing one can call inefficient. Wrong tree :) Cheers, R. On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <ssangli@juniper.net<mailto:ssangli@juniper.net>> wrote: On 06/09/19, 4:32 PM Robert Raszuk from robert@raszuk.net<mailto:robert@raszuk.net> said > Not really. Only SR OAM packets may need it. Is that a real problem ? Thanks for clarification. Like Ron pointed out before, its inefficient encoding. srihari… _______________________________________________ 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!QmUWmBSwMeAovLUIjU_O2tFmWCZOPQmNOWvSTsaRgHjWkA0is1xv2wNVKz9IevQp$> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- [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