Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Tony Li <tony.li@tony.li> Mon, 24 May 2021 18:45 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 7BA803A3236; Mon, 24 May 2021 11:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 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.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 O9ZiOeUpj4BK; Mon, 24 May 2021 11:45:01 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 0D30F3A3237; Mon, 24 May 2021 11:45:00 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id g18so19900990pfr.2; Mon, 24 May 2021 11:45:00 -0700 (PDT)
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=nQPQV1U1eonbJe+bMJ2OoGnch7ew+Crk1Fl8WVVYu0o=; b=Gv14GymNVAWce/MWLtRXkGMb8Eg3S/3SZd65565P6kFjbY0kvFGZvbA2moUikSdSc+ eMfF0ma8+3nPueBzqKnjHolte3lX2yxLKXP3HXWLKIUzxfPIMivXshV5TsGXKlU363hr +EI7Hh3EVHlGzeh+SMzh949crr3CjSBu95ki3Heb+UkTaalMJLHx7oCcFCiXmJ1mM3dy LinyBbvJ42ckn6HeGMuQW9Sx/WexZhpZdZrmyhmED7+wMyfmgBf1d4q1yDMxe3hMgIve SlaNDctJQq67U8v4QBJmhBaCKCw/tU8ZkCTT5nvpJTJW3spSKypKX29ZzWqFESdh2Dol D9/Q==
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=nQPQV1U1eonbJe+bMJ2OoGnch7ew+Crk1Fl8WVVYu0o=; b=MvRdTKIiAWtVfUhLuLlQJxt953psXR7R90BeakBVXT5UXIu6mnRCO2/cAGy0p3CN4Q b6g7tkkpCDCrR+G0WXJuPkPfCLs3AXmEjyVMT/BB0PbIvoNyLEJ2wd5rzmGmg0xkCQL+ U0j8NTng4TXf6kfqLRda19JVuqmd8tTtpXJlPkuePs46GLRPMeEZTTT9CmSTCVGKd3gV yUqfGjO5dy1p9Zd7xMYaRyA5+0yqAn9zRAxV+ageMSsYR+1zzCs9zOd8CKUpswqrLqmK N4tUhC8pT1NmDyPWZicMuLpcOSoXknbWJgUa/z+VJrlWSb6/YuJb4iavFSkTAiCUoTi5 kR9g==
X-Gm-Message-State: AOAM531wboZ4sfMpdLpTooU8lvD0wWMiJO8XZ/e0P0SYEYkNvxLlbVvn rGxj5AH2En3vUcHjx/EHmbI=
X-Google-Smtp-Source: ABdhPJzoFeHhzaCKeuyh2O5MoUvhJFfSFfq8K1LZKkcddM9bCzxmRl+j+zQ7t9JgbhVMUhKw+Fk59w==
X-Received: by 2002:a62:1e42:0:b029:2df:dd12:1608 with SMTP id e63-20020a621e420000b02902dfdd121608mr26053854pfe.11.1621881899524; Mon, 24 May 2021 11:44:59 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id e34sm161308pjk.31.2021.05.24.11.44.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 May 2021 11:44:59 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_33B904A4-06CB-40A6-A798-0240DE90FE84"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 24 May 2021 11:44:57 -0700
In-Reply-To: <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>
To: Ketan Jivan Talaulikar <ketant@cisco.com>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/77G_J96eOCt0zpGhIdarLu612L8>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
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, 24 May 2021 18:45:06 -0000

Hi Ketan,

> In general, I support the adoption of this document. There is, however, one specific point which is not clear to me (8) below that I would appreciate some clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough consensus on the content, just on rough consensus on the interest.



> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864.


Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it’s just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.

> Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3>

Fair


> Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic – we will need precedence rules and such. I prefer we avoid this complication.


We preferred avoiding ASLA.


> For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.
> Exclude Higher Bandwidth Links
> Exclude Lower Bandwidth Links
> Include-Only Higher Bandwidth Links
> Include-Only Lower Bandwidth Links
> Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of “exclude” for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?


Thank you for the suggestions.


> For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7 <https://datatracker.ietf.org/doc/html/rfc8920#section-7>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1 <https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1>?


I’m sorry, I don’t understand this comment.


> Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.


Nor this one.


> The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.
> 

I’m sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.

When there are multiple links with the same bandwidth, and thus the same metric, then the total path metric becomes (link metric) * (number of links).

Regards,
Tony