Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11
Julien Meuric <julien.meuric@orange.com> Tue, 03 May 2016 10:33 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 B9BA612D723; Tue, 3 May 2016 03:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] autolearn=ham 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 qqiMmOHoGHq7; Tue, 3 May 2016 03:33:19 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id D94C012D71E; Tue, 3 May 2016 03:33:18 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB87AE30080; Tue, 3 May 2016 12:33:17 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 8E5C1E3007F; Tue, 3 May 2016 12:33:17 +0200 (CEST)
Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Tue, 3 May 2016 12:33:17 +0200
To: Ina Minei <inaminei@google.com>
References: <56210C68.1080904@orange.com> <CAG4Q_avL_vVpmzyTfk4uGbdKYhvYVr_74KfaX-5iCGm7Vf+xVA@mail.gmail.com> <569CFA97.2080209@hq.sk> <56AF5F41.9000903@orange.com> <56AFA415.2090504@hq.sk> <CAG4Q_aueH3EhNhQhmTqkHH7q+EY0wd=gkjvwOei-sT3R-KXFMw@mail.gmail.com>
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <57287E6D.2050505@orange.com>
Date: Tue, 03 May 2016 12:33:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAG4Q_aueH3EhNhQhmTqkHH7q+EY0wd=gkjvwOei-sT3R-KXFMw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/Jisn-xCx1en28kQAEOygu71RUNw>
Cc: draft-ietf-pce-stateful-pce@ietf.org, "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 03 May 2016 10:33:22 -0000
Hi Ina, The status is the following: - There used to be a couple of mismatches between Robert's comments and the wording of the I-D: if he is fine with the latest update, we are good; - A parallel thread about stateless PCE has grown up to tackle an issue to be addressed as a comment on this I-D: it is now useful to have the authors joining that part of the discussion to reach a consensus on the resolution (https://mailarchive.ietf.org/arch/msg/pce/_ih3NcDK2_iy8xSHcquzm-q_2bs); - With PCEPS I-D getting close to IANA, Jon refreshed the codepoint early allocation proposal not so long ago (https://mailarchive.ietf.org/arch/msg/pce/Jg2f8AGa9ZpVZup13YWzTHwkUD8): a feedback of stateful I-Ds' authors on that action would be welcome. Thank you, Julien May. 02, 2016 - inaminei@google.com: > Julien, > > Not sure where this draft stands now after the latest revisions which > were posted more than a month ago. Is there anything else needed from > the authors? > > Thank you, > > Ina > > On Mon, Feb 1, 2016 at 10:29 AM, Robert Varga <nite@hq.sk > <mailto:nite@hq.sk>> wrote: > > On 02/01/2016 02:36 PM, Julien Meuric wrote: >> Hi Robert. >> > > Hello Julien, > >> Thank you for your help to move this forward. Please find my >> comments below [JM]. Note that a couple of your answers are not >> aligned with the proposed resolutions currently included the I-D: >> I was fine with these, therefore please make sure you are so that >> I can send to the IESG. >> > > please see inline, I am pruning the items we have converged on... > >> Julien >> >> >> Jan. 18, 2016 - nite@hq.sk <mailto:nite@hq.sk>: > [snip] >>>> >>>> - Avoiding "positive acknowledgements for properly received >>>> synchronization messages" has scalability benefits in >>>> normal situations, but the PCC is blind and may keep on >>>> sending PCRpt to dead processes behind up PCEP sessions. >>>> Have you consider acknowledgement, possibly using a >>>> compression mechanism like the one defined later in the I-D? >>>> >>>> ### XXX Pending >>> >>> The association between a PCEP session and PCE processes is >>> something which I would consider an internal PCE detail, and it >>> should be covered by the next sentence (e.g. raise PCErr 20/1). >> [JM] I still feel unwise to consider a lack of feedback as a >> proof of synchronization. What if, from time to time, a PCRpt >> gets lost? I do not think acknowledgement would be a pain to add, >> but its lack can easily turn to that in operational situations. > > The assumption here is that PCEP runs on top of TCP, so no PCRpts > get lost on the network without also losing the session. The > procedures for validating that the session is in fact synchronized > (possibly on a periodic basis) are part of > draft-ietf-pce-stateful-sync-optimizations. I think we can add > some text around that. > >>>> - In section 5.5.1, it is not clear if an empty LSP Update >>>> Request with a Delegate flag to 1 is an acceptable way for >>>> a PCE to send a delegation acknowledgement: to be clarified. >>>> >>>> ### XXX Pending >>> >>> It is not, as that would be seen as a request to modify the LSP >>> setup to empty. Such an acknowledgement would have to include >>> full configuration as previously reported -- which would be >>> handled as a normal update. >> [JM] The I-Ds says the contrary: to be checked. Note that empty >> could be loose, which seems possible to handle at the signaling >> level. > > I think this is clarified in -13 (section 5.7). > >> >>>> - The behavior associated to the resource limit per PCC >>>> rather looks like a Notifcation than an Error (e.g., in RFC >>>> 5440, cancelling a set of pending requests relies on >>>> PCNtf). Please consider the use of Notification instead of >>>> Error here. >>>> >>>> ### XXX Pending >>> >>> Current wording is based on the assumption that the PCE has to >>> have a consistent point-in-time view of the PCC's state. In this >>> regard a PCRpt of a new LSP which exceeds PCE >>> implementation-internal limit on the number of LSPs it supports >>> would break that assumption, hence we chose PCErr. This makes it >>> consistent with what would happen if that LSP is reported during >>> initial state resynchronization. >> [JM] Please note that the current I-D uses "PCNtf", and I am fine >> with that resolution. I was not questioning the expected >> behavior, which must remain. I was just suggesting the expected >> type of message to be consistent with RFC 5440: the PCC has not >> made anything wrong, it is informed that the PCE no more accepts >> its reports similarly to the way a PCE is able to tell about >> overload or cancel some requests. > > I'll try to re-read the entire thing and report back. > >> >>>> - It would be nice to elaborate on the reason why the >>>> SYMBOLIC-PATH-NAME MUST be included and not SHOULD. >>>> - I do not see why SYMBOLIC-PATH-NAME may be included in >>>> SRP Object: defining the LSP Object as its single place >>>> seems enough and much simpler. >>>> >>>> >>>> ### XXX Pending >>> >>> The MUST is there to maintain a single global identifier for the >>> LSP. PLSP-ID is then used as a shorthand. I do not recollect the >>> exact reasoning as to why the TLV can be in SRP, as the >>> placement and semantics of that TLV has changed quite a bit over >>> the past couple of years. If I were to venture a guess, I think >>> it was retrofitted to allow the PCE to update the symbolic path >>> name. >> [JM] OK about the "MUST". About SYMBOLIC-PATH-NAME in SRP, please >> choose: either it is legacy and must be dropped (current >> version), or there is a reason and it must be documented in the I-D. > > It was introduced in -05 revision with the SRP object. We'll dig > in history some more to see where this came from. > > Bye, > Robert > >
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Robert Varga
- [Pce] Chair's Review of draft-ietf-pce-stateful-p… Julien Meuric
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Ina Minei
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Julien Meuric
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Ina Minei
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Ina Minei
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Julien Meuric
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Robert Varga
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Julien Meuric
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Jan Medved (jmedved)
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Robert Varga
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Ina Minei
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Ina Minei
- Re: [Pce] Chair's Review of draft-ietf-pce-statef… Julien Meuric