Re: [spring] Beyond SRv6.

Ron Bonica <rbonica@juniper.net> Fri, 13 September 2019 00:40 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 8AE5E1200B4; Thu, 12 Sep 2019 17:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 7BRjihoOPrLn; Thu, 12 Sep 2019 17:40:39 -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 4E19D12002E; Thu, 12 Sep 2019 17:40:39 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8D0cox8015364; Thu, 12 Sep 2019 17:40:24 -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 : content-transfer-encoding : mime-version; s=PPS1017; bh=pbbGpnMXNQT+L/l8Slcc4YDu0RJKcJuy6h4jfcW1afY=; b=OY9nDV38ytutVYp71qqb6dLF/R2Ou4dZn7I9F1SGZ6Didlj8zKFhbKGUIR5kEmrgN64F XcUCZ//w99iyNDv4EoHYkkM4TXKW/VEDEq01qPtcE1TLjws95whbITIDi1aDSXguUf2M aFAkK0R1LXMvX7987eeCshsAKtiyD3P0sjjXlCNJ/CjfLR4cSX+LJnWTKEFtjypiok93 ssrVnmVunjWKT1Xmve2lAK3qQISNw5ihgmOhh0y3l+zZzDqtu3ZJSMeafc0+RM/WYl+d lrANaCeKXk2HvET/4EaraoEdhYvRmbgaXtj/uZ1erJycCSUjnelN2w4ZlLkD08vZHCOJ yw==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2050.outbound.protection.outlook.com [104.47.32.50]) by mx0b-00273201.pphosted.com with ESMTP id 2uytd8rpwp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 17:40:24 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nht4lt88wJ0dlsWChD6fHoS2Ieo/nlt9mSx3eaYQ9WQxw0h/AY6XXtHgkFbNH3nX+shQ15t5lu+GjQT+bBnqo+mR6/G9U+FnZxzdB/rJbNDlFepaakF5xyU39gLzDpa9n6iXqFEHQmYH89DKFEMGv5gUOB42vd1MZ0DNEsvT+DHZZC7UjWDmChSUer9wb7EIN4zPmvmFtTIkrFXTkTuEMn5teldupYpYnTThYeZ8bUq5typx5XOkB9AB56/y3Umv+Mh7V79E/hSAf6YOIytt1WmSba3cPQumXd9EuhzcZJKnif64CZu9xSdeTYWGYy8movw0aZv30qWM+KyAlgRTMg==
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=pbbGpnMXNQT+L/l8Slcc4YDu0RJKcJuy6h4jfcW1afY=; b=Vg876YOA903GiHpH84s1A3K5bYEA2XBmbuQ3704T6YGTGfuKRcIdz04If9OsubYsJICu6O05G8jVh/8FZQpqMEtp5MFeJ2jHmkoLXmOq87jggNNjTlNDXNHi/0Tr3ex7OlSFUt56VHoFtOROgMMR/dQlo+AL5TTg6kIKCf+VcH52mDa816iyg1aLuCzXP1omn58QgdsbKLvd9ni2EvnAxM4QU08eGk7iDk6p2hS3CrskR8p9NNlvCjFtz66JXW/LOlxktxy6ySPQb19aGLW//Vb0ldnQ74/W9i/ML9zMzBE97/u1y8PSNa55Q38n5UYsDACrhhH/Ca7dbFaIlg/Wgw==
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 BYAPR05MB5639.namprd05.prod.outlook.com (20.177.127.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.10; Fri, 13 Sep 2019 00:40:20 +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.2263.018; Fri, 13 Sep 2019 00:40:20 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Rob Shakir <robjs@google.com>, Tarek Saad <tsaad.net@gmail.com>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVaZd8SaOY2u3WVEC2YBfBMljE6acoYE9AgAAOgQCAADHmAIAAIZQQ
Content-Class:
Date: Fri, 13 Sep 2019 00:40:20 +0000
Message-ID: <BYAPR05MB5463943D34AF4E6322163934AEB30@BYAPR05MB5463.namprd05.prod.outlook.com>
References: <5B57874F-8C54-4E82-BB55-A2B6585B6AE6@bell.ca> <BYAPR05MB5463BA9F2C38745F4BDF5C28AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <CAOj+MMHvc-P=j0dvs0uMS+NmapQ-RbcgzC4OLg5evUjYpcaoQQ@mail.gmail.com> <704dbd1e-b1e6-0924-42b1-6bf19fa785fe@gmail.com>
In-Reply-To: <704dbd1e-b1e6-0924-42b1-6bf19fa785fe@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-13T00:40:18.7977591Z; 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=8500049b-1556-4363-86d7-69a090afab3e; 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: [66.129.241.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6013849c-bbf8-40d1-a05b-08d737e2f504
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:BYAPR05MB5639;
x-ms-traffictypediagnostic: BYAPR05MB5639:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <BYAPR05MB56394CB18F0A484DAEFA5F7AAEB30@BYAPR05MB5639.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0159AC2B97
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(396003)(366004)(39860400002)(376002)(136003)(51444003)(189003)(199004)(13464003)(8676002)(66476007)(81156014)(66446008)(66556008)(11346002)(81166006)(26005)(5660300002)(64756008)(66946007)(33656002)(229853002)(71200400001)(76116006)(71190400001)(30864003)(66574012)(66066001)(14454004)(25786009)(6116002)(3846002)(14444005)(4326008)(256004)(478600001)(54906003)(110136005)(966005)(2906002)(55016002)(6506007)(446003)(7736002)(316002)(305945005)(53546011)(8936002)(76176011)(7696005)(74316002)(486006)(102836004)(6306002)(52536014)(6436002)(476003)(53936002)(86362001)(186003)(6246003)(9686003)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5639; H:BYAPR05MB5463.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: it48isfu0wX9a4dHHvCZxGTysYAWS7GabynKT1guplF5VSngvHYEuLqxTcZMBNVMmBai1klOMQlirYeRiMWl2IvlDzqldFYNMU4D5MUZNvcUXoZ8cW5O9CuPR65ndshuRALl/Y5MSGIZnOR0eJB6G1zCdwRefN8g/B5slltgIAGRg60/h1uYohJgn0nq1pynXEXyScSeqGMOlcedbBc9/r2H2H7UJbkBajOO/Kz8PYVUiQnNRuVNhusc7Ne3bCqO4C5gmT/K0Ogk2Mf21amOYVfB0jvjxr60kBHgUg/giwSHFMfPJ/wSWRstaU+U0Sfv5Mfzqr29Aj9EZyFW5CmPEN90P+nbuYxDcDrF5OXwByl3sdcIMqBuusJP7TI65IJHrSJAZgn+powRh8bHgvlIX2EmzdBNk+ZU41Vg6geS5jA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6013849c-bbf8-40d1-a05b-08d737e2f504
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 00:40:20.7483 (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: N/oneIwFoZFXXvVzEZVqD5W9aveDzqFMQSOVb+OhOUxQFnP8gXjAxXuOrxMWxchc9wCMOoiqaYKjmGtSSSJ73A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5639
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-12_13:2019-09-11,2019-09-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 bulkscore=0 impostorscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 phishscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909130003
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9cElcskpu6xiWGG73VSFRaqtLWc>
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: Fri, 13 Sep 2019 00:40:42 -0000

Brian,

Those who lecture you on the poor design of IPv6 extension headers may need to rethink their position. Modern ASICs are perfectly capable of processing a packet that contains both a Routing Header and a Destination Header, so long as the length of each is kept within reason.

                                                                                                  Ron


Juniper Business Use Only

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 
Sent: Thursday, September 12, 2019 6:32 PM
To: Robert Raszuk <robert@raszuk.net>; Ron Bonica <rbonica@juniper.net>
Cc: xiechf@chinatelecom.cn; SPRING WG <spring@ietf.org>; 6man <6man@ietf.org>; Rob Shakir <robjs@google.com>; Tarek Saad <tsaad.net@gmail.com>
Subject: Re: [spring] Beyond SRv6.

Robert,

> But what is most important that common hardware reads just entire 
> header then starts processing. So it really makes much more sense to 
> encode SR SIDs and related functions and their parameters in the same 
> EH rather then scatter them around.

Sorry to get all philosophical, but it seems to me that there's another elephant in the room here (and he's been around for twenty years or so).
There seems to be an assumption that we should design on the assumption that fast path processing is done by ASICs or FPGAs, so header formats should be rigid enough that conditional or linked-list processing can be largely avoided. I've been lectured on the bad design of IPv6 extension headers in a way that only makes sense from an ASIC or FPGA viewpoint.

But anybody who's building the fast path using a network processor doesn't have that constraint and can use the existing extension header design happily enough.

To what extent is this behind the present argument?

Regards
   Brian Carpenter

On 13-Sep-19 07:33, Robert Raszuk wrote:
> Dear Ron,
> 
> I was trying to stop responding but its pretty hard when I see such 
> post like your last one ...
> 
>> A single IPv6 Option, the PPSI, replaces all of the following SID
> 
> Please understand that this is like stating that:
> 
> "A single new additional airport replaces all the planes which operate 
> to the old airport. "
> 
> At most you could say that single new PPSI could contain 2^32 SR 
> functions which you call in your draft as "PPSI identifiers"  From 
> your documents it also seems that you are defining a service 
> instruction identifier in a flat space which can contain the demux for the following technologies:
> 
>       o    Layer 2 VPN (L2VPN) [RFC6624
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc6624__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP6CZEfxv$ >].
> 
>    o  Layer 3 VPN (L3VPN) [RFC4364 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4364__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP0lKDPf5$ >].
>    o  Virtual Private LAN Service (VPLS) [RFC4761 
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4761__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JPyuNYiL8$ >][RFC4762].
>    o  Ethernet VPN (EVPN) [RFC7432 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7432__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP51E8Fug$ >].
>    o  Pseudowires [RFC8077 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8077__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP3gMZTMl$ >].
> 
> 
> It also needs to be observed that putting all of those services into 
> single flat table lookup is not a sound design.
> 
> But what is most important that common hardware reads just entire 
> header then starts processing. So it really makes much more sense to 
> encode SR SIDs and related functions and their parameters in the same 
> EH rather then scatter them around.
> 
> 
> Thank you,
> 
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Sep 12, 2019 at 8:51 PM Ron Bonica <rbonica@juniper.net> wrote:
> 
>> Daniel,
>>
>>
>>
>> Not really. A single IPv6 Option, the PPSI, replaces all of the 
>> following
>> SIDs:
>>
>>
>>
>>    - END.DX2
>>    - END.DX2V
>>    - END.DX2U
>>    - END.DX2M
>>    - END.DT4
>>    - END.DX4
>>    - END.DT6
>>    - END.DX6
>>    - END.DT46
>>    - END.T
>>
>>
>>
>>
>>
>>
>>                           Ron
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Bernier, Daniel <daniel.bernier@bell.ca>
>> *Sent:* Thursday, September 12, 2019 2:26 PM
>> *To:* Ron Bonica <rbonica@juniper.net>; Mark Smith 
>> <markzzzsmith@gmail.com
>>>
>> *Cc:* Rob Shakir <robjs@google.com>; SPRING WG <spring@ietf.org>; 
>> 6man < 6man@ietf.org>; Robert Raszuk <robert@raszuk.net>; 
>> xiechf@chinatelecom.cn; Tarek Saad <tsaad.net@gmail.com>
>> *Subject:* RE: [spring] Beyond SRv6.
>>
>>
>>
>> That was precisely my point
>>
>>
>>
>> Having been involved in pushing SRv6 END behaviours in various 
>> targets, I can first hand say that the primitives behind SRH 
>> processing is quite simple to extend. In your extensibility model, 
>> every predefined or custom behavior becomes a new DOH. On SRH, the EH 
>> does not change I just need to inform the data plane that when 
>> receiving a packet with a specific SID in SRH, do this internal processing.
>>
>>
>>
>>
>>
>> On 2019-09-12, 12:34 PM, "Ron Bonica" <rbonica@juniper.net> 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> *On Behalf Of *Mark Smith
>> *Sent:* Thursday, September 12, 2019 1:30 AM
>> *To:* EXT - daniel.bernier@bell.ca <daniel.bernier@bell.ca>
>> *Cc:* Rob Shakir <robjs@google.com>; SPRING WG <spring@ietf.org>; 
>> 6man < 6man@ietf.org>; Robert Raszuk <robert@raszuk.net>; 
>> xiechf@chinatelecom.cn; Tarek Saad <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>
>> 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 com​plex.
>>
>>
>>
>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-
>> 6man-seg-end-opt-04__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-R
>> aiy6m1Cekp54qt3IjMBM2JPyzmU2AP$ 
>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-
>> 6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe
>> 6qzFFZtlfTRAiabJjCZB0f5dp14y8L$> 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> on behalf of 
>> xiechf@chinatelecom.cn <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 <dirk@lapishills.com>
>>
>> *Date:* 2019-09-09 21:31
>>
>> *To:* Gyan Mishra <hayabusagsm@gmail.com>
>>
>> *CC:* SPRING WG List <spring@ietf.org>; 6man@ietf.org; Robert Raszuk 
>> <robert@raszuk.net>; Rob Shakir <robjs@google.com>; Tarek Saad 
>> <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>:
>>
>>
>>
>> >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
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
>> ing__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3I
>> jMBM2JP8G1SR9t$ 
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spr
>> ing__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJ
>> jCZB0f5aWDOXgb$>
>>
>>
>>
>> Juniper Business Use Only
>>
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM
> 2JPyyOEzqD$
> --------------------------------------------------------------------
>