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> Wed, 26 May 2021 16:47 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 5B7683A0AD4; Wed, 26 May 2021 09:47:39 -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, 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 yMSctjJ79OgE; Wed, 26 May 2021 09:47:37 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 936BB3A0AC5; Wed, 26 May 2021 09:47:37 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id kr9so1116393pjb.5; Wed, 26 May 2021 09:47:37 -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=Ox8eHNwRKT59tehJ7jFUzuS/9f3UAcoXoC4Chb3gkXQ=; b=cZuwa23ARoIfA/Douj9TF06SHdnhjvsk1jp3XKX8BroBj2lOZfJ6XG3nj7GptblzKL h5SFbwONB1fsyw9sF+r0vXv/5dcaAzwFAb+3lg6lbQBEjDMfJZfWKu4Hx/+lCZXM1Xhb jTWSKy8TGq+2v8LvJuRDN6+DqdgGm2X+e+4JvGi+0S1SHhy/O9P4kIt55NDnKuIaX7WY fTwnkBZfMqEgiw4c9RBM+x7fdlcmRtGL1uRHoK0jS3YBBxGrgPZJZWMp8kit+58ZBcYr ZgNQWiPlpTncjWwTFLSOyGcvY/9XOdAUsSRpR3Bm4+ZD214kQ9XXrJW2LPOLxWsSUQ8t QumQ==
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=Ox8eHNwRKT59tehJ7jFUzuS/9f3UAcoXoC4Chb3gkXQ=; b=LBvdGf2rATIINa/714SV/4PYoifuS0GQWpWMTfCYEvV4u9T0MfqnzXNAjDv53rwyuW 4CK3UBySdkRmgamXQpO7568QG35pd4XM53Qi18+6LecNoAC2rUU+PxRuwHzSLUAOycc9 wexcKujArkcCgsLrw5ih+TesSlDxkRyNGjKmpQ4logHBIYfP91VgqIEmjuky/1qXPebV k3ae3I2ycT4NVyyk1eW1JnB0NnVUxGei/re7yUSdBqNTIK3YLxuN0Tn54HLNvnbOfu9i OgrN2jD5OSWIpA6CQ0acFsmuEroPPfaCIemWzCbyrCFeA7XNUjR34T7p1o+sbhRGIKFc GdXg==
X-Gm-Message-State: AOAM532x8BUMcpqqNoLH70flp9lIau8VHVfH3B2i71vfCfbQT/lTWeEN FoLFvFb90b6gFwx/VnCSqTL3zY1zv6M=
X-Google-Smtp-Source: ABdhPJw2dlmKpq6+AZSao/V8AZgAcEIdwk16JHF/nI4H2O92q4QCEAreNNA4p8zfnY/L0O2NMNBeHg==
X-Received: by 2002:a17:90a:49c5:: with SMTP id l5mr4998416pjm.104.1622047656552; Wed, 26 May 2021 09:47:36 -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 v3sm8804596pfb.203.2021.05.26.09.47.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 May 2021 09:47:36 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <A35DAF3E-9C62-487C-B004-CC8466A0AFF6@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A4287B7A-FC5B-405A-A841-D19F9E4757E0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Wed, 26 May 2021 09:47:34 -0700
In-Reply-To: <000a01d751fe$5620c450$02624cf0$@tsinghua.org.cn>
Cc: lsr <lsr@ietf.org>, Ketan Jivan Talaulikar <ketant@cisco.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, draft-hegde-lsr-flex-algo-bw-con@ietf.org
To: Aijun Wang <wangaijun@tsinghua.org.cn>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com> <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li> <007201d75109$cb3bac00$61b30400$@tsinghua.org.cn> <A804984E-E6A4-4893-AEA7-F0CA5220DAEF@tony.li> <000a01d751fe$5620c450$02624cf0$@tsinghua.org.cn>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Ma8muDKVTc_thYP60-ge6xnfTog>
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: Wed, 26 May 2021 16:47:40 -0000

Hi Aijun,


>> My suggestion is still not introduce such non-cumulative metric to cumulative based SPF calculation process.
>  
> Again, what we’re proposing is cumulative.
>  
> [WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 4.1.1.2) can get unexpected result, that is, if there is no manual intervention, the E2E sub-optimal path will be selected. You have also confirmed this in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/ <https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/>, said as below:
>  
> “Override the metric on B-E-D to be even higher.
>  
> The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is    to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths. Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.”
>  
> The operator must investigate their topology carefully to add necessary manual metric to avoid the unexpected sub-optimal path.  Is it nightmare?
>  


I’m sorry, but I seem to be unable to help you reset your expectations. 

The bandwidth metric is NOT intended to find the absolute highest bandwidth path to the destination regardless of all other considerations. It is simply using link metrics based on bandwidth as a means of skewing paths towards higher bandwidths, but it is still cumulative so that a significantly longer path may still drive traffic away from a higher bandwidth.

If it is any consideration, you should be aware that most implementations already set their default link metrics based on interface bandwidth. This results in EXACTLY this same behavior, with administrators making manual adjustments if necessary.

Regards,
Tony