Re: [Int-dir] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

Peter Psenak <ppsenak@cisco.com> Thu, 01 June 2023 10:54 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C198CC14CF1F; Thu, 1 Jun 2023 03:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJQEGQoNxTu0; Thu, 1 Jun 2023 03:54:39 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF667C14CEFE; Thu, 1 Jun 2023 03:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2565; q=dns/txt; s=iport; t=1685616879; x=1686826479; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vCRS8gCeyZK3I6vfgnyOKFmsf1QNUuk7jqa2FnMUELU=; b=l9GrSfLfm0HbygZXL0d1lEx4sOd33P0VtwJ9nAZyXy2fvePGgxI0rJVU 39rYs1oO/DFGUuKBPf2vLmJ5T/gkwx+48AXdPAEP3YpMF0/Exa60s6bvb ZzOjY/oCIu1vJWgX34PDTT8JAnbtJ6sQJGzx6FvsNUbLGy0hJkuMcaj+0 o=;
X-IPAS-Result: A0ABAABfd3hklxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIE7BQEBAQELAYN4LhKFGIgdX4hBA51ngX4PAQEBD0QEAQGBU4MzAoVgJjQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBATcFEDWFdYYEAQEBAQIBIxVBEAsYAgImAgJXBgEMCAEBgnqCOiMDVq4qeoEygQGfYIFogRUtAY0XF4QxQoFJRIEVJwyCeD6IH4JnBItGgmeNcYEvcIEhgSaBAgIJAhFngQ4IYoFzQAINVQsLY4EjglkCAhErExUFRXwOAREDBwQCgQcQLwcEMh8JBgkYGRgnBlYHLSQJExVCBINnAwqBG0wVEgIRTSUEDgMZKx1AAgELcD0UIQkLHwYmAR4CK4FYBC+BUygknyBdDGoBA1dMgRQvAVSSJJBmoQmEEoRjnCEGDwQvg3+MaoY8kUlimA4ggi+lZIEyMTqBWzMaCBsVgyNRGQ+OJxKTVkJsAgcLAQEDCYtGAQE
IronPort-Data: A9a23:eF0YFKoPejOQoepItvuo/oasK75eBmLUZRIvgKrLsJaIsI4StFCzt garIBmFOPiPa2T3Lox2bo3loRgHvpTUzoM2SgBq+Xw3FHxBpePIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILas1htZG0k8EE/NtTo5w7Ri2tAw2IDja++wk YqaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDf3Zw0/Df2VhNrXSq 9AvY12O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/RPjnRa70o1CBYTQQAIt2uGrdte8 vtE6pGTYwcOB4P9sc1IBnG0EwkmVUFH0LbKOz20ttaeihSAeHr3yPIoB0YzVWEa0r8oWicVp bpCcGtLNErra+GemNpXTsF0nt8uKsDoFIgeoXpnizreCJ7KRLicHPyWvYYDtNs2rthHJvGHZ pBDUyJQdkXOQxBvGRAuIp1ryY9EgVGmI2EH9zp5v5Ef53PJ5A18zLarN8DaEvSOTN5J202Ro mbu/mnlDFcdLtP34Taf+3yww+7CgS2+XJkIUbygs/BujU2awmMUThQSUXO6rOW3zEmkVLp3K koIvyYvt4Az+VClCN7nUHWQqXiYuR8aVpxeCeAh8wiLwa3J+RqxBnUNUTNALtchsacLqScC3 1KT2tLxAiZz9bucVTSW96yfqnW5Pi19wXI+iTEsClQ5vdbRq64JoBuQQ/VJEImMoOzcMGSlq 9yVlxQWi7IWhM8N8qy0+1Hbnj6hzqQlqCZou207uUr4tGtEiJ6Zi5+AtAKAs6cQRGqNZgTb5 SJV8ySLxLpWZaxhghBhV80rONlFDd6sNDjRm1MnJIUo+1xBEFb6JtkNiN2SDGltP9gDfTbvb CfuVeJtCH17YSHCgUxfOtzZ5yEWIU7ITIWNuhf8N4smX3SJXFXblByCnGbJt4wXrGAikLskJ bCQetu2AHARBMxPlWTmGrpAju9wmXxvmAs/oKwXKTz6gNJyg1bIFt843KemNYjVEYvd+lyOq oYDXyd040wHDrKWjtbrHX47dABWcidT6WHeoM1MfenLORt9BGwkEJfsLUAJJeRYc1Buvr6Qp BmVAxYAoHKm3C2vFOl/Qi06AF8Zdc0k9ixT0O1FFQvA5kXPlq72sftGKMRrJuN5nAGhpNYtJ 8Q4lwy7KqwnYlz6F/41NPERcKQKmMyXuD+z
IronPort-HdrOrdr: A9a23:xCjLqK7yzG3wDI7M0gPXwPnXdLJyesId70hD6qm+c203TiXqra GTdZMgpHnJYVcqKRYdcL+7VZVoLUmskKKdpLNhWYtKPzOLhILLFutfBOLZqlWKJ8S9zJ8+6U 4KScZD4bPLbWSSwfyU3OF9eOxQuOVuN8uT9J7j80s=
X-Talos-CUID: 9a23:bmvf+mhw/q20202x7se50vk9YTJuNSLhknjiKGCCJ282RZ6/SXip1pJNup87
X-Talos-MUID: 9a23:w3omuwU6asLlhLLq/CflvzY7NZ0y2byREhEDsZgmmI69HyMlbg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="6.00,209,1681171200"; d="scan'208";a="7714013"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2023 10:54:36 +0000
Received: from [10.147.24.37] ([10.147.24.37]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 351AsZxQ024185; Thu, 1 Jun 2023 10:54:36 GMT
Message-ID: <5c1b18f3-a834-f8eb-9755-715f6b0c8795@cisco.com>
Date: Thu, 01 Jun 2023 12:54:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.1
Content-Language: en-US
To: Antoine Fressancourt <antoine.fressancourt@huawei.com>, int-dir@ietf.org
Cc: draft-ietf-lsr-ip-flexalgo.all@ietf.org, last-call@ietf.org, lsr@ietf.org
References: <168561134224.9013.2692506261437440094@ietfa.amsl.com>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <168561134224.9013.2692506261437440094@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.147.24.37, [10.147.24.37]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/BShkX6ixF6DssVXvUWDqzJpRu-U>
Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2023 10:54:43 -0000

Hi Antoine,

thanks for the review, please see my response inline:


On 01/06/2023 11:22, Antoine Fressancourt via Datatracker wrote:
> Reviewer: Antoine Fressancourt
> Review result: Ready
> 
> I have reviewed this document as part of the INT area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.
> 
> The document, in version 12, is well written. The objectives of the draft are
> clearly stated, and relate to the requirement stated in RFC 9350 to describe in
> specific document each extension of Flex-Algorithm beyond SR-MPLS and SRv6
> data-planes. The draft's structure is borrowed from RFC 9350 and describes
> forwarding or operational considerations.
> 
> In my view, the document is ready to be published. I only have one minor
> comment that the author might ignore as it may stem from my inexperience with
> IGP Flex Algorithms. As far as I can tell, the metrics that can be used in
> flexalgo can be rather dynamic. Given this dynamicity, what is the policy that
> should be adopted in case the metric for a given prefix is updated very
> frequently? IGP convergence can take time, and consumes resources on the
> routers, and I was wondering if there would be some sort of threshold or
> minimum time before an update is considered.

there are three metric types defined in the draft:

1) IGP metric
2) TE metric
3) Min Unidirectional Link Delay

First two are static values configured by administrator.
Third one could be measured, but the min delay mostly reflects the 
property of the physical layer and should be semi-constant, unless the 
physical path changes (e.g. re-routing at the optical layer).

RFC8570 that defines the "Min Unidirectional Link Delay" says:

   "Minimum and maximum delay MUST each be derived in one of the
    following ways: by taking the lowest and/or highest measured value
    over a measurement interval or by making use of a filter or other
    technique to obtain a reasonable representation of a minimum value
    and a maximum value representative of the interval, with compensation
    for outliers."

RFC8570 also talks about announcement periodicity and announcement 
suppression to avoid frequent changes in these values.

On top of what RFC8570 mentions, IGP implementations have SPF throttling 
mechanisms to avoid too many calculations, even if some originator 
advertises these values too frequently.

thanks,
Peter


> 
> Nits from the Gen-ART review have been addressed in version 12.
> 
> 
> 
>