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

Tony Li <tony.li@tony.li> Fri, 05 March 2021 17:28 UTC

Return-Path: <tony1athome@gmail.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 5C9183A28AB for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 09:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.501
X-Spam-Level: ***
X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oOYjcXGloqYn for <lsr@ietfa.amsl.com>; Fri, 5 Mar 2021 09:28:14 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297ED3A28A8 for <lsr@ietf.org>; Fri, 5 Mar 2021 09:28:14 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id 18so2604859pfo.6 for <lsr@ietf.org>; Fri, 05 Mar 2021 09:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UhIQc0OnbxG4UVBypDkju7IYTqlqArit0dgPrPc1L00=; b=ozoM4ttVDHE38QvaBhc/j41TMXOPOuxr+VgC62XhBh6DY0BPRlvOjbFkc74xeLgrzL /daipby2CizQZOUanVSt2YjgIx29N5GGV2DsyP/eMX5rD+pDFtnQnvecJMFVcfl5Zb7K Z2B2oepLZ5KplUooAi3MiorFhVhpsfNdmXom5zEEENcuJEYoCJtBGKOmDObUb5Pjxo+/ 7hkDMMjAmq35rPg6B2nJjJGDQYV4auNspN3vpjlHjhRNxB0HRin/pJWngOhZQRpKUfdr 5Qh2pX6yiq45F4FkjcWvXtlwh908ViCLFh7vf9mJ4PAQQ1TYTVvCPgZOb1ItXbAeAqi6 gnow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UhIQc0OnbxG4UVBypDkju7IYTqlqArit0dgPrPc1L00=; b=LpnXBBZs9Ic5fSeAm+Z/AtE5nmpp0NnejdhGjH15JNdn67t+tljRHwgSdBfVns7rJZ tck9abO5+MwZD3r21bnqPzOHzD0w8lFB1jH73dePmuiqqQaK+CWQtYw9bRwO/42SM2rS cwNz3uMxZjfF1drcspeW7WOj3JzGir4gB3hjO14hJ7LVnG89zDA7su92epcH4Ij4HGO9 RL3iqII6wIJVitDv6zsmoSSYmy6hzTt3/Amx+NzLIa5B7Dk5Vk/s59d8vCFEan1GnqvU Kf1FCX2nMJaPLA4dRZFjF6OHVo21r1MChyyGWzS0YT9V+BxkI4n74Yhfr7kZw9NuYX35 c9yA==
X-Gm-Message-State: AOAM531X6gsiCjNbcbO0zh4SomipgkSkAvGEWCqNMol2RlXrKsg6rCGK Jm/ZBpDZ9I0ylAPPWt4ekR9JlAS/cho=
X-Google-Smtp-Source: ABdhPJxAwHZfRFenGrt7MwQHiQrzs5r64CdHtK+wS7sWY7uO6msO7zB6bPyBmHph+3Uq8mVDCw+t0Q==
X-Received: by 2002:a05:6a00:7c9:b029:1ee:5346:8f04 with SMTP id n9-20020a056a0007c9b02901ee53468f04mr9761892pfu.69.1614965292702; Fri, 05 Mar 2021 09:28:12 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id q23sm3161484pfl.123.2021.03.05.09.28.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Mar 2021 09:28:12 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <9DE9C19F-DAB3-4102-A46A-FE3007041E2B@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0921B88E-B4C8-4D74-8D8E-778F9FA77523"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Fri, 5 Mar 2021 09:28:10 -0800
In-Reply-To: <CY4PR05MB357692CA29F39444D7DD222ED5969@CY4PR05MB3576.namprd05.prod.outlook.com>
Cc: William Britto A J <bwilliam@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>
To: Shraddha Hegde <shraddha@juniper.net>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <AEEC6707-7E76-41FF-9388-EA2AFE9FF5D1@tony.li> <DM5PR0501MB3800B7976376E6167378FFB2CD9C9@DM5PR0501MB3800.namprd05.prod.outlook.com> <23144FD9-0CE9-40DA-94FD-DE5611D24911@tony.li> <CY4PR05MB357692CA29F39444D7DD222ED5969@CY4PR05MB3576.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Cfg5Dea5Yr9mDIs-O6c2nozJ5I8>
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: Fri, 05 Mar 2021 17:28:16 -0000

Hi Shraddha,


> 8) Section 4.2. You write that an implementation "considers cumulative bandwidth of the parallel links while arriving at the metric for the link”. This seems a bit vague.  I think you’re trying to say that in interface group mode the bandwidth of an adjacency is the sum of the bandwidths of the individual links.  Typically today, if we have L3 parallel links they are encoded as separate adjacencies, complete with unique interface addresses.  How does interface group mode work with that? 
> <SH> It continues to work the same way. I mean the topological representation does not change. It is going to be represented as multiple parallel 
> Adjacencies. How the metric is assigned to these links differs in simple mode and interface group mode. In simple mode, single l3 link bandwidth is taken and metric is derived by using either of two modes of metric derivation (reference bw or staircase bandwidth thresholds). In  interface group mode, cumulative bandwidth of parallel links is used derive the metric (again either ref bw or staircase method can be used) and same metric is assigned to all parallel links.


So just to be very clear: we continue to see multiple, parallel adjacencies advertised. Each of them that has a metric that was computed using the sum of the bandwidths on the parallel links.

When one of those links fails, the remainder are then advertised with a revised metric that was computed using the sum of the bandwidths of the remaining links.

If this is correct, it would be good to state this very clearly. If you intend something else… please be equally clear.


> Does each adjacency advertise the same metric based on the total bandwidth of all of the links?  
> <SH> In automatic metric calculation method, each node derives the metric  based on advertised maximum link bandwidth .
> In interface group mode,  metric is derived based on cumulative bandwidth of parallel  links and same metric is assigned for all parallel links.
> In automatic metric calculation method, metric is not advertised.


I don’t understand your last sentence. Section 4 is all automatic metric calculation. Why would you calculate the metric and then not advertise it using the Bandwidth Metric subTLV?


> In cases where operators do not want to use this automatic metric derivation, they can advertise bandwidth metric.
> How this bandwidth  metric is assigned, whether same metric on all parallel links or different metric and actual metric value is all upto the operator.
> When bandwidth metric sub-TLV is advertised on a link, simple mode or interface group mode does not come into play for that link. Bandwidth metric advertisement overrides, automatic metric derivation.


I see that I have misunderstood a big chunk of your intent here. Please add more clarifying text.  How does a node know whether we are using automatic mode or are being explicit in advertising our metrics? Is it on a per-link basis? Do we default to automatic mode if no bandwidth metric is advertised?

Is the metric automatically calculated if no bandwidth metric is advertised?

What does a remote node use as a bandwidth the compute the bandwidth of a link? I would assUme that it’s a Maximum Link Bandidth subTLV of the ASLA subTLV. If so, please be explicit.

If we are to use the bandwidth metric in a FAD, we need to specify that in the FAD.   This implies that we would need a new value (or set of values if we want multiple bandwidth metrics) for the Metric-Type field in the FAD subTLV.  I see that you’ve added a specific request for this in section 7.1, but it deserves mentioning somewhere in the text as well.

Regards,
Tony