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

Tony Li <> Wed, 26 May 2021 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29CF83A0A5E; Wed, 26 May 2021 09:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJB5PdzelGdd; Wed, 26 May 2021 09:40:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A83393A0A79; Wed, 26 May 2021 09:40:11 -0700 (PDT)
Received: by with SMTP id l70so1430713pga.1; Wed, 26 May 2021 09:40:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5+/ZKA6PuIx4xh5g4lOT/j3VETiyAJ3MWhKz5EvDOCU=; b=u10KHSDyY6AGTwwfh+ZofoLy8RzvD+5PeekyJ92U00oGgnEnxTh0jELdisbo45KDlu dCHEqb0tQouF1CgmChyu8lFeySZl9rxBRD5kVqh/Mp2tAWe2fCTBvxrASocPlGjPFVZV h9KeWCpIMtKmo0t5uVLAvTa9ghzHcgxUq+PL3IpQtR2a8QyvFaTj8ihuYUWiqoUdEXPd 2vgl6FhBc7Y5BZvPeLg31NH6oa9/k5RW+GaHH7Acv2PxvUoBg4tzHow6YHqOp3RRA4fL zywQvjthkiBWckulKho2U/k3yHx60JNdGxftSYAAQOV2ZlLm7lTeY7rP1nrgicD/vuQv /LHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5+/ZKA6PuIx4xh5g4lOT/j3VETiyAJ3MWhKz5EvDOCU=; b=RWZW5pwhtwrjqWASA6Qkw0E6jUQIHcRnpZ9fFpNUH36ZCSw68SZKU1YYIJzMjkdRwI R5xWoAnmj2L5z562iCUw2fh9TJ742+oHZZbcmV08iYp+R6WXbnEcZWVDPioqUgfx/3W7 dSm3wpV2e1lqynJevmLXShEGvofGbqzLQOo3AUEfvn5HQSiRqTMoFDbi+glql/7YHeSj Ij5Uy3l9W4xYGNtbyO8aymTNLJHa1JydR7WjyU+DMsbm3vO5cQGA/WdYS5cQ80WxbeDV ZFShxQtSpWOi7lXE0eKESBVLjiyNq1gdl2UmNt3HH2lyUXNRK5ZI5A8o5JlJvjv93lJu f0lw==
X-Gm-Message-State: AOAM5315iOE25wgDMOJsRoXMd9AF+Zgcuy/slN5ZvxzVdBa5T62LnMuw GJ4yfwHniGSxBi7MA+rJUCc=
X-Google-Smtp-Source: ABdhPJzin82dlcUEK2C9+zxzdDQOhtJdB7ctAQGBA/8kto75LQbvkBt+Vq3cZWPrT6vQ2W3Pm3sDkw==
X-Received: by 2002:a63:1d2:: with SMTP id 201mr25859340pgb.3.1622047210278; Wed, 26 May 2021 09:40:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id w74sm16160894pfd.209.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 May 2021 09:40:09 -0700 (PDT)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_998D1549-D6D5-41F6-A6AF-808D9C80779E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 26 May 2021 09:40:07 -0700
In-Reply-To: <>
Cc: "Acee Lindem (acee)" <>, "" <>, "" <>
To: Ketan Jivan Talaulikar <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 May 2021 16:40:22 -0000

Hi Ketan,

> 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.
> [KT] The Generic Metric is by definition something that will get extended in the future and we don’t know what use-cases might arise. It doesn’t seem right to follow in the steps of an administratively assigned metric type like the TE metric. Therefore, I suggest to make it variable.

Thank you for the suggestion. I don’t think anyone has suggested a variable length metric before.  A variable length metric is difficult to implement as if the length exceeds your processors word size, you need to resort to long integer software emulation packages. These are a huge performance penalty.

> [KT] Regarding metric overflow, I think it would be better to leave it to implementations on how to deal with it. A guidance similar to below (from draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does not cause interop issues. Theoretically, it is something that is independent of the size of the metric.
>    During the route computation, it is possible for the Flex-Algorithm
>    specific metric to exceed the maximum value that can be stored in an
>    unsigned 32-bit variable.  In such scenarios, the value MUST be
>    considered to be of value 4,294,967,295 during the computation and
>    advertised as such.

In fact, we are not specifying how implementations deal with it.

> 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 - <>, in case of ISIS also, it is not really appropriate for use within ASLA - <>?
> I’m sorry, I don’t understand this comment.
> [KT] In <>
> The Maximum Link Bandwidth as advertised by the sub-sub-
>    TLV 23 of ASLA [RFC 8920 <>] MUST be compared against the Minimum
>    bandwidth advertised in FAEMB sub-TLV.
> And in the <>
> Maximum link bandwidth is an application-independent attribute of the
>    link that is defined in [RFC3630 <>].  Because it is an application-
>    independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
> Somewhat similar for ISIS as well.

I’m sorry, I’m still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.

> Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.
> Nor this one.
> [KT] Generic Metric is used for the links. When we get to the computation of inter-area or external routes, we will need to get into FAPM. The draft at a minimum should discuss the applicability of the Generic Metric and its use as FAPM. Now, if we do make the Generic Metric size variable (as suggested above), then we will likely need a new TLV for a variable size FAPM equivalent?

We would need a new TLV regardless of the metric size as the FAPM TLV only carries the default metric. We are not proposing that TLV at this time. That’s future work.