IETF Logo Mail Archive

Re: [Idr] Adoption Call for draft-zhang-idr-sr-policy-metric-05 (10/20 to 11/6/2023)

Zhuangshunwan <zhuangshunwan@huawei.com> Fri, 27 October 2023 02:04 UTC

Return-Path: <zhuangshunwan@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C67C15C288 for <idr@ietfa.amsl.com>; Thu, 26 Oct 2023 19:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.204
X-Spam-Level:
X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 U062QnCbd0oc for <idr@ietfa.amsl.com>; Thu, 26 Oct 2023 19:04:49 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED08C15C287 for <idr@ietf.org>; Thu, 26 Oct 2023 19:04:49 -0700 (PDT)
Received: from lhrpeml100002.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SGmDf0p3nz6K8hJ for <idr@ietf.org>; Fri, 27 Oct 2023 10:04:02 +0800 (CST)
Received: from kwepemi500004.china.huawei.com (7.221.188.17) by lhrpeml100002.china.huawei.com (7.191.160.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 27 Oct 2023 03:04:45 +0100
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500004.china.huawei.com (7.221.188.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 27 Oct 2023 10:04:43 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2507.031; Fri, 27 Oct 2023 10:04:43 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Adoption Call for draft-zhang-idr-sr-policy-metric-05 (10/20 to 11/6/2023)
Thread-Index: AdoDfK/TNJV9jfBFQHOxPO5fBvrWRgE+LQgQ
Date: Fri, 27 Oct 2023 02:04:43 +0000
Message-ID: <c0d433d3224c41c287b4c972655f248b@huawei.com>
References: <BYAPR08MB4872A7276F17700F768D21CBB3DBA@BYAPR08MB4872.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB4872A7276F17700F768D21CBB3DBA@BYAPR08MB4872.namprd08.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.95]
Content-Type: multipart/alternative; boundary="_000_c0d433d3224c41c287b4c972655f248bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6NomX6B3MPqv9zUJp7L4f6qScL0>
Subject: Re: [Idr] Adoption Call for draft-zhang-idr-sr-policy-metric-05 (10/20 to 11/6/2023)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2023 02:04:53 -0000

Hi Sue and all,

I have read this draft and support its adoption.

Responses to the following questions:
1. Yes. The weight is used for weighted load balancing, and the metric is used to select a best path, both of them are required for segment lists.
2. This draft has provided clear instructions on how to use metric, and the weight has been clearly described in RFC9256, I think they do not conflict with each other.
3. Yes.

Thanks,
Shunwan



From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Saturday, October 21, 2023 1:49 AM
To: idr@ietf.org
Subject: [Idr] Adoption Call for draft-zhang-idr-sr-policy-metric-05 (10/20 to 11/6/2023)

This begins a 2-week WG adoption call for draft-zhang-idr-sr-policy-metric-05.txt.
https://datatracker.ietf.org/doc/html/draft-zhang-idr-sr-policy-metric-05

The authors of this draft (Ka Zhang, Jie Dong, and Ketan Talaulikar) should respond to this email
And indicate whether they know of any IPR related to this draft.

This draft proposes adding a "metric" field for each segment list for
SR Policy candidate paths in addition to the existing "weight field"
described by the tunnel attribute for the SR Policy tunnel type:

              Tunnel Type: SR Policy
                 Binding SID
                 Preference
                 Priority
                 Policy Name
                 Policy Candidate Path Name
                 Explicit NULL Label Policy (ENLP)
                 Segment List
                     Weight
                     Metric
                     Segment
                     Segment


As you discuss adopting this draft, consider:


  1.  Do the segment lists need both a weight and a metric?
  2.  Does this draft provide clear instructions on how to process a segment list that has both weight and metric?
  3.  Is this feature needed for SR Policy Candidate routes?

Cheerily, Sue

v2.23.0 | Report a Bug | By Email