Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Mon, 04 May 2020 09:59 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99DC3A0768; Mon, 4 May 2020 02:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_BTC_ID=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=UqVoXfIs; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=fZ+X/ZaF
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 JnijVT-BRMIJ; Mon, 4 May 2020 02:59:35 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.2]) (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 488093A076C; Mon, 4 May 2020 02:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1588586372; i=@ecitele.com; bh=dt+yydHIDmlmDnRGR4LXgluGQezH4sWOw40pNCgur5s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UqVoXfIsKMfPAlC//mrrp1ODyVS2zIxAVLZ5drzwxVUYh+sUF8UTYViOwRnWJhnFJ RZ2G0jbFmDJpIc//f9SpRNGD8fD9LuIEnBLaUKz62C2HFdyrNqxKAo6QiMhmlVI7z0 mXb5sboD0NzSqQ1BBf78ZVS3YP+095G7U6qFx0+A=
Received: from [100.112.193.214] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id 0D/A4-40611-E77EFAE5; Mon, 04 May 2020 09:59:26 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfUwbZRjn7V2vB+vhUZh9JaClMhnM61qc2gV nWJYtYLJkMeomkcF1vdGSttS2jOLHMt2iQltljCwwnFSkQMrnYBGGMmfdxsd0IMwJcyhgsVLA keFGsAbscTD1nze/j+d5fs+bPDgiGseiccZqYUwGWifFwlDRnP0c9bav5aD8a1+K0vHT5zzlh Uo7ppzoHkeVvd56vrLzi/cx5eBsAFGOTHYjyp7BAEjF08oC5/hpNTVLvLQf3/1BkLbUVczbh2 bwtQZVnjWbr5mqb8SM5Sqrx9fFPwb+zC4GYTggXQi0N9oBR66iMFC8yOdIO4C9PaUClqBkEwJ n5u+tEhH5KQ/2fz+PcuRnAMs9HbxiEIpj5A7Y1jCGsUYUeQfAitNzCEsQsg/AuoVZjK2KJFPg t+3dqx1R5HNwpvM2xuE98PQtu4DFKBkPV5yzwRocJ0gaHj+VyaVV8uD4V60IWxMaTOv5pQGwG JAPw8X+xtWZCCmGt7xVqxiSJKz5cgDh8EY4/evy2u9sAN6cLMHYAEhK4P0ZnKuJhUNVNsDJj8 Pzv2dycC8c8UOu4knoGR4TcHI8XPYUcrIR2tsCa0FPwIWpG2s4BjpaB1AOPwrdjgl0XR8f6cB KgPzMf3Y+E5yKkImwpWsrJ8fBMtuEgMUEGQH7KryoE6BuoFSZtDkai57W6iiFXE4pFMmUYnsy lfzUNhn9BkXLmHyqgDFbKIWMLjDLzIX6Qzq1zMBY2kDwwNTGS/5O0Nd0R+YBj+A86UbC8VvLQ VG4Kk9dqKHNmixTvo4xe0AMjkshcZT1IkxMDmM9rNUFz3TdhrhQGkXcZW3CbKT1Zm0OZ/WD7X jJ9NlqBP9j6bPge/msqxoRoYY8AxMtJorYBpJt0OQbHoxbP/whEBsdSYCQkBCR0MiY9FrL/30 /EONAGkmksFOEWoPlQao/uBAvuFDScjO7kIX+14o+xnvRN/rCRXuq0D+x+zg9XG+N212eLZk6 UBcfq3JWpReI1efDTZemkis3JOzJPXptTlG27eP0u6+XbrX57uc0f/Jh7WS7JO7waysuVdH1N 8Oojm/+znwL825p2P+SMTXx+dqLM4fUEfS0a3Tn3tyiU31JVG7dhVck12+4qZiTQj7mPnHg1S tXmGqHLquJSXxMvMMtXdq/kxL9lff0ZOszWOlHGVuyewsWkAzhB4N8yv6yvn+l9L1nK3rn30E lSvWsMMum2IwP7zoy0HTS0rCruzwh/eqmsWYgtRLV3suu+JshQzEbnKO3TSdqjyzWX1u4Fy6v 2/ddnDPBHWoztGwu3DT0UKwUNWtoRRJiMtP/AFh//c1zBAAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-18.tower-265.messagelabs.com!1588586363!223137!1
X-Originating-IP: [18.237.140.177]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.50.1; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 19312 invoked from network); 4 May 2020 09:59:25 -0000
Received: from p01b.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-18.tower-265.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 4 May 2020 09:59:25 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IM0u5KAJ/1dtdg6jbdpxCvcUG0uQ3ytYTAYofbgaAz84j6SmsZwtp4SzP6rrbqIaPt9Ui4boRfLjcb5xY+V/s3nj0CblNI1l2KeGerYijCH7PthrOa5rA2ANmsb9pXw6OE+eUuO5IJ3c/QOati9HnUSvvStOTK8MzVEpIBor8RouLLQ1jitdTIwiUqWdKAUIj+gezKd6Mrua1hIZmsDYjStcmgcbcJjSK1xMz5sZcl0S2UNV4ZcU6Gjwf7sVyhZ6wj+BW1WrWD0fqZMm1rKfES/CKCV5Eug7g24iQyZniTtscD9EpBnscCB0HqmNAfzt024nj4q/4syhBZDgcJW8hQ==
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=/xk497e7qX1Ux85iF520Fyi1gmS6BnMgB3yT+Uquzjg=; b=Ag4DWvP2kY400Tg2XIDHtYGexAYrycLE/hFHef+EJV0V0UwhM+Vw++FgXbDT9a7V55dFwpgDnGQA0j7VIRQmkjWkj3GWKU+tz+7ngz0lUxBzlJG9ZoxjGcfSfgMuNmkdteiE5OtQhNj6IMkyC2mU4STQLuJ061sjUoBlQeedY26NqZT6FlHvmBr/Hu3PQWxXNGjcWKrQXXL4QXYf93kUGE96hbyFY9xw1tjZrFShdfPa1V0ZfDelFEceY7yPQAIeUas/mvt+N4Q22CZMKJpEolyx14GDdCHjGJOfTK4sb2BS4apKfopTPDvT/+jCxaRtpicgTKMkxjOzvZkAbCgZkg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/xk497e7qX1Ux85iF520Fyi1gmS6BnMgB3yT+Uquzjg=; b=fZ+X/ZaF0wulYOfFv8lm27VnbomFkayPX9m3I/hYM6TEUWwRnyyF8Ztcy9exMc55NjH5YhuyEIExuLiXZMaEn2Y88yLWUpBEVvgq4FCOdKIv7asSbWtznZjptztAQaCdzaeoL8HQsqS6lMpkHBTPIvY8tDg/mlmjmGNJexP4UI0=
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com (2603:10a6:208:2::12) by AM0PR0302MB3393.eurprd03.prod.outlook.com (2603:10a6:208:11::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.27; Mon, 4 May 2020 09:59:20 +0000
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::a0f0:9917:35:4260]) by AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::a0f0:9917:35:4260%3]) with mapi id 15.20.2958.029; Mon, 4 May 2020 09:59:20 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Peter Psenak <ppsenak@cisco.com>, "shraddha@juniper.net" <shraddha@juniper.net>, "cfilsfil@cisco.com" <cfilsfil@cisco.com>, "ketant@cisco.com" <ketant@cisco.com>, "arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>
CC: "lsr@ietf.org" <lsr@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>
Thread-Topic: SRLG usage in the IGP Flexible Algorithm draft
Thread-Index: AdYfAAtyRauA7slnSUiSBLNPZjFKDgAntx2AAF+Zs5AAM2E5gAAD8npA
Date: Mon, 4 May 2020 09:59:20 +0000
Message-ID: <AM0PR0302MB321713E0EE03D3431C8D5AE99DA60@AM0PR0302MB3217.eurprd03.prod.outlook.com>
References: <AM0PR0302MB3217968E975EDC3B74F091849DAA0@AM0PR0302MB3217.eurprd03.prod.outlook.com> <bf999a11-86cb-000f-4ede-653e7b063313@cisco.com> <AM0PR0302MB32171A34910751F32C94D6E89DA90@AM0PR0302MB3217.eurprd03.prod.outlook.com> <aa145505-3885-08f6-907f-a41aec3cd6ba@cisco.com>
In-Reply-To: <aa145505-3885-08f6-907f-a41aec3cd6ba@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [79.178.58.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c360a653-4e6f-499d-b4d6-08d7f011d0a3
x-ms-traffictypediagnostic: AM0PR0302MB3393:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR0302MB3393B58B2CF8E9C9BC31FE179DA60@AM0PR0302MB3393.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 03932714EB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tdeXjA8FgoKXlwieOjV9H76QlZwSQU2s4H4wdMTHB3RBxbBGQFLeEFFo4uSJ+rQuReJDZdfUaKbfdL6dxr5AH90bbFCZDdb9ua+DxW2bxY3wFcmS28JNbN5djrdI7+aVYDe5U/9pPjLaqVNXqSqOIRMpEjXJO9W3Wq7PYyZ2W67g5yBuMlFXwYyi91qeGu5r4gsBi8JpJyhds56xIYzeHsuxVBZ6T4/D8XzkNJPz2vq9qt71Ge2PYxTX/WctZVO74gwvH6CGcvV7TuOoNRAY4DLJukbeO3c3NDhcF0aIwWDGaq7S00Is57xY2rQPCMYRaGrSYfQWWwG9G1vxf6CP4IZHDZnFhQGgyIkPM76WpxVocFRYdcc91v3MjG7S8LPkA9K5YsmjGrL7hSW5i8/o47cmgN6j4oG1Gb2RiBEuqbGrQWZrfDfnU9WGc2RUuBPCygeoxujcCS0+6F3mxX5j92DuOKfozexUAEejilrsjeA5mSJzG1hfswPo/gijksWhDTVLdDiRLa+9k1ib2Pi06w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3217.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(346002)(396003)(376002)(39860400002)(2906002)(107886003)(76116006)(64756008)(71200400001)(478600001)(52536014)(4326008)(86362001)(7696005)(6506007)(26005)(53546011)(55016002)(66476007)(9686003)(66446008)(66556008)(316002)(110136005)(186003)(54906003)(5660300002)(66946007)(8936002)(8676002)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: GZN07C0NsmLUroFlYC1rg/IEmJ/TW/LU5sPWsroVFTkDabgqxG3WUE29HgELTKyfZhawqnAuENSnPWyeli12/gJBK3Oox1JwP74OYoGj+z4/n95/PZOhN/X0oiaa8g/H27dJ8Lu5rAzkK1ot9hJ872wlW6Lpgdyic9oA2iFXnx68AUAbBCeKIz78WUbZ0S2mxcvfxzZL/2oCMesZbIf82XhgzEy87se6c+z14FtS5SBylAV9MPIcLGyQNLEeFKE+ugwrLjthLN4GJvu5txNIGFkOCG8eau8x/n2sisXStMKy9Gha8qtY8usLKSIQxyFMniZpfEltCsdMEulnKGc6xZPUK8/3afFvnoBXYkSAJDg/iWF7mUnEBWqwUg4LQ2pPTG6I8PwZxEtcgTV3kLJLCulOqxgctzLSga8JKTIBiutI0Bu+Msso7XoRhvxBZwdmGydquUE1OzEQ1LtK8oGRgoq+XzpFiJa42tXfCnbifKmpqICNqkGfVvY4Fb50GKUj439GcLdxdUc8yAAWOvdS1vL3HAIIgb3CKpdeO2bks1QjqZxSgU3rWIahDgVeMDhH3CwGeXZWP+WQgDC7rZzWCPUpMSX15EdpgizYHeLpvMD7JCKy70MEYQKIxNthlaPmSkbahKryYqe3iFtnBjvru89vPU8Q02N9NoTSEXRBWl7+6tlChTmRB5dj8Y7b7WB8twCvcAHoxh1vnYO99BkjgBWP08LMYWnnuKmnaYHlcYLfSEihFHlVcTEUXnO2vvspu1cDJASLDVPS71XXHx4U7hSt5xnr3tyPVlFJ3ef/ntw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c360a653-4e6f-499d-b4d6-08d7f011d0a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 09:59:20.0395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gOahgROYQQcV635xPyK2YRDIQWBmfZ0L+irZILCXC7jgJl6F/xcy/O4IScHZSV0YKyI92zX9lwik9IwJebhcvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3393
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/vY8SQ9Vv9H5IUTEVIDzd5ofABjc>
Subject: Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2020 09:59:37 -0000

Peter.
Again lot of thanks.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Peter Psenak <ppsenak@cisco.com> 
Sent: Monday, May 4, 2020 11:06 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; shraddha@juniper.net; cfilsfil@cisco.com; ketant@cisco.com; arkadiy.gulko@thomsonreuters.com
Cc: lsr@ietf.org; spring@ietf.org; rtgwg@ietf.org; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>om>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>
Subject: Re: SRLG usage in the IGP Flexible Algorithm draft

Hi Sasha,

On 03/05/2020 09:46, Alexander Vainshtein wrote:
> Peter,
> 
> Lots of thanks for a prompt response.
> 
> My reading of your response is as following:
> 
> There are two different ways in which SRLG information can be used 
> with Flexible Algorithms:
> 
> 1.In a context of a single Flexible Algorithm, it can be used for 
> computation of backup paths (e.g., as described in the TI-LFA draft).
> This usage does not require association of any specific SRLG with the 
> given Flexible Algorithm.
> 
> 2.In the context of multiple Flexible Algorithms it can be used for 
> creating disjoint sets of paths by pruning the links belonging to a 
> specific SRLG from the topology on which a specific Flexible Algorithm 
> computes its paths. This usage:
> 
> a.Extends the definition of the topology used by a given Flexible 
> Algorithm that can be defined using Admin groups (a.k.a. affinities)
> 
> b.Facilitates usage of already deployed SRLG configurations where such 
> configuration have been in place
> 
> c.Requires explicit association of a given Flexible Algorithm with a 
> specific set of SRLG as defined in the current Flex Algo draft.
> 
> The two usages mentioned above are strictly orthogonal.

yes, above is exactly right

> 
> If the understanding above is correct, it makes to me sense to add the 
> corresponding clarifying text to the draft.

sure, I will add it in a next version.

thanks,
Peter


> 
> Regards,
> 
> Sasha
> 
> Office: +972-39266302
> 
> Cell:      +972-549266302
> 
> Email:   Alexander.Vainshtein@ecitele.com
> 
> -----Original Message-----
> From: Peter Psenak <ppsenak@cisco.com>
> Sent: Friday, May 1, 2020 12:57 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>;
> shraddha@juniper.net; cfilsfil@cisco.com; ketant@cisco.com; 
> arkadiy.gulko@thomsonreuters.com
> Cc: lsr@ietf.org; spring@ietf.org; rtgwg@ietf.org; Michael Gorokhovsky 
> <Michael.Gorokhovsky@ecitele.com>om>; Ron Sdayoor 
> <Ron.Sdayoor@ecitele.com>
> Subject: Re: SRLG usage in the IGP Flexible Algorithm draft
> 
> Alexander,
> 
> On 30/04/2020 17:21, Alexander Vainshtein wrote:
> 
>  > Hi all,
> 
>  >
> 
>  > I have a question about the proposed usage of SRLG in the IGP 
> Flexible
> 
>  > Algorithm
> <https://clicktime.symantec.com/3Wn8dBNRoEXXTU1kJz6RrsR6H2?u=https%3A%
> 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-flex-algo-07>
> draft.
> 
>  >
> 
>  > This usage is defined Section 12 of the draft with the reference to
> 
>  > the SRLG exclude rule as following:
> 
>  >
> 
>  >
> 
>  >
> 
>  >        2.  Check if any exclude SRLG rule is part of the
> 
>  > Flex-Algorithm
> 
>  >
> 
>  >        definition.  If such exclude rule exists, check if the link 
> is
> 
>  >
> 
>  >        part of any SRLG that is also part of the SRLG exclude rule.
> 
>  > If
> 
>  >
> 
>  >        the link is part of such SRLG, the link MUST be pruned from 
> the
> 
>  >
> 
>  >        computation.
> 
>  >
> 
>  > This looks effectively undistinguishable from the usage of the 
> exclude
> 
>  > Admin groups rule as described in the same Section 12 of the draft:
> 
>  >
> 
>  >        1.  Check if any exclude rule is part of the Flex-Algorithm
> 
>  >
> 
>  >        definition.  If such exclude rule exists, check if any color
> 
>  > that
> 
>  >
> 
>  >        is part of the exclude rule is also set on the link.  If 
> such a
> 
>  >
> 
>  >        color is set, the link MUST be pruned from the computation.
> 
>  >
> 
>  >  From my POV, with such a definition, there is no need in the
> 
>  > dedicated “Exclude SRLG” rule as part of the specification of the
> 
>  > Flexible Algorithm, since such the SRLG Exclude rule can be 
> replaced
> 
>  > with a matching Exclude All rule  using Admin groups.
> 
> there is one very important point. Maintaining the affinities is 
> operationally complex. Some networks have already deployed SRLGs. If 
> SRLG exclude with flex-algo gives people what they want, asking them 
> to deploy affinities would be redundant. That's the main point.
> 
> Simple use case:
> 
> I have two SRLGs in the network. For some specific traffic I want to 
> send the data via two independent streams. I want to avoid single SRLG 
> failure to affect both streams. I define two flex-algos, each one 
> excluding one SRLG. No need to define extra affinities. This is btw 
> not an academical example, this has been requested by real users.
> 
>  >
> 
>  > I also think that such a usage of SRLG does not fit the needs of 
> the
> 
>  > TI-LFA
> 
>  > 
> <https://clicktime.symantec.com/3GhKPQ2JAgebW7vLidLjXRx6H2?u=https%3A%
> 
>  > 
> 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtgwg-segment-routing-ti-lfa-0
> 
>  > 3> draft that considers an SRLG as a resource that fails when any 
> of
> 
>  > the links/nodes comprising it fails. E.g., it says in Section 2:
> 
>  >
> 
>  >     The Point of Local Repair (PLR), S, needs to find a node Q (a
> 
>  > repair
> 
>  >
> 
>  >     node) that is capable of safely forwarding the traffic to a
> 
>  >
> 
>  >     destination D affected by the failure of the protected link L, 
> a
> 
>  > set
> 
>  >
> 
>  >     of links including L (SRLG), or the node F itself.  The PLR 
> also
> 
>  >
> 
>  >     needs to find a way to reach Q without being affected by the
> 
>  >
> 
>  >     convergence state of the nodes over the paths it wants to use 
> to
> 
>  >
> 
>  >     reach Q: the PLR needs a loop-free path to reach Q.
> 
> I see no conflict between the LFA draft and flex-algo one. If you do, 
> please be precise where the conflict is.
> 
>  >
> 
>  > To me this suggests that SRLGs are only relevant when computing 
> backup
> 
>  > paths for specific failures, e.g., an LFA for failure of a link hat
> 
>  > belongs to a specific SRLG must be computed in the topology from 
> which
> 
>  > all the links belonging to the same SRLG are pruned. This
> 
>  > understanding matches RFC 4090 that states in Section 6.2 
> “Procedures
> 
>  > for Backup Path
> 
>  > Computation”:
> 
> SRLG is a mechanism to express fate share. I see no reason why SRLG 
> could not be used for other than LFA purposes.
> 
> thanks,
> 
> Peter
> 
>  >
> 
>  >        - The backup LSP cannot traverse the downstream node and/or
> 
>  > link
> 
>  >
> 
>  >          whose failure is being protected against.  Note that if 
> the
> 
>  > PLR
> 
>  >
> 
>  >          is the penultimate hop, node protection is not possible, 
> and
> 
>  >
> 
>  >          only the downstream link can be avoided. The backup path 
> may
> 
>  > be
> 
>  >
> 
>  >          computed to be SRLG disjoint from the downstream node 
> and/or
> 
>  >
> 
>  >          link being avoided.
> 
>  >
> 
>  > If SRLGs are only relevant for computation of backup paths, it is 
> not
> 
>  > clear to me if they should be part of the definition of a specific
> 
>  > Flexible Algorithm.
> 
>  >
> 
>  > What, if anything, did I miss?
> 
>  >
> 
>  > Regards, and lots of thanks in advance,
> 
>  >
> 
>  > Sasha
> 
>  >
> 
>  > Office: +972-39266302
> 
>  >
> 
>  > Cell:      +972-549266302
> 
>  >
> 
>  > Email: Alexander.Vainshtein@ecitele.com 
> <mailto:Alexander.Vainshtein@ecitele.com>
> 
>  >
> 
>  >
> 
>  > 
> ______________________________________________________________________
> 
>  > _____
> 
>  >
> 
>  > This e-mail message is intended for the recipient only and contains
> 
>  > information which is CONFIDENTIAL and which may be proprietary to 
> ECI
> 
>  > Telecom. If you have received this transmission in error, please
> 
>  > inform us by e-mail, phone or fax, and then delete the original and
> 
>  > all copies thereof.
> 
>  > 
> ______________________________________________________________________
> 
>  > _____
> 
> 
> ______________________________________________________________________
> _____
> 
> This e-mail message is intended for the recipient only and contains 
> information which is CONFIDENTIAL and which may be proprietary to ECI 
> Telecom. If you have received this transmission in error, please 
> inform us by e-mail, phone or fax, and then delete the original and 
> all copies thereof.
> ______________________________________________________________________
> _____


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________