Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

Huaimo Chen <huaimo.chen@futurewei.com> Wed, 22 July 2020 18:18 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 195B73A091F; Wed, 22 Jul 2020 11:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, 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 oZLY4x8a2FnI; Wed, 22 Jul 2020 11:18:44 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2105.outbound.protection.outlook.com [40.107.223.105]) (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 3E4233A091E; Wed, 22 Jul 2020 11:18:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RL63i0XM+FEldSr05tzikl8QHeEfDIHuD8JMHwlSTHoo8b880SemqV8MFMbZ4ANPsuhw4TX/oz/GOO9BEUJ+Tkds7rhC5Cvcj1PseEmW0Wj4mfqo2/9oR9JVcNh0/kCSqdHezE6oEdzomDHPCt7k1MnSLf54UwJkT1xUjkud/82Sc7TlfWUCT860RAsQ4ULV6v2y6aJDUwIMarT8U98eCwK9CC1zdNYcJ3ZzO1uixD6dW475NOg0VUgl0vccPxZXa6VGl0S0k2kIGeafB2LP0aCjNsAE/MRwQAyHaam+HvH0yCMgPL7Qs6O41NG6+GYv8Ve2cAPVoPOHLb5v2u2bbw==
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=71gAbQaVZXW4jD2kXtZEuE4fqs9R54UI71Zzncu7HfU=; b=DN7yInbvwdmLZVcQTVhqP0IFOP9qA/o0Dbn8RPaIPB7GTZGtro/xHEGNlBKP09f7/GwEJsqsJzheNMT24+mJaArToKU/4hCGHh9N7v2MWN+NGIaoHk3zRGkqExwZ6ZBBpcjf+fKiNmVNM9eqeQqqHCWYB4jha5gtye8HUufY4208+dBaGmRuBq6Tu0Rz4i0ugkUQTjyu2DQsfMDh+pDTWch+lTjmrc+czeHS4AbpmlyPyLcL3mtzSi60Sk/heAAkJk0l2CMOSvgsURaNl93F37WRTrmcWpNZrWHN3nVKPq08P6sKNfklwXlA+pzu0v28NPWbc/CCMz8MsZbwdUlSPQ==
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=71gAbQaVZXW4jD2kXtZEuE4fqs9R54UI71Zzncu7HfU=; b=mnFVVIX7+fEJyafHjvGld7w1K4nnNf7/hfucD4BT3WLigK0tasq/iDbDzHxY6KGbtVkkTkI2ukXGE4COqsKKpeH/aYfcmZFvL9ZLAqse7K2d10Gao2mudgqdIQrLSwIu2sLMcLirN0xgkZr5n+6KkXkvWyNaOgGoC1gnR8jol+k=
Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3711.namprd13.prod.outlook.com (2603:10b6:208:1e3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.18; Wed, 22 Jul 2020 18:18:42 +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.3216.020; Wed, 22 Jul 2020 18:18:42 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Alvaro Retana via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>
CC: "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" <draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)
Thread-Index: AQHWVI3Xkb0zxFK8G0euXGvvDcHNd6kSQB8AgAG3j/8=
Date: Wed, 22 Jul 2020 18:18:42 +0000
Message-ID: <MN2PR13MB3117333366F91AEDF0B74FC1F2790@MN2PR13MB3117.namprd13.prod.outlook.com>
References: <159414709200.5178.3398442601733460072@ietfa.amsl.com>, <CAMMESsxcVn7aNFav+4U_ReVerV87YKAFVDeqvZDSDkRYtG3GMA@mail.gmail.com>
In-Reply-To: <CAMMESsxcVn7aNFav+4U_ReVerV87YKAFVDeqvZDSDkRYtG3GMA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2601:199:4300:8e5a:f4d4:7dde:c8f6:9ec1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce70d76c-5969-47c2-1445-08d82e6baa4a
x-ms-traffictypediagnostic: MN2PR13MB3711:
x-microsoft-antispam-prvs: <MN2PR13MB3711AEC45335D5CAA1198C49F2790@MN2PR13MB3711.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: B+37BrtvU1CS1z2M00o0KwMSY+fkmpyXIR2gumbpph2Iku4xZb0vZ8y4UY/1YZZUQojgEG2CVdGL+Ps5mkdOLpUbrbvh3bUOYZGZUUURuWqadtc5b+0mzX8ggWoHvKxnHV7CTkZAKbXHjjqqe8AedjWWGUEO/Vz4mjnY6wMQjWIMtlC7LZdb85h+63jZN9sTagypTwLHzdN+tCJYa+Kp0tiK3m57f3/dlqeVPQcgkVnfggQcbeESt9utT47VKZRnn/3jZPCoGCRKUPfhEIAg+QfKiuOf+wqIoejKuydL6L/Q9Z9WrpwIU85ZlP1Q/gTElK/cKWMn3L17VGG0UTA8fA==
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; SFTY:; SFS:(4636009)(346002)(366004)(39850400004)(396003)(136003)(376002)(9686003)(186003)(71200400001)(6506007)(4326008)(19627405001)(2906002)(7696005)(110136005)(53546011)(54906003)(52536014)(55016002)(316002)(478600001)(8676002)(8936002)(33656002)(66946007)(76116006)(83380400001)(86362001)(66476007)(64756008)(66446008)(66556008)(44832011)(5660300002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: qm/ocWcol1wtdd40YPtn0O3eV34s93JCRiI7DaGJtY4bsoxHbu1kbLYxm4Y/g3vjGqx8bUw8PrA+tVxHJ2WQTRGPRXT8RS/r2Bih8QdL1ZVKJq2ijDLtnCb/vNm2TCWhiLsc0G899AHGub2gbXCfJa1t+0te/UUJ2nHAuWj5BqqGOwsr0U8rWuoMCtQ3EelhswsGn1mpraiZf+b0EPG16HFmct+LPdan8cgYBgBZMKEKLQ+aFBbCqfB2gIhTkvSKUg9ZXcHYIZuunJm5QL6uZ/EXuC/cFV4zTscdp5Eb2RtqlbQuDxjCIjJpAMCaTJJJ4dMHTPJNW0pwKiluuS7r816D6CYA7itWaJy6cWRU1eH6rWmBS7pv1kw1MGGEHdtN/dzBbsuCJLEs724OPp8D9BdX97ZkbTPyyo7GdJBvcosHSsvQ5IXM8YgB76yExtqFmB+28vGGOc1OGW0PhdSj2oYIUSi+oZ447j1p6u7q8xSOc/2BRm4q+cIKz88rz3cxvwGHaEOXIVtfVEEgErpWaKRzt6mp4Z+OczBBSva8eGNdx9GcwbNl4tAEeq/CwHCm
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117333366F91AEDF0B74FC1F2790MN2PR13MB3117namp_"
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: ce70d76c-5969-47c2-1445-08d82e6baa4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 18:18:42.5045 (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: Lw8vPPK/M/8qSbFqkTkzGwZjtKc+w+33ytQU9hvjZ1f6n9zGZBcsDXDrs6jypPy/bG5GDXTLytbMTUDfYfY6zg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3711
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/k4hCYoxhe2UzcOH6G4Brogp12TA>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with 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: Wed, 22 Jul 2020 18:18:46 -0000

Hi Alvaro,

    Thank you very much for your valuable comments.
    My answers/explanations are inline below with prefix [HC2].

Best Regards,
Huaimo
________________________________
From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Tuesday, July 21, 2020 11:35 AM
To: Alvaro Retana via Datatracker <noreply@ietf.org>; The IESG <iesg@ietf.org>
Cc: pce-chairs@ietf.org <pce-chairs@ietf.org>; draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>; pce@ietf.org <pce@ietf.org>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote:


Huaimo:

Hi!



...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> I think that this document still needs work before publication. I consider
> the first 3 points below to be close to DISCUSS-worthy.
>
> (1) In general, it feels like an editorial pass is needed to tighten up the
> language used as specification in this document. There are several places
> where the language feels loose -- as an example (from §4.4):
...
> [HC]: We have updated the document according to rfc2119 as you suggested.

Thanks for addressing this one instance.  As I mentioned, there are
other similar instances that would benefit from similar tightening up
-- please reread through the document with an eye for "loose
language".  I trust that you will do the right thing.

[HC2]: We will reread through the document carefully for "loose language" and
update it accordingly.

> (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which
> way is used to achieve this is out of scope for this document." If the
> synchronization mechanism is out of scope, how can an implementation be
> compliant with this specification? IOW, if there's nothing to normatively
> refer to, then normative language shouldn't be used, or a mechanism should
> be mandated. In either case, because synchronization between the PCEs seems
> important for this specification, I would like to also see a discussion
> about the specific effects on LSP scheduling instead of the generic pointer
> to rfc7399.
>
> [HC]: The description related seems too broad. We have rephrased
> the related text to focus on the state of a scheduled LSP
> crossing multiple domains from an ingress domain to an egress domain.
...


As mentioned separately...I think that changing the scenario is not a
good idea at this point.  It also leaves the single domain case
unaddressed.

[HC2]: We will update the text according to Dhruv's suggestion.

> §4.3 says that the "stateful PCE...shall send a PCRpt message with the
> scheduled LSP to other PCEs...to achieve...synchronization." Even though
> normative language is not used, the intent seems to specifically point at
> using PCRpt messages for synchronization...
>
> Besides the confusing use of language, rfc8231 defines PCRpt as a "message
> sent by a PCC to a PCE to report the current state of an LSP", but I didn't
> see where the use if defined between PCEs -- maybe I missed it. §6.1 does
> reinforce that the "Path Computation State Report (PCRpt) is a PCEP message
> sent by a PCC to a PCE to report the status of one or more LSPs as per
> [RFC8231]....This message is also used to synchronize the scheduled LSPs to
> other PCE as described in [RFC8231]". But this last point is what I can't
> find in rfc8231.
>
> [HC]: We have updated/cleaned the text related.
> The Path Computation State Report (PCRpt) is a PCEP message sent by
> a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt
> message to another PCE.

The "as described in [RFC8231]" text is still not accurate -- that
document doesn't talk about using the PCRpt message between PCEs.

I don't think that the "PCE can act as a PCC" part is well defined.
Is it specified somewhere else?

[HC2]:  RFC 8751 has a child PCE acting as PCC and
sending PCRpt messages to its parent PCE.

> (3) This whole document is about scheduling LSPs, which would seem to require
> time synchronization. However, I found only one mention: "It is necessary to
> synchronize the clocks of the PCEs and PCCs when relative time is used."
> Should this sentence use normative language? Is there a recommended way to
> achieve time synchronization? This seems to be an important manageability
> consideration that impacts network operations.
>
> [HC]: Yes. We have changed it to use normative language, and
> recommended Network Time Protocol [RFC5905] for time synchronization.

The reference should be Normative.

[HC2]: We will move it to Normative References

Thanks!

Alvaro.