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:27 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 37D463A077A; Wed, 22 Jul 2020 11:27:11 -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 hkiuzljzSgCU; Wed, 22 Jul 2020 11:27:09 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2116.outbound.protection.outlook.com [40.107.223.116]) (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 55C383A05AC; Wed, 22 Jul 2020 11:27:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EwwyzpFufGw7uGrV6hlrZ5w6+j14CHL0Xt7S3eMKVgMv6+feRAf6dgbfjDjY/4lEPJyfazCrn6QLNSzXFlKLIUDtvN6NSj5Z/iKgPgSfXQlqnXWVSaW0BS6VgbXCZkCtLw6tOcsnZN3r666tEXQwGuS5P7wuiPOH0syRRUL85MfLHfdgNcu5Ygj1zNRkyZIEz09RdYTGFf/h3KRnXWhDSXmj4uvjLoiCyp/GkxFjqAvp/2UTW2aVFOgA3IVmpJA8/0/X+2Rj4N8PEEB1GMnf2Kiut5OR6YD/01/qILzMrjoJdY4kVjKrX6jYVZo1MO9koQZRJpoHPeE01hd7jLFm4w==
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=fnbBJOQ3gO04NHVSOZ9abq3fF4xgJWcssYih2qtEvA4=; b=EQQxm/Zt33EKmSXzK2eyNBSA6IP7HuCYoE4dENhyw2msw+CnaZUAooGRnN5+SH5uUEz2JjVPUUiXpclyA9vMeWE970dnmDc2hVlhoY0lO90f2E5ACmmDQOl4PNOsOSOiNvK+wZxDjzoxBYsJe5sKGFZPAYyd6eYUGXklKtzntfraTvsRYznJi8mFHleEunCl0NIbIO1IyHooHADLV3PRO3nOvFjr+c2h5PMJ1Bom0Vox0hNlW+rLbSL7zCWxhyQ33nH6JOfy76nfCWdfSWQQZNjp5sHRbHiRidrOTcPjtlHCh7hE95IAjJfMqOpMGiKRxnsDu1jFEv4BJrfm7o5Udg==
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=fnbBJOQ3gO04NHVSOZ9abq3fF4xgJWcssYih2qtEvA4=; b=uLoeC9w4PbdoBYyVGjdHQA8/l7psrG5u1TLjFdAmBqeIujhrPfhz5t1tJf//NALtTzaff2Pbu4XxVf+74udKHJ/ce9VvL1STrsOeYOb3+iHS9c6rXziEpCOdnBVleqAhqkPSTS9Ohw8eJh3o8rvG5VMALcGo9oROvsQlUy/bYws=
Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3216.namprd13.prod.outlook.com (2603:10b6:208:13b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.14; Wed, 22 Jul 2020 18:27:06 +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:27:06 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Dhruv Dhody <dd@dhruvdhody.com>, Alvaro Retana <aretana.ietf@gmail.com>
CC: Alvaro Retana via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, pce-chairs <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: AQHWVI3Xkb0zxFK8G0euXGvvDcHNd6kSQB8AgADW1wCAAOmtsQ==
Date: Wed, 22 Jul 2020 18:27:05 +0000
Message-ID: <MN2PR13MB3117AE60D6774BC1ABB65DF0F2790@MN2PR13MB3117.namprd13.prod.outlook.com>
References: <159414709200.5178.3398442601733460072@ietfa.amsl.com> <CAMMESsxcVn7aNFav+4U_ReVerV87YKAFVDeqvZDSDkRYtG3GMA@mail.gmail.com>, <CAP7zK5Yg9VhHR6F7K-EXdDeO6UO_HefU4sBQCJ-ScUPvW8RCMg@mail.gmail.com>
In-Reply-To: <CAP7zK5Yg9VhHR6F7K-EXdDeO6UO_HefU4sBQCJ-ScUPvW8RCMg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dhruvdhody.com; dkim=none (message not signed) header.d=none;dhruvdhody.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: 5d348ad4-4a8c-4578-84c5-08d82e6cd656
x-ms-traffictypediagnostic: MN2PR13MB3216:
x-microsoft-antispam-prvs: <MN2PR13MB3216E0ECBDA789F0AF336CE7F2790@MN2PR13MB3216.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: 9ul9Nv8EaFLFoz1/BW0Frq6+npvnxo2zP6b3qlWdvqGejM2YDUR5yAqiqk05uWh9klGLiRoyO35lgEIzSjaw3DQle7BOMokdw3biNkkALhhB3VW3y424mx6uKx42+d4r0eIv1D3rhMyvMztnaZ0N5vXrurM+O7ALL5VeeJlFES+7N1gX9HTrSg4msTONuU+TCnnHCDcEABrZUB9MuCRhdJp01FtZOI4R4kN/tSFe1pu+/JldjW4e5ygVfF3C1JxDbi0KZnN9sViCcsIIlTFpanWBp5dcNBTmqtvxVa6u9K20guto64iXcZOqvKnhk9ZwCFKnGIy1rTuGD+qL9+mQ+Q==
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)(136003)(366004)(346002)(396003)(39850400004)(376002)(8936002)(316002)(9686003)(5660300002)(86362001)(7696005)(2906002)(186003)(71200400001)(8676002)(478600001)(83380400001)(4326008)(110136005)(66556008)(66476007)(33656002)(66946007)(64756008)(66446008)(76116006)(55016002)(54906003)(44832011)(53546011)(6506007)(19627405001)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: YFjjYNBLeDuttQzx+0GEQI4uYxHZaO9oWbCCJmMtmNWgDQs01b2wwOju6KNtIgOtUe3GPqY3uI2wHi6p78XutO62+lv3I/dx5GYpuGrYvVErNSF2nwkyAiKjHLkAaEC17ouqmOFmWiQ5LKiI3e0MWTu9+ELq/G3ZiyYex13IxuJsidk/1l93fJmuYF15jWHwWOyTXzVgeaOpK+Q5igcHyiZ/JDBZ29VYaP0KCK4CzdklAm/K41U1kdAQB6Gif8Xp/+YXzynKMHtJmQWNDYwWKzsJ7VUUKg6IC5h9MrvDAOM3wG0vOgaXOhzm1z+BQOlJZ5mSw00s5APCsd50cNbe8Ue0QqpaCdhWuewOTeq7QY9nAbCynVpjBff9zKxVIkaDbm4eRUZXIh39z6n2Ct8a+ADRFUaX8pPEW1AVzP5ptzxR8RNlrq703IIjRllyVgQVvg4NP3VWyzBoR/ttLhdt0NkrElKA9os2Zr7u7mKwRt1PeZsLWMbNHvvlBlbjy/9XXBfzaYTw4YAettEqiRvBBnlEirqrFlkEQRrfQEYfXjWB5LPfFJZKGYb15t41cGHL
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117AE60D6774BC1ABB65DF0F2790MN2PR13MB3117namp_"
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: 5d348ad4-4a8c-4578-84c5-08d82e6cd656
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 18:27:05.8576 (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: T4wSmVrLwp0irqLw4Bg9XlWYpV9e4nW6/yObwB/4OFG3XxLgGGkXV7kMyXf4fu1VM0oPC1ehh+aqxdtWPegQMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3216
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/J90iB0vfpFgGSe9CFFznLJ0C_DQ>
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:27:11 -0000
Hi Dhruv, Thank you very much for your valuable suggestions. We will update the document accordingly. Details are inline below with prefix [HC2]. Best Regards, Huaimo ________________________________ From: Dhruv Dhody <dd@dhruvdhody.com> Sent: Wednesday, July 22, 2020 12:24 AM To: Alvaro Retana <aretana.ietf@gmail.com> Cc: Alvaro Retana via Datatracker <noreply@ietf.org>; The IESG <iesg@ietf.org>; pce-chairs <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) Hi Huaimo, Alvaro, <snip> > > > (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. > > I suggested making these changes in section 4.1 - In case of multiple PCEs within a single domain, the PCE would need to synchronize their scheduling information with other PCEs within the domain. This could be achieved by proprietary database synchronization techniques or via a possible PCEP extension [I-D.litkowski-pce-state-sync]. The technique used to synchronize SLSP-DB is out of scope for this document. Also, update section 4.3 with - o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP and synchronize the scheduling information with other PCEs in the domain. [HC2]: We will update the related text as you suggested. > > > §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? > In this case, the right reference is draft-litkowski-pce-state-sync to synchronize between PCEs using PCRpt/PCUpd. My suggestion would be to change the text in Section 6.1 (version -19) OLD: This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231] NEW: This message could also be used to synchronize the scheduled LSPs to other PCE as described in [I-D.litkowski-pce-state-sync]. END I can even live with removing the text completely. [HC2]: We will remove the text completely. BTW, just for information - PCE acting as PCC and using PCReq message towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE acting as PCC and sending PCRpt messages to parent PCE. But that has no bearing on the fate of the above text. [HC2]: Thanks much for the information. Thanks, Dhruv
- [Pce] Alvaro Retana's No Objection on draft-ietf-… Alvaro Retana via Datatracker
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Huaimo Chen
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Alvaro Retana
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Dhruv Dhody
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Alvaro Retana
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Huaimo Chen
- Re: [Pce] Alvaro Retana's No Objection on draft-i… Huaimo Chen