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 12: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 657033A0798; Thu, 27 May 2021 05:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.297
X-Spam-Level:
X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 7P68WZf_BtqE; Thu, 27 May 2021 05:49:54 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44ACE3A0799; Thu, 27 May 2021 05:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1622119794; x=1623329394; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JyASHw0YUpimp0bfmjH4he7L6DknXCYWUnZhQudWhaE=; b=M5nfoklFYHbPEnOoUMdV4XkYr3+s6Er9lxCpQtFjo/0ozKjUy1H8/zRy kdp9i4whV1FZUxmzkN0H/P9pCpx7IlHDjflZ/kTbOecwHN7pXP+0Pguut W1BYqnmmo+DSkJ7xdOcEwNg/fgJHi4RjDnSb440CRCLDu6StWbLDuHK5a A=;
X-IronPort-AV: E=Sophos;i="5.82,334,1613433600"; d="scan'208";a="36409082"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2021 12:49:52 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 14RCnp5f028548; Thu, 27 May 2021 12:49:52 GMT
To: Shraddha Hegde <shraddha@juniper.net>, Tony Li <tony.li@tony.li>, Ketan Jivan Talaulikar <ketant@cisco.com>
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> <8c49f2d0-0842-bff5-9121-7ceb37781a38@cisco.com> <CY4PR05MB3576FC5B449DDA9BB82C38E6D5239@CY4PR05MB3576.namprd05.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <a6437340-0db0-921a-d013-6b5945013642@cisco.com>
Date: Thu, 27 May 2021 14:49:51 +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: <CY4PR05MB3576FC5B449DDA9BB82C38E6D5239@CY4PR05MB3576.namprd05.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-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qeBTQYJDrGX_InEeh2ZtnvZVxvQ>
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 12:50:01 -0000

On 27/05/2021 14:36, Shraddha Hegde wrote:
>> we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we >should be fine with the existing FAPM.
> 
> Yes agree.
> The idea of making generic metric variable length is worth considering.
> I don't see a strong enough usecase right now to make it variable length but will wait

nor do I.

thanks,
Peter



> for inputs from WG.
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Peter Psenak <ppsenak@cisco.com>
> Sent: Wednesday, May 26, 2021 10:27 PM
> To: Tony Li <tony.li@tony.li>li>; Ketan Jivan Talaulikar <ketant@cisco.com>
> Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-con@ietf.org; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Tony, Ketan,
> 
> On 26/05/2021 18:40, Tony Li wrote:
> 
>>> */[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.
> 
> we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we should be fine with the existing FAPM.
> 
> 
> thanks,
> Peter
>>
>> Tony
>>
> 
>