Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-wson-rwa-ext-11: (with DISCUSS and COMMENT)

<julien.meuric@orange.com> Thu, 07 February 2019 13:57 UTC

Return-Path: <julien.meuric@orange.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 7C67A124BE5; Thu, 7 Feb 2019 05:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.433
X-Spam-Level:
X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
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 6OEve9KvtkrF; Thu, 7 Feb 2019 05:57:19 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF6C123FFD; Thu, 7 Feb 2019 05:57:19 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 43wKcs5LrYz10rk; Thu, 7 Feb 2019 14:57:17 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 43wKcs3gynzyQT; Thu, 7 Feb 2019 14:57:17 +0100 (CET)
Received: from [10.193.71.125] (10.168.234.6) by OPEXCLILM5F.corporate.adroot.infra.ftgroup (10.114.31.43) with Microsoft SMTP Server (TLS) id 14.3.435.0; Thu, 7 Feb 2019 14:57:17 +0100
To: Leeyoung <leeyoung@huawei.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-pce-wson-rwa-ext@ietf.org" <draft-ietf-pce-wson-rwa-ext@ietf.org>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
References: <154916511174.18400.15146609335810321774.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E173D0D3DF2@sjceml521-mbx.china.huawei.com>
From: julien.meuric@orange.com
Organization: Orange
Message-ID: <10526_1549547837_5C5C393D_10526_368_1_6414fe4a-547f-61c9-d7f5-2c05ff22e05e@orange.com>
Date: Thu, 07 Feb 2019 14:57:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E173D0D3DF2@sjceml521-mbx.china.huawei.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.168.234.6]
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/tc8DEoI7NjhYfxXe0luyI-Vvi7k>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-wson-rwa-ext-11: (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: Thu, 07 Feb 2019 13:57:21 -0000

Hi Benjamin, hi Young,

Sorry for jumping onto the discussion, but it seems to me that there are 2 slightly different issues tackled below:

1- scoping the wavelength restriction:
    * Young's response below remains true from a generic signaling stand point,
    * I would had that the WDM data plane we are controlling in this context implies a label continuity between hops by default, unless the node has an additional hardware capability (i.e. termination/regeneration) it can control; as a result, a restriction scoped to the PCC from the generic protocol's perspective implicitly means "restriction till the other end of the wavelength (several hops downstream)" in our technology-specific context [side note: facing these multi-hops constraints is part of the use cases for the PCE architecture];

2- the "Identifier" field, inherited from RFC 6205: my reading of the definition brings us in the prescriptive/ERO use case, where 0 leaves freedom and non-zero relies on a "MUST"; the latter puzzles me for 2 reasons:
    * from a PCE implementer's perspective, we end up with a mandatory field whose actual use is fuzzy (maybe Daniele could help us with his CCAMP chair hat),
    * an implementation needing to report an error related to a blocking issue with that field has no clear specification to follow (a well define error behavior may be required).
An easy way to address both concerns may be to temper the language from RFC 6205 when the field is used in a PCEP context.

Thanks,

Julien


On 07/02/2019 02:27, Leeyoung wrote:

Section 4.3.2

 

RFC 6205 says that the "Identifier" is a per-node assigned and scoped value that may change on a per-hop basis.  I don't see where our base label gets scoped to a node (just that it's part of a PCReq message which does not seem scoped to a node), so this seems problematic.

 

YL>> RFC 6205 is written from the perspective of GMPLS signaling which is on a per-hop basis. Here we are using the same encoding, but from the PCEP perspective. In the PCEP, PCC is the head-end node and the head-end node would apply the wavelength restriction to its out-going interfaces. If the restriction applies to globally, then GMPLS signaling will carry this information to sub-sequent nodes. If the restriction locally applies, then PCE-CC mechanism (PCE talks to each node) would allow the restriction to be applied to each node.  This draft was written the restriction would be applied globally (as a mechanism for limiting the tunable range of wavelength globally so that the head-end node can propagate this restriction to other node (via GMPLS signaling mechanism). 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.