Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
"Zhangxian (Xian)" <zhang.xian@huawei.com> Wed, 23 October 2013 01:22 UTC
Return-Path: <zhang.xian@huawei.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 B1DD011E80F2 for <pce@ietfa.amsl.com>; Tue, 22 Oct 2013 18:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level:
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A8csPd2DFHB for <pce@ietfa.amsl.com>; Tue, 22 Oct 2013 18:22:48 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF411E80E6 for <pce@ietf.org>; Tue, 22 Oct 2013 18:22:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZI79908; Wed, 23 Oct 2013 01:22:46 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Oct 2013 02:22:45 +0100
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Oct 2013 02:22:44 +0100
Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.96]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 09:22:40 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, "draft-ietf-pce-stateful-pce@tools.ietf.org" <draft-ietf-pce-stateful-pce@tools.ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
Thread-Index: AQHOxLq4T5I4Ve4TpUGH/tbvTGOf/ZoATcCAgAFDA/A=
Date: Wed, 23 Oct 2013 01:22:40 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B263CA6FA@szxeml510-mbx.china.huawei.com>
References: <20131009064217.11449.53492.idtracker@ietfa.amsl.com> <CAB75xn4Z6YJZ=rr0Hixe-ZeSm3zVRUCsvRRSxF2SETQXAgNbag@mail.gmail.com>
In-Reply-To: <CAB75xn4Z6YJZ=rr0Hixe-ZeSm3zVRUCsvRRSxF2SETQXAgNbag@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B263CA6FAszxeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 23 Oct 2013 01:22:52 -0000
Hi, All, Just to amend the first comment below. In Section 2. 5 of http://tools.ietf.org/html/draft-zhang-pce-pcep-stateful-pce-gmpls-03, we discuss the use cases of why the LSP identifier is useful in existing messages (PCReq and PCRep) and provide encoding. Although we currently put in this draft, but IMHO, it should be generic. What is the WG opinion on this? Regards, Xian From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 2013年10月22日 21:58 To: draft-ietf-pce-stateful-pce@tools.ietf.org; pce@ietf.org Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt Hi Authors/WG, Some comments on draft-ietf-pce-stateful-pce-07. Apologies for a long mail. Major - I noticed that the PCReq/PCRep encoding are removed from this version, how should the passive stateful PCE behave now (with no LSP object). In section 5.6.1 when a passive stateful PCE sends PCRep message, PCC send PCRpt message to indicate is the path can be setup or not. There is a need to link the PCRep with PCRpt in case of passive stateful PCE. The LSP object added in PCReq/PCRep in the previous version could do this. I wish there is some discussion on the mailing list, so that the WG is aware of why the changes were made. - PCRpt/PCUpd Message: What is the way to know the source and destination of the LSP in the current encoding esp when the LSP is down or not yet setup? Also note that the ERO is a mandatory object in PCRpt. Should it be existing when the path calculation has not been initiated so far? ERO object is also mandatory in PCUpd. IMO PCE may choose to tear down an LSP (say during handling of a higher priority LSP), what should be in the ERO object then? IMHO ENDPOINT object in PCRpt/PCUpd will make for much cleaner design but "...an ERO with just the 'endpoints'" is also an option. Either way some text in the document should explain that. - PLSP-ID: it is constant for the life time of a PCEP session. IMO its a better idea to make PLSP-ID unique NOT per PCEP session but across PCEP session, i.e. if there are multiple stateful PCE and re-delegation happens (after the earlier delegated PCE is down), PLSP-ID will not change. IMO in case of PCE-Initiated LSP, it would allow a new stateful PCE to take control over the orphan LSP using the same PLSP-ID in a much simpler way. Minor - Abstract Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or ... Prefer if *synchronization* can be clarified, i.e. we explicitly say LSP state synchronization, so as not to be confused with TED sync. - Terminology State Timeout Interval: when a PCEP session is terminated, a PCC waits for this time period before flushing LSP state associated with that PCEP session and reverting to operator- defined default parameters. Can we change this to operator-defined default parameters or procedures? By procedure I meant that on state timeout interval expiry, PCC may rely on local CSPF computed path or ask a passive/stateless PCE to re-compute based on the operator- defined procedure. - Sec 3.1.3. Protocol vs. Configuration Security: opening up a configuration channel to a PCE would allow a malicious PCE to take over a PCC. Rest of the section compares the shortcoming of existing configuration tools/protocols with stateful PCE; But this point suggest opening up configurations of state directly at PCE. Am not so sure about it. - Sec 5.3. Capability Advertisement If PCE advertise its stateful capability during IGP discovery, do the PCC/PCE still need to follow the procedure laid out in this section. This should be clarified in the draft. If the PCEP Speakers support the extensions of this draft but did not advertise this capability, then a PCErr with error- type 19 (Invalid Operation), error-value 2 (Attempted LSP Update Request if active stateful PCE capability was not advertised)(see Section 8.4) will be generated and the PCEP session will be terminated. Also needed an error-value for attempting to send LSP State report if stateful PCE capability was not advertised. Basically a PCEP speaker which supports this extension but did not advertise it, PCC anyhow chooses to send PCRpt message then the another error value is needed. - Sec 5.4. State Synchronization The set of LSPs for which state is synchronized with a PCE is determined by advertised stateful PCEP capabilities and PCC's local configuration (see more details in Section 9.1). How is the capability advertisement related to decision which set of LSP are synchronized? IMO Capability advertisement determines if the state synchronization as a whole is performed or not, it doesn't determine a set (subset) of LSPs which are synchronized. A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. Some text can be added to suggest how should the PCC/PCE react if above happens? Error Message? Termination of PCEP session? A PCE implementing a limit on the resources a single PCC can occupy, MUST send a PCErr message with error-type 19 (invalid operation) and error-value 4 (indicating resource limit exceeded) in response to the PCRpt message triggering this condition in the synchronization phase and MUST terminate the session. By resource do you mean a limit on number of LSPs that a given PCC can synchronize? - Sec 6.1. The PCRpt Message <path>::= <ERO><attribute-list>[<RRO>] Please add some description on when RRO should be used. How it works along ERO etc? - Sec 7.2. SRP Object The SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt, PCNtf and PCErr messages. PCNtf? Well then the extension of PCNtf is needed to support carrying of SRP object. - Sec 7.3.2. Symbolic Path Name TLV The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object and the LSPA Object. What is the purpose of this TLV inside the LSPA object? (Also mentioned in section 7.4) Editorial - Terminology This document uses the following terms defined in [RFC4090]: MPLS TE Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. Should be removed as they are not used in the document anymore. Delegation OLD For intra-domain LSPs, this PCC SHOULD be the PCC of the LSP head end. NEW For intra-domain LSPs, this PCC SHOULD be the LSP head end. LSP State Report OLD an operation to send LSP state (Operational / Admin Status, LSP attributes configured and set by a PCE, etc.) from a PCC to a PCE. NEW an operation to send LSP state (Operational / Admin Status, LSP attributes configured at PCC and updated by a PCE, etc.) from a PCC to a PCE. - Sec 3.1.3. Protocol vs. Configuration OLD Efficient State Synchronization: configuration channels may be heavyweight and unidirectional, therefore efficient state synchronization between a PCE and a PCE may be a problem. NEW Efficient State Synchronization: configuration channels may be heavyweight and unidirectional, therefore efficient state synchronization between a PCC and a PCE may be a problem. - Sec 5.1. LSP State Ownership OLD An active stateful PCE may have control of a PCC's LSPs be delegated to it, but the LSP state ownership is retained by the PCC. NEW An active stateful PCE may have control of a PCC's LSPs that are delegated to it, but the LSP state ownership is retained by the PCC. - Sec 7.3. LSP Object The figure shows operational bits of 2 bit length, it should be three! Dhruv On Wed, Oct 9, 2013 at 12:12 PM, <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Author(s) : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename : draft-ietf-pce-stateful-pce-07.txt Pages : 47 Date : 2013-10-08 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce
- [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.… internet-drafts
- Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce… Margaria, Cyril (Coriant - DE/Munich)
- Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce… Zhangxian (Xian)
- Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce… Dhruv Dhody
- Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce… Ina Minei
- Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce… Cyril Margaria