Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
Huaimo Chen <huaimo.chen@futurewei.com> Fri, 07 August 2020 19:55 UTC
Return-Path: <huaimo.chen@futurewei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEDC3A02F7; Fri, 7 Aug 2020 12:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 QnUoW96fRkto; Fri, 7 Aug 2020 12:55:07 -0700 (PDT)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2117.outbound.protection.outlook.com [40.107.212.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AFD3A0044; Fri, 7 Aug 2020 12:55:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=daNZ1Alk5ttz7nTWtUMDm/xj8Q9JPi2ZD1WoyWIp99dKUXr8SCfncsw/oe2EOuF5X42kkUhugJvFraQG/zei89dqnnRjVCGFliYRcMJVo4bsgFI6XMeI823+6Tu4HJnlgqSiHOOGDtaCRG0mEwj3kugLCXm53H860tI5q7n/Hlw89UakgyZMwpS3q7IpK1pyk/bpSf6US98JZOaCu6hsxDj9IYjJrEiyVgPyHhfDs8jsUzBmc2hU2F9zB2B7xIAHYlAoLJrvv2t8yfH9Pf2MZFY7zi0wdexg1GVWCtgisWg0BeF3nvjqmN1223vIMcuxtKJbEAHuYK2zIOT68AlirQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xG+K6YYvcAAU6HwEavcpsy1Fab78MUI6yxvbmOmcMXU=; b=AzQb4dFqSjEqqVPm3ZbMXtpfNq/SoZv1fBQtW2ohy2gYuocoh7h7VJTHU0w07zBVF/7VVNp1w0s5ClG4m4600l8cLDd2QCGHqO812mL5YqxjO+9GTzoqK0TuMF4vVag5FOqgGcMgtdMNFhxxC+Lr7MAdxzXc0c82gZycyE5IyiHOcu5Hgm26JvhY98xBeoXfNG5tomw2SKIMBJ/C3UeSRtrk9bj9CccVFeqpjegGM5DOy2Yiv2IWhPWUVIc7b76dtX0W5lefdWAASty+TftuCwp1sbq1pBLnMMpN1ptDuGBpGFQEemMNUEZq4C4nSOBr0SYEuSBEzfWxi6EFvJ+EHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xG+K6YYvcAAU6HwEavcpsy1Fab78MUI6yxvbmOmcMXU=; b=dk97VZq9UNRSTpCyNwum22iqEsbt4MUiM0TlH5IUkE1ZWvkAVvYBKL3lJevKIbwFgcmrifBz2vMoEO72y40uKmLakuvq9lXPPtTY1F7JmdjwCI++HxW280uzU+QNKgzkfCLQijgBgtr0t/TpBCh9nKeRizE3UK8rXXQ1/R5LBlM=
Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB2975.namprd13.prod.outlook.com (2603:10b6:208:13f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.7; Fri, 7 Aug 2020 19:55:02 +0000
Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3261.013; Fri, 7 Aug 2020 19:55:02 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" <draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
Thread-Index: AQHWbGHVs3ky4w+nbkCPI9JM5YmDVqktD04s
Date: Fri, 07 Aug 2020 19:55:02 +0000
Message-ID: <MN2PR13MB31175A0ADCA331E457C7ACB3F2490@MN2PR13MB3117.namprd13.prod.outlook.com>
References: <159676704653.18651.9315612770740538972@ietfa.amsl.com>
In-Reply-To: <159676704653.18651.9315612770740538972@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [73.114.233.24]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 85fe26e3-72dd-4e0d-9781-08d83b0bc617
x-ms-traffictypediagnostic: MN2PR13MB2975:
x-microsoft-antispam-prvs: <MN2PR13MB2975E0516241A3105C24B39DF2490@MN2PR13MB2975.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: b9Z+C3FyHiXNJ7e5DNQswCVcFZLtoAl+lQd9T5KVOaI811Cj8FOZqzklKjL3thImTRMWOsojZ5/qVHe2fhW5wtSMnW62QK7Ej3kr6NM3NRrLVZI65mn68q73R6Rj3tFjWpoWRfn6oXkme0raxshtHqfBXD/HYadKRvKZdmUZgb8Pg0uF9pmkdAWb4OXEsJacYgsztmxXHnFnKZYn3vB4HVYWTY7jPr+ll6Jz5n8Y7CG4zJPvofnbOYd8nrtbYXKrUjjfXaVJIYbaUbKK0HvMtU77bv+K2xJTHJGk7BRzjdaDs0jfyvh5S8l5FP2o9P55Oe7lFO3JQWzC/6yhMVBaDv9WDw248Sfn00h/ukJ8R6yjZHp3xyFE5801DwD+3hHzqq0Jkz2Lko4aAoKu/uGnvA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(376002)(396003)(136003)(366004)(346002)(54906003)(110136005)(8676002)(166002)(5660300002)(53546011)(6506007)(8936002)(316002)(7696005)(52536014)(45080400002)(4326008)(66946007)(9686003)(966005)(83380400001)(19627405001)(33656002)(26005)(66446008)(66556008)(64756008)(66476007)(2906002)(55016002)(86362001)(44832011)(76116006)(71200400001)(478600001)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: zORz8ZsWBgR6p2O1NDfPfU87VQcWntJmiG+YbWJf2GwXDaYX6yINdGpgSbNVdGSwN4ntnVRyy51ejvFDnSAuSy+kH92Dw7A51ZSgZzTeTikD9Zv+9XwUaYjXeWRQBCefcPt/NivbSmRlF0himUCa6XUMs2TxFwcVetQKJHBbaa3hZg7bZWjiMpjBRhuMP4krih7SnrcHcCE3TaIsrYQszAmnpZ4a7ySu0YjuYb6kq7HpdpN7SR2H1PFpoQKAPvjnjcSxJvsnTBjc5rgI5Fm+iYLolDLEVPgzVaXF0KeF19cAZskfbxZi4O7dim7gGDwnWg+XJavpw78xFS1AhxW++yKKAK0lV22F5bDO7e87pzRSTXBeNkArWcaw8aXe4Ki21ZtEZ8iYnHRfQwkgPTklm8e3zM7jo8IoTbdFiCukePXx6ize3etqLPeYcYi68FmJbx59APYd1trLiYLch6TLtKI7EWpRC39QnkXYzAnqKMQPH9h+RfBqWg9uzcgo/1HyxoJ6wGyV7Gp7Ff0IYuAhSBoNDtm5ohAHne8fCE+Mwv7LaAJeZTClLEqStE9qM7mxlqUKp3MIbYqYRuXr+upIHOCy3uttp+/V1SEVVfYFaVFnlFbTPnDdTu/NzpduH9Ep7JY6O2tD37KnMP8noDzNiA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB31175A0ADCA331E457C7ACB3F2490MN2PR13MB3117namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85fe26e3-72dd-4e0d-9781-08d83b0bc617
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 19:55:02.6209 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yOJRvVkCgWIbTNYZwympszAIkie7pI8mHuVyrYD5qfft5nuUSTAbIBAOOfqrflxlcsYoBeZmx77ZtasqVGDOyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2975
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/cf0UEIP2yw-qTSt0JDXFmp0Pwi4>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2020 19:55:10 -0000
Hi Ben, Thank you very much for your further valuable comments and suggestions. They should have been addressed in version 24 uploaded. Inline below are my explanations. Best Regards, Huaimo ________________________________ From: Benjamin Kaduk via Datatracker <noreply@ietf.org> Sent: Thursday, August 6, 2020 10:24 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce-chairs@ietf.org <pce-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>; Adrian Farrel <adrian@olddog.co.uk>; adrian@olddog.co.uk <adrian@olddog.co.uk> Subject: Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C77e5a8e196f9405b19f808d83a78f6f4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637323638504477582&sdata=Qbc5Va%2BmQottFqMBHI6%2BycUle3BhkWfxushrS3qFvQ8%3D&reserved=0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C77e5a8e196f9405b19f808d83a78f6f4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637323638504477582&sdata=My4fM%2BqPZCPeYIRAFragD9ZRgy40vAkIguq474QA5Nk%3D&reserved=0 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing my first two discuss points from the -19; it looks like the last one is still remaining (please note that I had a typo in my original ballot on the -19, referring to a section 3.3 when 7.3.3 was intended): Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 7.3.3 of RFC 8231. [HC]: We have changed it to "Section 7.3.3 of [RFC8231]" as you suggested (in version 23). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some new comments after reviewing the diff from -19 to -22. (Signs indicate that processing of my previous comments is still underway; if there's a need to refer to them they are available in the email archives and in the 'history' tab for the document in the datatracker.) Section 4.1 For a scheduled LSP crossing multiple domains from an ingress domain to an egress domain. There is a PCE responsible for each of these domains. The PCE for the ingress domain is called ingress PCE. The PCE for the egress domain is called egress PCE. The state of the LSP MUST be synchronized among these PCEs. After a path for the LSP is computed, a PCRpt message with the scheduled LSP information MUST be sent to every PCE along the path from the ingress PCE to the egress PCE. After receiving the PCRpt message, the PCE MUST update its SLSP-DB according to the scheduled LSP information. The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message. After receiving the PCRpt message, the next hop PCE acting as a PCC sends its next hop PCE the PCRpt message. This continues until the egress PCE receives the PCRpt message. A bunch of nits here. How about % Additional requirements apply when a scheduled LSP crosses multiple % domains, from an ingress domain to an egress domain. There is a PCE % responsible for each of these domains. The PCE for the ingress % domain is called the ingress PCE. The PCE for the egress domain is % called the egress PCE. The state of the LSP MUST be synchronized % among all PCEs along the path. To achieve this, after a path for the % LSP is computed, a PCRpt message with the scheduled LSP information % MUST be sent to every PCE along the path from the ingress PCE to the % egress PCE. After receiving the PCRpt message, each PCE MUST update % its SLSP-DB according to the scheduled LSP information. The ingress % PCE acting as a PCC sends its next hop PCE the PCRpt message. After % receiving the PCRpt message, the next hop PCE acting as a PCC sends % its next hop PCE the PCRpt message. This continues until the egress % PCE receives the PCRpt message. [HC]: The paragraph has been changed to talk about synchronization among the PCEs in one domain as suggested (in version 23). Section 4.3 o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP. Besides, it MUST send a PCRpt message with the scheduled LSP to its next hop PCE along the path of the LSP, so as to achieve the scheduling traffic engineering information synchronization. nit: I think s/Besides/Additionally/ [HC]: We have changed it to Additionally in version 24. Section 5.1 During a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. [...] Some nits here; maybe: % During the PCE session establishment phase, a PCC and PCE indicate % their ability to support LSC scheduling. [...] [HC]: We have rephrased the text accordingly in version 24. Section 5.2 Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its presence in the LSP object. The new text here has changed what I interpret it to mean. I interpret the text in the -22 as allowing for an LSP that includes one SCHED-LSP-ATTRIBUTE and one SCHED-PD-LSP-ATTRIBUTE TLV in the same LSP, whereas the text from the -19 seemed to indicate that if (e.g.) I had a periodic scheduling TLV then the regular SCHED-LSP-ATTRIBUTE was forbidden. After just a cursory amount of thought, it seems like there is not a useful way to interpret both TLVs at the same time, which would make this text change a regression, but I may be missing something. [HC]: These two TLVs MUST NOT be for the same LSP. We have added the text to explain this and rephrased the related text (in version 24). Section 5.2.2 STATEFUL-PCE-CAPABILITY TLV carried in open message. If the TLV is received by a peer when both bits were not set, the peer MUST ignore the TLV and generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter). (nit) English has this unfortunate property where the "not set" in "both bits were not set" can be interpreted as a synonym for "unset", which would make "both bits were not set" mean that this is describing the case where B=0 and PD=0. What we actually mean is "anything other than (B=1,PD=1)", which might be expressed as "If the TLV is received by a peer when either (or both) bit is not set". [HC]: We have changed it accordingly (in version 24).
- [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-… Benjamin Kaduk via Datatracker
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Huaimo Chen
- Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk