“SRV6+” complexity in forwarding
"Darren Dukes (ddukes)" <ddukes@cisco.com> Mon, 16 September 2019 20:37 UTC
Return-Path: <ddukes@cisco.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 8DDA21200C1; Mon, 16 Sep 2019 13:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.4
X-Spam-Level:
X-Spam-Status: No, score=-14.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JZfMWoSs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qBrp6jC5
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 sEhJ5KKgZQ0E; Mon, 16 Sep 2019 13:37:50 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F9C12006F; Mon, 16 Sep 2019 13:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76379; q=dns/txt; s=iport; t=1568666270; x=1569875870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZG0ij6HnPm7+gtVyJUF0IoSTnalXEANuUTS4V1tGDg4=; b=JZfMWoSs2ME9hGZ3HGORe6P9787+1/VcY6c2ShrMBGg9iP4K/AMa+BrB G12JrHXwR25xZSvoysQT2bL7VlQehmqSNp9ycM8KhfFQuIBuYZOiraIJk jhXh3ky9ps4IK+uyi+V+xgrCTBqDHYrtenhq8BMT6QXjnYwSxw05Lgd+r 4=;
IronPort-PHdr: 9a23:HePAWRQlWWEN0ESIdDl22pt9a9psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiA2AcdPT3du/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A+BgB58X9d/4UNJK1mHAEBAQQBAQcEAQGBZ4EWLyQFJwNtViAECyoKhBeDRwOKcoI3JYlljgyCUgNQBAkBAQEMAQEYAQUPAgEBg3pFAheCWCM4EwIDCQEBBAEBAQIBBQRthS4MhUoBAQEEAQEQER0BASUHCwEPAgEGEwECAQEBIQEGAwICAh8GCxQDAwMIAgQOBSKDAAGBHU0DHQECDJF3kGECgTiIYXOBMoJ9AQEFgTcCg1cNC4IXAwaBNIt4GIFAP4ERJwwTgU6DVkcBAQIBgWYPCQcGCYJVMoImjEwfLwOBfDWFJYkdjh1BCoIihwWJe4FJgjcbgjWHR4QliniDO5JaggiObgIEAgQFAg4BAQWBaSE3gSFwFTsqAYJBgh4kDAUSgQQBCIJChFk7hT9zAYEojioBgSIBAQ
X-IronPort-AV: E=Sophos;i="5.64,514,1559520000"; d="scan'208,217";a="332735466"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2019 20:37:49 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x8GKbnY2017473 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Sep 2019 20:37:49 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 15:37:48 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 16:37:47 -0400
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 16 Sep 2019 15:37:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdznjZWqojlRj3NtFce8MprKk4zWvhC4/RGp8eJI1hzd/V7/2Lf/LE8FHA8gkPHCsPEMMTebhHWS2FtehcSLVJFO6E2QdivY7J0QKPh06YilMU3nzwSrsgP0B3d7Ho3Vf5u7Numof3ELO5xzgyncmhULVW/HTe7B0hP9lyz3l4Upa81coDhPyAYvWqEfCL4RuqKyOOvtoxZ3Gnfgb6QhI0KJ4Z3d+EWTZ1l6TE3tZEWL1YEm4+1bbTbo1LbX+1npLDmcGd+spFm4Dt6GDO45/MY1hqir8zYiab9kZX5u04+vLlRxeaXHMbZ+9V8kvMd0yQz7KGMXzp7jdPS8YvEE5g==
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=ZG0ij6HnPm7+gtVyJUF0IoSTnalXEANuUTS4V1tGDg4=; b=lYeAAxuDlmHdXilHfcIch7z6rRhHjdftBRNqowTdhN7lQN4EzvLgO2wUgyOodOmV62mWu5Pi18LsYr84H2hmflwQGolZPl2ifUQ+FHGcMmlLVcZb/WS8pEv+KxUwiYD/xBu0/LiNDKXVU+VLpsFMCsXPCLBin8QVi3nVVehsyPzz2wV8eUbrWIy6QPB11eGKEeSLXDIfVSTeLyXw4aacyYzX5KlHmQHhgZciUlGK1BfdZDyiDH0fOvO8BNlYyerXDMfgRmf/m+YnA7M6j1WPW94K8PFAIr5Xx4AY3o+moSwx9NJ9kW4/FCJI02rJSCXDvF9UQWuHXgSDD9uD/gIl9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZG0ij6HnPm7+gtVyJUF0IoSTnalXEANuUTS4V1tGDg4=; b=qBrp6jC50bCuhnVxU93N9KKXdY5AP43xTV3eTElS3SywrjQ6u2XjuJt+KPf/VUsm2RsSddsdGRTcnSskqlcYWkaTWk/57oeLNae/ytla7XtStBdCnWXYmpGpcuiwg4v02kUiWQhxMkx+Z3x+Zw2Yq433rzT1X9ZlhWxyc4XhrnQ=
Received: from BN7PR11MB2594.namprd11.prod.outlook.com (52.135.246.159) by BN7PR11MB2771.namprd11.prod.outlook.com (52.135.252.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Mon, 16 Sep 2019 20:37:45 +0000
Received: from BN7PR11MB2594.namprd11.prod.outlook.com ([fe80::b5f5:4cb9:14c0:618b]) by BN7PR11MB2594.namprd11.prod.outlook.com ([fe80::b5f5:4cb9:14c0:618b%4]) with mapi id 15.20.2263.021; Mon, 16 Sep 2019 20:37:45 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: Mark Smith <markzzzsmith@gmail.com>, "EXT - daniel.bernier@bell.ca" <daniel.bernier@bell.ca>, "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>
Subject: “SRV6+” complexity in forwarding
Thread-Topic: “SRV6+” complexity in forwarding
Thread-Index: AQHVbM6YoJK0HEB+Dkyan1pH9OVf5A==
Date: Mon, 16 Sep 2019 20:37:45 +0000
Message-ID: <6EA6F7C0-BEB2-4749-A6AB-62B1337213B2@cisco.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>
In-Reply-To: <BYAPR05MB5463A04B05B4BD6AA294F7F0AEB00@BYAPR05MB5463.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ddukes@cisco.com;
x-originating-ip: [161.44.212.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0451ff20-ba2d-4c75-cbc0-08d73ae5bb2c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN7PR11MB2771;
x-ms-traffictypediagnostic: BN7PR11MB2771:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BN7PR11MB277132A60B64655820D42FA9C88C0@BN7PR11MB2771.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0162ACCC24
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(366004)(376002)(199004)(189003)(51444003)(99286004)(6436002)(606006)(236005)(186003)(5660300002)(7736002)(66574012)(53946003)(102836004)(53936002)(6512007)(86362001)(6306002)(54896002)(478600001)(4326008)(486006)(36756003)(14444005)(256004)(476003)(11346002)(446003)(26005)(2616005)(54906003)(53546011)(6486002)(6116002)(6506007)(966005)(14454004)(316002)(33656002)(76176011)(66946007)(64756008)(66556008)(66476007)(76116006)(91956017)(66066001)(66446008)(71200400001)(81166006)(2906002)(25786009)(81156014)(71190400001)(8936002)(3846002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2771; H:BN7PR11MB2594.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4Ow6i6i/hftCqBAB+AIh1+ifzJ0GmVoe8tlDl2etg8KXRSCyavxhx3jcsq9W9lq71R6W2qG3pxQcJ9D/KjnOe8iYI62SKsM21xuJFX3OprhU+81SilwuqUmILTYUQ0bryGAqtHc8dYByhMFeldwdYjniehsqY/RUlToLfWuH6SMzxtnlPMY7PKX8nR6G+LKyVRZOiPvuRC1qE0WV5sT69GOG1ZkZefQt76F1kLQDZ0iA2qi5A/yPZrdyCbyw+U97h7q6Z/ynfxXdtEAxmI8tMOSGi4SwnZi6RpBgQsySyOOeT2FBkgknsheSCCeijqqjlgAQ+DbU0HweDRB2+vzZID8wBgPK3t2l8V++kEGrFWu1973tQ7uO378k9C1bfORxnZC48wR35SjpNc7FrSYGXqB0fAQAtqZCMrxOTT3ai2Y=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_6EA6F7C0BEB24749A6AB62B1337213B2ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0451ff20-ba2d-4c75-cbc0-08d73ae5bb2c
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 20:37:45.6572 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yrpDqblXPgXnQCiCNVMBOcQc1KdXfEulpT00Kxdx6Kl94AG0h2UZGmGZticVIu8MzESOoa0MuOc0b89+UJQJEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2771
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/F49z8CEX_lMyF4-qMgiBLLqj_mM>
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: Mon, 16 Sep 2019 20:37:55 -0000
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:rbonica=40juniper.net@dmarc.ietf.org>> wrote: Mark, I think that you may have exposed yet another elephant in the room…… IPv6 defines a robust extensibility architecture, that includes multiple extension headers. Initially, IPv6 adoption was slow and router vendors were not highly motivated commit extension headers to ASICs. Also, in those days, ASICs were not so capable as they are today. From the above-mentioned data points, we should not infer that it is beyond the capability of a modern vendor to develop an ASIC that supports a more complete set of extension headers. Two things have changed. As IPv6 adoption progresses, vendors are becoming more committed to IPv6. Beyond that, ASICs have become more capable over the decades. We shouldn’t abandon the IPv6 extensibility architecture based on a claim that ASICs cannot and will never be able to process multiple extension headers. Ron From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Mark Smith Sent: Thursday, September 12, 2019 1:30 AM To: EXT - daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca> <daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca>> Cc: Rob Shakir <robjs@google.com<mailto:robjs@google.com>>; 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>>; xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>; Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> Subject: Re: [spring] Beyond SRv6. It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its forwarding, and matches on the Destination Address to determine if to perform deeper packet host processing. You're building much more complicated forwarding services if you're going to be marching on TLVs etc. past the IPv6 fixed header. However vendors and carrier engineering groups like selling and deploying new gear, so I suppose that's ok. They don't have to operate it or fix it when it breaks. On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, <daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca>> wrote: +1 The ability of using a single SRH to convey behaviour information wether they are per-segment or per-path has proven to be very simple and quick to define in various data plane targets. At first analysis, trying to replicate with CRH + DOH variants, the logic required for service programs is more complex. What happens if I need TLVs mid-point in a path but not at its end (e.g. referring to the Ole's ACME analogy) ? Would they now be defined in a seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested midpoint devices will have to lookup beyond the TLVs to get to CRH for next segment ? Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$> correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH. I fail to see the simplicity there. Dan B ________________________________ From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn> <xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>> Sent: Wednesday, September 11, 2019 8:57 PM To: List Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk Subject: [EXT]Re: [spring] Beyond SRv6. Hi, folks, Last year China Telecom begun to implement SRv6 trial in Sichun province for the bearing and interconnection of video platforms which are located in different cities, service agilities,secure sepertion, traffic steering and other features of SRv6 have been demonstrated in this trial. Based on this, SRv6 will be implementated in larger-scale in CT. No technologies is 100% perfect,I agree that compression mechanism is needed to reduce the the overhead of long SID in the long term, but it is better to be compatible withe SRH, instead of designing a complete new one. CRH is a complete new design, it move the complexities from SRH to DOH. Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network (APN). Meanwhile, we should consider more on how to implmement smooth transition and protect the network assetof carriers. Best regards Chongfeng From: Dirk Steinberg<mailto:dirk@lapishills.com> Date: 2019-09-09 21:31 To: Gyan Mishra<mailto:hayabusagsm@gmail.com> CC: SPRING WG List<mailto:spring@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; Robert Raszuk<mailto:robert@raszuk.net>; Rob Shakir<mailto:robjs@google.com>; Tarek Saad<mailto:tsaad.net@gmail.com> Subject: Re: [spring] Beyond SRv6. There seems to be some confusion regarding TI-LFA. A couple of comments: - Remote LFA tunnel is not used with SR, only TI-LFA which only operates on the node that is the PLR (point of local repair). - Any encapsulation on the ingress PE with or without EH has nothing to do with TI-LFA except for the special case where the ingress PE itself is the PLR. - TI-LFA is not an IGP extension and does not require one. It is a purely local computation based on IGP topology. - The PLR for TI-LFA may need to insert some SIDs into the SID list to steer the packet around the failure. For the LFA base case no SIDs are needed at all. If SID insertion is needed, the PLR will push the required number of labels in the MPLS case. For SRv6, the equivalent operation to the label push is to insert an EH with the required SID list. The packet will already have been encapsulated on the ingress PE and in the most common Internet or VPN base use case it will not even have an EH so that this EH insertion will result only in a single EH.. Alternatively, the PLR could also be configured to perform encapsulation with a new IPv6 header using the repair SID as IPv6 destination address, without needing any EH. This will work for the vast majority of cases. Remember that one 128-bit SID in SRv6 is in most cases equivalent to 2 MPLS labels, i.e. a node label plus an adjacency SID can be encoded in a single SRv6 SID. Only in extreme cases would the PLR need to add an EH to the new IPv6 header with more SIDs. - EH insertion for TI-LFA has nothing to do with stitching SRv6 domains. Hope it helps. Cheers Dirk Am 08.09.2019 um 09:19 schrieb Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>: >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.. _______________________________________________ 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!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5aWDOXgb$> Juniper Business Use Only -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- 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