IETF Logo Mail Archive

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

Peter Psenak <ppsenak@cisco.com> Thu, 27 May 2021 13:50 UTC

Return-Path: <ppsenak@cisco.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 5FE563A0CD8; Thu, 27 May 2021 06:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 h4bp7CS3Fua3; Thu, 27 May 2021 06:50:40 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0913A0CCC; Thu, 27 May 2021 06:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1195; q=dns/txt; s=iport; t=1622123439; x=1623333039; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3fwS+6LVLCBFnpt5jsJNm8L0PY36J4pDFIFhyBP5na4=; b=kprkqAWI3ffG+u/SA5eWfMy5QRWvMRNRga9NSqlCA4JKX//jgYMnAqN4 7KVEgC5IT2YGBztQMtTLoBh0B1yG9l6SMKKhtmxFhD0jDtNmlDDB0VFba sr7jKwLFufQGdSw54LWrziuc+YO6sNJCY0A/TQCYxR7VXMuZE35QPDuFt k=;
X-IronPort-AV: E=Sophos;i="5.82,334,1613433600"; d="scan'208";a="33977690"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2021 13:50:38 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 14RDoasg009731; Thu, 27 May 2021 13:50:37 GMT
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, Tony Li <tony.li@tony.li>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com> <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li> <MW3PR11MB4570BF55DAA30AAB9E25D7EEC1249@MW3PR11MB4570.namprd11.prod.outlook.com> <82697C23-4283-4646-A266-F67828337C5C@tony.li> <CY4PR05MB3576B217AEDF4C58353EEB83D5239@CY4PR05MB3576.namprd05.prod.outlook.com> <SA0PR11MB457603E9055D3AAF37690A57C1239@SA0PR11MB4576.namprd11.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <b3a5ad39-47f5-493b-bc3f-5ae6749a75b6@cisco.com>
Date: Thu, 27 May 2021 15:50:36 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <SA0PR11MB457603E9055D3AAF37690A57C1239@SA0PR11MB4576.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ZqPcb4zr0-mo7f_jfCFYWe0UpH0>
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: Thu, 27 May 2021 13:50:46 -0000

Hi Ketan,

On 27/05/2021 15:37, Ketan Talaulikar (ketant) wrote:

> 
> For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that 
> different values for different applications is not allowed. Maximum Link 
> bandwidth is also allowed with all bits set to zero in SABM/UDABM  or 
> each individual application bit set for all applications making use of ASLA.
> 
> */[KT2] Yes, you are correct. The RFC8919 does not mandate or require 
> Max Link Bandwidth to be signaled within ASLA (at least that was my 
> reading). If so, perhaps it is better to not require that in this 
> document – just keep in the base. Would that not work? And if it were 
> advertised in the ASLA (as RFC8919 allows it), then perhaps a reference 
> to the RFC8919 will be important on how it is to be done – basically 
> exactly what you described above./*
> 

given that RFC8919 allows the Max Link Bandwidth to be signaled within 
ASLA, we need to be able to support it, in case someone uses that. What 
we would probably need to do is to look at the ASLA advertisement of Max 
Link Bandwidth first and if none is available fallback to legacy 
advertisement.

thanks,
Peter

v2.23.0 | Report a Bug | By Email