Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

William Britto A J <bwilliam@juniper.net> Mon, 01 March 2021 10:16 UTC

Return-Path: <bwilliam@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 AA3353A194E for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 02:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.154
X-Spam-Level:
X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=QkGI7RoV; dkim=pass (1024-bit key) header.d=juniper.net header.b=cNkSA9x+
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 eVvwYJKHqXLO for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 02:16:13 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7D4C23A194C for <lsr@ietf.org>; Mon, 1 Mar 2021 02:16:13 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 121AFWVH025974; Mon, 1 Mar 2021 02:16:13 -0800
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=PR+e7DJrda0TeyCh3+zp4h8WiqO3Wt0gA4nKSa4T2Ss=; b=QkGI7RoVgpXu8Zv5jcGYCpcFk7aYTPHpclzaC3YUb/vES4WK/cXO5wWTLBtKTOQgzQ34 BFiH3+uo5RyRg3P0ApaAUmqerCyn6ytCJn67N8p43KNWjk0zILXY3SWVi6KJIFU74QfD Pv6OMCsy0pYGVxITNnC63SMvuv2PiZFMkPrgi5qSP51fT0IPjNpwwrpgaJ7PyDMwxIL9 VeJcKuMGPEjHHKHmXv1Lx+h9L1S8zuNSpyn0M1RLnauSyFBiPjhCZVVGZx5uR76XQYTU mHJqb3yEbUjaaiKz/CUa3CUdFNnRRsevwhlCvwID0io9Va8Ig+V96T/UjcSr6Azn7tzL Nw==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by mx0a-00273201.pphosted.com with ESMTP id 36ynytjkju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Mar 2021 02:16:13 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kndc5cSclGyAZ6vmb0adS3ilEwSwCzwD9t6IeTkDn7QZCXz9aynKlf8XpwmkHlzDT9RtTwA+mI4AeKNvLIIoNnf4J1rQDDKvFnxY4M0rGjlhl6z/zebO3MeZT83iaISMp94TVFLeeGmr+OTdUDEcNl+HPORIWz6LZVG9gY/micPzptTdBaxLhfO/FvD21ZWUVTBBzS4HzMy/NBGtpEimxZXTTuQmR2OniYGnYFxegx3Wq0nmdMVZmE8HxNq2VOwQ6WrD+n1EcYDW2GcuNiMu0RwT+AE74wC874uExUpZWFAAJBBFO7Lz98j4gvJfTfC5HwdEhD95kDVxEIPGJhwnaA==
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=PR+e7DJrda0TeyCh3+zp4h8WiqO3Wt0gA4nKSa4T2Ss=; b=OhWAmd6PbIMTHPSaejjVuJ/RRxO0YmU3k/uSyuUl6OUWXAZIbLxzJx7Rw3oD5BZWfugCl3/pguqRjpY+UYDiFJK3zQSCgKhlnHvhxcC40sN6EAkbk5jIe2R3NwXURe78SPUI3lC2kAkjC7NLKmpmZnEBbeDmHQdHOc8BvNkKuvHOk8rWEpQhTUd98SXwcyq7+FqpFhTJW/9IUTXrQhHjATX247rVoQ++5PFOwAThARL8i5jynbr3qIJRbiGY4+XgYy1niEQvwgvu4heaTLlWDGg21QRx6PR5P2moh7gZtFlt66o3V7p3jxF/8O5foik49lzMR5MSFIcoSUY4TUy8GQ==
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=PR+e7DJrda0TeyCh3+zp4h8WiqO3Wt0gA4nKSa4T2Ss=; b=cNkSA9x+bGENrVbc77Aol2Ngm1dmUCdrrvrRwQ+E70wtqfMn50iX0iOBrAdcOrSGV2EWR+/dx+4W+VARXihz34eYdVRQ+YPquRRJytqNcP8ljZTPSFD29gtjO01nvtaMV47tyDjV/JUmxFFeccS5Vc2meakgWfcLDW+5er/rzSM=
Received: from DM5PR0501MB3800.namprd05.prod.outlook.com (2603:10b6:4:7b::10) by DM6PR05MB5900.namprd05.prod.outlook.com (2603:10b6:5:108::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Mon, 1 Mar 2021 10:16:09 +0000
Received: from DM5PR0501MB3800.namprd05.prod.outlook.com ([fe80::537:9ad7:1e60:65a3]) by DM5PR0501MB3800.namprd05.prod.outlook.com ([fe80::537:9ad7:1e60:65a3%5]) with mapi id 15.20.3912.009; Mon, 1 Mar 2021 10:16:09 +0000
From: William Britto A J <bwilliam@juniper.net>
To: Robert Raszuk <robert@raszuk.net>
CC: "lsr@ietf.org" <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>
Thread-Topic: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Thread-Index: AQHXDBIWT9mc4YXF3E+r+hn24uWzgqpr7s2AgAL3zMY=
Date: Mon, 01 Mar 2021 10:16:09 +0000
Message-ID: <DM5PR0501MB38008ADCECE28C2695C67CA5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com>, <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com>
In-Reply-To: <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
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_SetDate=2021-03-01T09:43:43.9136697Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Privileged
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 25518fe8-5f3a-4fad-6b78-08d8dc9b08ad
x-ms-traffictypediagnostic: DM6PR05MB5900:
x-ms-exchange-minimumurldomainage: ietf.org#9487
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR05MB5900D4BE1FA7FFD6686A360ACD9A9@DM6PR05MB5900.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dr7mI1pF3YwdrCeCiFZQrCg6SrQrAfRZAJNm30W/ZUobeUieOH1lf+5IntAkAbVAsidgSP9R7zLIvUqhzSQJOoEnSYwuEgP844sM1YCM2BFqN/Nx7atrI5YWFlRANixIF7AzNmjtdeeEwD3pFeg/FV2vG5NlYKOMvQKGfPc8lUorkA1jSAfaxbhgOpUwyw+3R0XAldGNxzucfqKx3nEGTSSgZCjwGJkEfKZ2Lhj6dEqNxoeo+jaer21Z5FUlO1M/IfLRgzksgsJ8DBaFO9BuXuc6LINP3U6vATpZUqTRbiYRJGyewFdEnYCbwdTuTKtecfiaYSf3nzbj4m4GcZh2djXbiZOd9SCFKRgvwlc3WKIfxgX0N+Axa9aiFBb55homtkF+h0MBaz4lVolOMWYCBlI0TA6DbKvLDQVwtUhGRtnKL85xij44ouflG/6Yy4yTEqRtCw+xg18SjkL+zheH0Wzk/9CAUxw9gkGeWPac4g/+FrYVxBL3+WKrm29rJ+4qFtyAPddmGzi5u45bbizQik2/V0dX5wJjGfCVf58xtblGx0P1g4Hi2SsubrFpwAqwPehb+sqKTB3o66Uc9DySkoIaTCfbvV/39u/Di5oMHIA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0501MB3800.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(396003)(346002)(366004)(39860400002)(76116006)(478600001)(4326008)(9686003)(54906003)(53546011)(2906002)(8676002)(86362001)(6506007)(91956017)(5660300002)(316002)(55016002)(9326002)(83380400001)(8936002)(26005)(966005)(66476007)(64756008)(6916009)(71200400001)(186003)(166002)(66446008)(7696005)(66946007)(66574015)(52536014)(33656002)(66556008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: L9MtEdFzxEoWYojPOPTTSRn338DCOzBRhNSU+j1H3OWk8/+0q+sSXcZnRdUVUln9EjW/zQRk/qCQaqWPvHWTOti/Up5mH9TD73SzXSF6qXNdwBT0bqiHI4I7fSiWRUg5vbfBqyAwI9njvDdSyvfFKM1CXlUIZW2vGwtuLYPR4t4Ffo3PLwJp6M5JSMSB++MZLzqb1T+z8vGHhVyksP/jPHJ2pWjorDHg+6kD4CVD89Qq7j/cdKPg+2h7fXlnCIdLjlkdV3W0MMs0xwkYHU4t1DuI9UB1tz+SI2VWPXnqXyC7QL2W9kjDJvKEMbOR6aFtpa8dX9945jM90whRDRARhlqUgFVcRlD4gjpPumMz0gHNCQfs2yx+7JNvLsofL8CVrn0u94R57TwigfToA1BI9/PBJF44OmoYtidyh6rTPj+ZeU8l6MTmYrTEA6OwFy1HAkS/bEUVfXYes7/4wZyLMf8dCvdhKs7iCKfveBYTcIsv82DbrAiRVT1yc53A32csT1z8rgFpMyKQ+k9FSwsZhFfSgzvyur1YPl6maMbR8jasrwWzoS2WnnzN4FXoaJbpXK6cwWDvWcNCztHA+9L23hRg1/MIVxN6E6ThM1PqmeXzSRJScHT5uc4b7/aP+PBz3u0RjzWjzPHKzpDnSrJSF5IYYnwT7mp3DbCRjZ53ezFQ5IVP23U/cCLMi7fPDvWqbzIrSYm2k3JmrAJHmWcJo9B/XcDorGe5zBZwmL1+IfGxDBGYTjfxlz/MCy2xfNGJVn66UChOBrj7m56IYI1TcQMLoGZDihtEglTapAhN+O3C9R9jPDCJVJV7CI7jdLYVPqflpESOrMHV6e99F5S6JP4vmYJM4V5WhNnCkdzLBkXy7DGcAtHjmncqUz/OgWr5NOAwXLGOtnpGDNguNN+A2Nq3inqFdv11xwtCLwhnKnduEsQPt9iVw9hfBkOqyfZ2/SMEdAAdeTFQ9ZYPJPKkhngYrU8TztG3meAJ1chmNg793v8szCYCaWhQLTwRb3QHatVs/+keZUbnddotsw11RA1fsPagpVV0Eg7SIhn3EEhboBtsDnjjTZxC/HpvTB4CNs447OWxKnjPQtw8I4eKh5SjLK8YVDQy/WV59flh3C9ijGL4MdLYVU44wcwtcFz4Wvj0oO7HHLMHe0JiRnbDJwU020Z4nN6Sn9AxkL5EWo1eZR2hNUbPS75XoeEQ8m53oj8bIQhUrrOgriSsuzE1HZy+DTMK26xGhKbKbpQjvVzWVYQ+lHsBgEizQjpJRIjGAp6iP+SPtfOFmuAoYhQDjWaI2M0CUTOfPjccUVHibT5OBoD0cEHlVlZIuqQE0xjUKU3Gsw6/21RS2UK9nb2YAw==
Content-Type: multipart/alternative; boundary="_000_DM5PR0501MB38008ADCECE28C2695C67CA5CD9A9DM5PR0501MB3800_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR0501MB3800.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25518fe8-5f3a-4fad-6b78-08d8dc9b08ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2021 10:16:09.5440 (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: aRh26o0wtW4EJ8PL2gPptnWghVOkawHVvaFOoZnCo5zQvyKoYEpP9C/562GoTrARNVSpbVxApQ9nDEFZolYAcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5900
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-01_05:2021-02-26, 2021-03-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 clxscore=1011 bulkscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103010085
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xofSj0Whw2jvGtMd2FE4RO5p47g>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
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, 01 Mar 2021 10:16:16 -0000

Hi Robert,

Thanks for your comments.

Currently there are customers who deploy separate networks, of which one could be assigned metrics relative to the interface bandwidths, while other could be based on other parameters like latency, etc. Flex-Algo which facilitates different metric-types for SPF, is a very useful feature for such network consolidation use-cases. We are trying introduce the protocol constructs to simplify the use of metric based on bandwidth via Flex-Algo.

Any existing tools and techniques used by operators who configure metric relative to link bandwidth to optimize the network can be used with these Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here can be used to automatically derive a metric based on reference bw vs link bw; and if required, this can be overridden using the individual link bandwidth-metric sub-TLV. We will make this clear in the next version.

RFC 8570 support advertising link delay parameters in ISIS. Protocols like TWAMP support dynamically measuring the delay. Whether egress queueing delay is included in the link delay depends on the measuring mechanism. The Exclude Max Delay sub-TLV introduced in this draft is only meant for pruning out high latency links from a Flex-Algo, and it is upto the operator to define the maximum bounds based on the measuring mechanisms deployed in his network.

Thanks,
William

From: Robert Raszuk <robert@raszuk.net>
Date: Saturday, 27 February 2021 at 5:54 PM
To: William Britto A J <bwilliam@juniper.net>
Cc: lsr@ietf.org <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
[External Email. Be cautious of content]

Hi William & co-authors,

I read the draft and have two basic questions.

1.
Both bw & delay can be used as defined in the draft to construct new forwarding topologies. But how practical such topologies would be in the real life when 40GB links may be heavily occupied with bursty traffic and 10G links can sit idle ? I suppose you are trying to address the case where say 12 gbps holographic stream needs to be sent across a network.. But then I don't think if sending it in a single flow instead of spreading into many sub-flows and use as much as possible ecmp would not be a better option.

2.
Likewise how good is my accumulated link delay value if in between there are deep buffer network elements and say egress queuing to each link (which max is unaccounted for in your draft) can significantly alter the end to end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link basis (still as static value).  So if some traffic is delay sensitive we will have a much better accuracy not to get into a trap of queuing related delays.

Thx a lot,
Robert.


On Fri, Feb 26, 2021 at 8:37 AM William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
All,

We would like to draw your attention to a new ID: https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV2Tba5Qg$>

The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric.

Please review. Any questions and comments are welcome.

Thanks,
William


From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Monday, 22 February 2021 at 10:56 PM
To: Bruno Decraene <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>, Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>, Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>, Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>, William Britto A J <bwilliam@juniper.net<mailto:bwilliam@juniper.net>>, William Britto A J <bwilliam@juniper.net<mailto:bwilliam@juniper.net>>
Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt
[External Email. Be cautious of content]


A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
has been successfully submitted by Shraddha Hegde and posted to the
IETF repository.

Name:           draft-hegde-lsr-flex-algo-bw-con
Revision:       00
Title:          Flexible Algorithms Bandwidth Constraints
Document date:  2021-02-22
Group:          Individual Submission
Pages:          21
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$>
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$>
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$>
Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$>


Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a set of
   bandwidth related constraints to be used in Flexible Algorithms.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKXnuJRcew$>.

The IETF Secretariat


Juniper Business Use Only
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV0XHjSNQ$>


Juniper Business Use Only