Re: [Lsr] Generic metric: application-specific vs application-independent

Shraddha Hegde <shraddha@juniper.net> Tue, 17 August 2021 18:04 UTC

Return-Path: <shraddha@juniper.net>
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 F39FB3A2616 for <lsr@ietfa.amsl.com>; Tue, 17 Aug 2021 11:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 header.b=S1lP5Qkq; dkim=pass (1024-bit key) header.d=juniper.net header.b=VVlOZGc8
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 d95XYNwE-MWQ for <lsr@ietfa.amsl.com>; Tue, 17 Aug 2021 11:04:53 -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 BD1B13A260A for <lsr@ietf.org>; Tue, 17 Aug 2021 11:04:53 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17HI0BOW015012; Tue, 17 Aug 2021 11:04: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 : content-transfer-encoding : mime-version; s=PPS1017; bh=1Q0fFUJV0hI4qYRt++Ty5wxvmQYvklt6meFCKzccBxo=; b=S1lP5Qkq2GIVcwjUNhgvjfPwDXoC62w9yH/oPzcV5md/6NskzvgxkyRiQss3sS1P1AnK dSZDe9tZIKkN7J/LSzbXctgRdRAwSWKJ1mGZeBMsA3wezK4PTJglQw23EF32kplneWsl 6fGDHhPGEQzOyCGwaODXaTOPH2UU+iFQbO5ClNK6e/vfZVyQLPSh32gB2WqVXR68wLeb uH+0M9394SNCgSACw+8Fg60Ivu6NTP8UgKvq+2nwH+A/CJYohUJir7LZUjxZqO344Ylp ZBQZzg+yYJYWDxDvGQWLMjThBZjpjiosUSvxsIyUoM/gZ0I94cN14AoWixMF0/7GhTBS zA==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) by mx0b-00273201.pphosted.com with ESMTP id 3ag9pss9ge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Aug 2021 11:04:51 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DCncWymfLeh31WGz2kBJDuDnAn1/WoT8MZT47qkIiorSC7vzdcTWTvQhH4+Nl+lsbPVvKS3hjRLK5aK8l+CKx8UWhxqL978HkUR/0YINRU4a/OXRDK/NTjgJLS2olSEFWtUlvbpQ1FH+RIDXQ/qVsvLe2kk6j2PBLLK1PNAEjBKSbh8tQyPsk7LM6pnDgqDH2AKgflh4OhKwFTrt8G7eT7oJ362X15wsHDxHMOH2ZxOQqFbGRaLTQYbDdE9ztjqHjcVj2PzxdDU5WNXLNTOzFdvWY6pqqUao4DxepvkV0gpASVd58Lfwd8Qa+G329fnDU6WeMZ9/PWhVVs27e67utA==
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=1Q0fFUJV0hI4qYRt++Ty5wxvmQYvklt6meFCKzccBxo=; b=axPS9DxOo2FkRWvDjBPu5cPitnUrwcVnaF+KW/eLCYdyGa97qr0bVrkssmpTF5DCbU/RnNMzVWVroI6gFONkZcgWMkwnAFaTXTMFsddSl5ywFraJch+DSRFDoqBfrPPbQW8VunMfDdvh5fiVNsRWabHZz+WWYkZUeig5lOUHiAvq8rbyGh1GnZfM/XrIAoTBIKscwFyADunTFa/HmQgGEqyeXYNDgDPdcjqyRxtsi/WhYhj6OBCWdUsiYlD79DLKx8nvv14MAMR3oN0whK1DOS2gXZcqWdVYF/5dTC6lzZY0figcqD4k3tjP4eJqiXlnmHsw83/a43Rhdn/mDbaqUw==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Q0fFUJV0hI4qYRt++Ty5wxvmQYvklt6meFCKzccBxo=; b=VVlOZGc88pm2skvqsZOujGm74RX/t+4YMlqSmN1rJgP4I2j86ANuYxLPA300Cv+aruaHDsvxtUU8SMm/3AKbvMY4up99V/FZfvYHvu5jGkuyXawQUZu08z9wMt3stW8zurSDuxn5JGf4Qf+ufe9ul4yl0n0qRCVQGUiR0HHbmjw=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB2918.namprd05.prod.outlook.com (2603:10b6:903:c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.15; Tue, 17 Aug 2021 18:04:48 +0000
Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::e523:ce3f:813f:dd10]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::e523:ce3f:813f:dd10%7]) with mapi id 15.20.4436.018; Tue, 17 Aug 2021 18:04:48 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Peter Psenak <ppsenak@cisco.com>, Robert Raszuk <robert@raszuk.net>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
CC: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Generic metric: application-specific vs application-independent
Thread-Index: AdeD3NKi79kSDJZ6TDOhKM2waM8fYQAALscAAAIGSsAAAZl1AAAAgkigAEQivgAABe7LgAAC0TJQAAfz9wAAAPh+gAAAuLCAAAZ6zLAABgj0gAOF6IXA
Date: Tue, 17 Aug 2021 18:04:47 +0000
Message-ID: <CY4PR05MB35766F808A73D80706354F1DD5FE9@CY4PR05MB3576.namprd05.prod.outlook.com>
References: <DM5PR05MB3577D1C0D75965EAD00A9247D5EA9@DM5PR05MB3577.namprd05.prod.outlook.com> <4569B3FA-ED65-485A-9273-B5D2A46F6690@tony.li> <BY5PR11MB4337337B882CC1A1D37A0E3BC1EA9@BY5PR11MB4337.namprd11.prod.outlook.com> <3D1EF451-7F15-488E-A889-A82283EFBD53@tony.li> <BY5PR11MB4337807459E356E3BA0A2A08C1EA9@BY5PR11MB4337.namprd11.prod.outlook.com> <DM5PR05MB357703B5F3DED46EA3FE271FD5EC9@DM5PR05MB3577.namprd05.prod.outlook.com> <6ca49c02-3dd2-bbc1-8072-89a57bcbba9b@cisco.com> <AM0PR07MB63865717B6B4A8263B689E61E0EC9@AM0PR07MB6386.eurprd07.prod.outlook.com> <CAOj+MMHRWn4OeuyZgJxbvUH2Qt7rR+gdP=pYCBU4a3Gn5sf=vw@mail.gmail.com> <BN6PR05MB3569F243ABF1F5A472EB03C1D5EC9@BN6PR05MB3569.namprd05.prod.outlook.com> <7fe0f30f-a435-f13e-0fc4-fc061d214393@cisco.com> <BN6PR05MB35696FCD5148902702661D39D5EC9@BN6PR05MB3569.namprd05.prod.outlook.com> <c6b97407-4e70-a7a1-9f79-bd5159d38ebc@cisco.com>
In-Reply-To: <c6b97407-4e70-a7a1-9f79-bd5159d38ebc@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.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-08-17T18:04:45Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=32c438c8-91da-41e9-b547-368e80550d28; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9b85e6ca-fbb6-42ca-3a15-08d961a98057
x-ms-traffictypediagnostic: CY4PR05MB2918:
x-microsoft-antispam-prvs: <CY4PR05MB29186BE5BC4D072B5188E39BD5FE9@CY4PR05MB2918.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4JR+xAmBnj4jsgiVXLfcd/TckYWcE153dAHTWmlSwjBIVM81z0MndAUUXLWg6WrwnwwwRqs2Ie+8uDpZR5VCwMKWf9gp1NztAKQECDyIxMCgyUCeBFCvhmtziXYBcdfC/t1ZsMPwirZZvyilCwROVuNbfpL+Bfi52DCSiaFAbW3US5iGQUrZNq7HPJohv+/YgwgJ8d7UyGcE8WFg4eqhBy6HSYpcdk7g0oTM3aTLY9MF6TOLkl+FkXOHGZtoF04AI7S4tfuxU29J2ToIT2LyTUGYzFq5IXckkC5YPvK2Isxx/EMFVPWRTA88WziqLkn1BXo1DmcKNv1dWSS60kAGYw8bEmRnTB9RMFiZwree0kdvnCJeTfOBC8TGBMCrg8/Dp3AWD3pqF1SEtjvLviyezbRjlxFCjLl32voBRxOaLO6/Nx0fnOu6LoDvx+K9S6y44sjwcjOXPWCqIuhsD8PAbbBagyxVGT58mSyZRbPeAp9pIOkZZjhbOBA8vGMtLHYwgUHd6yaIqZCGc8VzK8h3GevbhKJGR5rrL7K3YPlb/DUJb2ld4iaY9DwNBYwtdrqCOdqamDsSUttrpChc/0sEYMxlKU/e4dFncBjqWfH46nmWgCJaZf0aBQAFTa1zo7Yzw0eHo08XrHDjHepTzJWZqyN6zR0zgmfRmHh9ifMgMn1jw9ns5S/b2lYLkH+UFha6oz8ry/sfeodtAva50x1nZwlIY/mYMO5sSSpqa5yYFT3QEzRce4g10nwyjCX4UHEmrCcDizSGuAqLx32lsUt67g775DVzvAaD9LddkBhl4g/gG7GI4zPTSBR33SLnGDsPTe2vV9wtw0dh6IQN7ktmCAVdLa8nbDDI4HQGGTiNHN0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(39860400002)(396003)(346002)(186003)(66476007)(64756008)(38070700005)(8936002)(66946007)(66446008)(2906002)(76116006)(53546011)(6506007)(26005)(66556008)(8676002)(7696005)(86362001)(9686003)(52536014)(66574015)(55016002)(966005)(4326008)(110136005)(54906003)(33656002)(71200400001)(38100700002)(5660300002)(122000001)(83380400001)(316002)(478600001)(41533002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: u5pOnIN7r9i48p3tt5ENHs1LdicCZ2L7ahTIWZU5iiOZEir32p8RxbAN3SdMhJ7EzrfNWIe1y6vtofeDyiaMTQucHPWJdRwz1DSw5n6BZ5A7fcCzNEYPNeRUDtmQLAsDFP3tNGwpTZ5otjanNtqDQO/seE50+bRErASIRk8/YydsiX42bxQZzpRhtYFMkc6y7Y1OvEBLJ9LhjM9jpBFqmpv9jAcvQOttF2L1JHtZP+0vSIPP88wt9Ksj7wbBKYFhYpRa6jT7KDMAB1CDlTUe2yq4o5QWpQFNnndFJzPlX5ErGXtEmCy8KQfXyf90bc/u97aGb2cww/UomMmKyd97GVTFP5pjEAnPCdTatV1F2Swl8XbWU2HO4yOIcgERFFI25VUC/csTUn9eH5OFrmXaGxVHJf/F2L5Wfh8tFsArqUicgBLtB3H3Kgyj26UT+s7KJcZ4p9X2TsF+DPVOlxlg2dLQr9S5PH6z+X8rVbQCWBFngI/vLjBQxTuRwfaBgkdpQQnEi7kqLnOxoDGMHlGKzVGF7Qql714nGyLMg8PqW8S7fVpR2fe800QrIW3HP3tpt/q5wNB4KJsAxZCwjAFJHkb2IQroxZM7kZE6Qvqb5Gsiyw2xoJFKUZaixZM7U6dGluWvEIOYsHGNbnGqay4rQTCYS09gR92/6S0kY8pqMVEIFEA5xDmRSwnVXuSYaSkquhdtwCOZU8d4omPWBdaziFcgZ21w+0VOQOa1vCAO2aPoUVveJNDBMPvB+SFAr+hzzHAHbRPvcEIsQrCy9JPy08Ke4qaAgHxNLduX9rI7eNLdf5iSqDzoVPfbRS3lkz3i8chwJVn2tTr5ZSxbWI85TuVHm098NoONIA/suIqa5Nxej1qpAgiR+77G6kOsKAtGGpRIyhsWfrytQtkSkoVLyLixZ3xRlclbVJrL5oA4zWf8oxFd8hP7qjkzxjsnyC2xdjmzfORRUBKM0AWPtcTayLly1zBh4G/gtGg6kG6w8grPSowGvxU7pDf9hXpSeswbDpAXNgZjTz85bt1U9yhM3C0+nEG2QPmWGmDKnRHWLOz8xaFaEBpstTY2HXd4KXjcxEP1nX659bCZErP2YOvIYP6pa3Qxr58zZ6BpbZIMDsdZHA3x2X+AackjL8w53YNLLAJSG8kGxevRcUxikFx9FNBE6y7F5lK/wjFdpzgNA23BfS2XS1nta4bk+qZ3YhB8Qjbyp60Zowv+nMM9Y5cUrmIAnOiAcLiTIf3uoeYjLPLXenpgDUDPopwyxezqyC8NlKDYa9jsf6UkSjPPWUbUP7/yvIcT6eDrNCKdJvRxe4ySxkAjQh73+Lx3mNCWm+Iq
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b85e6ca-fbb6-42ca-3a15-08d961a98057
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2021 18:04:47.9323 (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: 3tDB7UTOZhko9K3t22WvhjrXug6Vw349Z5XdZ+iQZ5xMqH4Ja7vIEFddX7wYRFi32WxJW0V3QpNfFg74+O/J2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2918
X-Proofpoint-GUID: fAdDrOKHMvu4o8oh5DZ3w0orJioH4_NQ
X-Proofpoint-ORIG-GUID: fAdDrOKHMvu4o8oh5DZ3w0orJioH4_NQ
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-17_06:2021-08-17, 2021-08-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 impostorscore=0 malwarescore=0 spamscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108170112
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/HhDi62mY0qYeg6tZUWPH7yECAiE>
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent
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: Tue, 17 Aug 2021 18:05:00 -0000

Peter,

>no, I don't want to use affinities to do that. That's the whole point.
>ASLA gives you per link per application signaling. No need to use affinities.

The usecase you are describing to exclude links from an application topology is very straight 
forward and how this is done is defined by applications.
TE applications have defined a topology filter data model that uses 
link-affinities to Include/exclude links from topology 
 https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00. 
 In your example if application B is any TE application it would be natural to use link-affinities.

If application B is LFA, RFC 7916 defines link-coloring and include exclude policies to be used (Refer sec 6.2.3).
so it cannot use application bits on metric to exclude links.

If we assume application A and B are both Flex-algos, ASLA  
natively doesn't support Per flex-algo attribute advertisement 
and it is extremely complex to define user-defined bit masks for Each 
flex-algo and assign the bit masks on the metric on every router. 
Operator could use link-affinities to Exclude links 
from flex-algo topology which is much simpler.

Rgds
Shraddha


Juniper Business Use Only

-----Original Message-----
From: Peter Psenak <ppsenak@cisco.com> 
Sent: Saturday, July 31, 2021 1:07 AM
To: Shraddha Hegde <shraddha@juniper.net>; Robert Raszuk <robert@raszuk.net>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Tony Li <tony.li@tony.li>; lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

[External Email. Be cautious of content]


Shraddha,

On 30/07/2021 18:45, Shraddha Hegde wrote:
> Peter,
>
>> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X >because you want application A to use it.
>
>> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X >(because you do not want application B to include the link X in its topology). How do you do that without ASLA? The >answer is you can't.
>
> This is very straight forward to do without ASLA.
>   I would define an admin-group and assign that admin group on link X and
>   exclude that admin-group from Application B.
>   This is much common way how
>   operators exclude links from the topology.

no, I don't want to use affinities to do that. That's the whole point.
ASLA gives you per link per application signaling. No need to use affinities.

>
>   The alternative being proposed with ASLA is much more fragile.
>   An operator would have to set the bits for application A and Application B
>   for metric M on every link that he wants to include and reset the
>   application bit B on links that he wants to exclude for application B.

sorry, but setting affinities is not any easier, so the above argument is not valid.


Peter



>   Imagine what would happen if he missed setting the bit or resetting
>   the bit on some of the links and how difficult it would be to debug.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Peter Psenak <ppsenak@cisco.com>
> Sent: Friday, July 30, 2021 7:09 PM
> To: Shraddha Hegde <shraddha@juniper.net>; Robert Raszuk 
> <robert@raszuk.net>; Van De Velde, Gunter (Nokia - BE/Antwerp) 
> <gunter.van_de_velde@nokia.com>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Tony Li 
> <tony.li@tony.li>; lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> [External Email. Be cautious of content]
>
>
> Shraddha,
>
>
> On 30/07/2021 15:22, Shraddha Hegde wrote:
>> Robert,
>>
>>   > Can anyone explain how do I map generic metric to selected 
>> network applications I am to run in the network ?
>>
>> Which application uses which metric type is defined by the application.
>
> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X because you want application A to use it.
>
> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X (because you do not want application B to include the link X in its topology). How do you do that without ASLA? The answer is you can't.
>
> thanks,
> Peter
>
>>
>> For example in flex-algo FAD defines which metric-type its going to use.
>>
>> In SR-TE, the constraint list specifies which metric-type it is going 
>> to use.
>>
>> Rgds
>>
>> Shraddha
>>
>> Juniper Business Use Only
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Friday, July 30, 2021 6:20 PM
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> <gunter.van_de_velde@nokia.com>
>> *Cc:* Peter Psenak <ppsenak@cisco.com>; Shraddha Hegde 
>> <shraddha@juniper.net>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 
>> Tony Li <tony.li@tony.li>; lsr@ietf.org
>> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
>> application-independent
>>
>> *[External Email. Be cautious of content]*
>>
>> Hey Gunter,
>>
>>   > It doesn’t make sense to have Application specific values if a 
>> particular metric is obtained only dynamically,
>>
>> It sure does.
>>
>> Please notice what ASLA RFCs say up front in the abstract. ASLA is 
>> useful for:
>>
>> A) application- specific values for a given attribute
>>
>> AND
>>
>> B) indication of which applications are using the advertised value 
>> for a given link.
>>
>> It does not matter if the value is same or different ... what matters 
>> is automated and consistent indication which of my applications given 
>> new metric applies to.
>>
>> I already mentioned this to Ron here:
>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr
>> / 
>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!VVLJCpIMrWixS17PeaBbfOpe
>> b NPO4JUW4jparIn36jHmhv4_-W2_q_Smwo7oIYgk$
>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr
>> /
>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck
>> 7 J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>
>>
>> Can anyone explain how do I map generic metric to selected network 
>> applications I am to run in the network ?
>>
>> Thx,
>> Robert.
>>
>> On Fri, Jul 30, 2021 at 11:05 AM Van De Velde, Gunter (Nokia -
>> BE/Antwerp) <gunter.van_de_velde@nokia.com 
>> <mailto:gunter.van_de_velde@nokia.com>> wrote:
>>
>>      A little late in the discussion... (PTO events do happen)
>>
>>      a quick opinion on the below discussion on whether Generic metric
>>      sub-tlv should be encoded on a ASLA or not.
>>      For me, it depends on how the metric for the corresponding
>>      metric-type is obtained and if it can be configured (static).
>>      It doesn’t make sense to have Application specific values if a
>>      particular metric is obtained only dynamically, for eg, dynamically
>>      measured delay is going to be same for all applications.
>>      On the contrary, te-metric can be configured, and we can in
>>      principle configure different values for different applications.
>>
>>      My opinion is that if any of the metric-types in the Generic metric
>>      sub-tlv can be configured, it should be inside the ASLA.
>>
>>      G/
>>
>
>