Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11
Ina Minei <inaminei@google.com> Mon, 02 May 2016 16:02 UTC
Return-Path: <inaminei@google.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 4ADC512B04C for <pce@ietfa.amsl.com>; Mon, 2 May 2016 09:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level:
X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rwmmbQ7JlQx2 for <pce@ietfa.amsl.com>; Mon, 2 May 2016 09:02:55 -0700 (PDT)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0691B12D161 for <pce@ietf.org>; Mon, 2 May 2016 09:02:55 -0700 (PDT)
Received: by mail-qg0-x22b.google.com with SMTP id f74so71162378qge.2 for <pce@ietf.org>; Mon, 02 May 2016 09:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=F3ZnGuu01dQCPkBm9KnU2eaKOqKZohoXojAxsM9wfao=; b=DdlI1vP6LSueuiS5aud7yyZf64FZ27g3z5s9C41SrFHKLJDXF0bMGie6ky/+xi+9uX ZmMYlSP/2VK/1IX2eJ9rf8xUflCKFQ/1tHoIpXPeGeF96ukFLaeki8cso7T4QXx7JTq8 VJioQVByjY4dQk9/C12SV/mvJsyehM6zKxAiENUvvkq+ajts0TkVm4gdDonA1IB/ZxSn bhVyNDRMD7wSIo8Ww1BQxe7WzZp4VxsApQcwMQ5z82s4CLjVQQvfeOgdLn19erIK14Ck 0spEpcyGX1sbr6tJMBvsT/oKS8n8rSDu6rKTgatEzd5vhFlHcs8sd9tDdSm8uIGbg8D8 PvTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=F3ZnGuu01dQCPkBm9KnU2eaKOqKZohoXojAxsM9wfao=; b=Enl4jMtvksvsSRg9YtO5An40nbJNqBo/O0T9ITWEfVU/aF2LC8pJXv8BdpomQF/SNh BlTStEng/j0a+fE3j6NWMyKtXEl/EXRtMLQWh7mFR4zBJwI2i6n92Am/YyE/lifRfZ+S A0EtxpsdhD66DesB5pEpUEVzlBIyy0jmuJxjpf8AhJecIscvWKLuoNWW2jO5m+41Pg8B cIr2TtCn8A3EFiJLGUBbVwO7wankjMHc9WJekvEsf7fTy1UaduPHqfuwnMEw4JZM2szl jZosvlpbI9z4uVCBcdSBMK7RAeuSWMCU5TPTiuqyxUcepuoJb91GTqo7HQ5b6ladohCo qoKw==
X-Gm-Message-State: AOPr4FVaYBm8G6oI71yUDicnhVqafHaFqMq8mcNxCNJ86EvI/HEGtnDShH1zCMYJVY1+MnyIMvyMwb7cLRK+o1ev
MIME-Version: 1.0
X-Received: by 10.141.45.5 with SMTP id w5mr34399568qhe.1.1462204974041; Mon, 02 May 2016 09:02:54 -0700 (PDT)
Received: by 10.55.171.15 with HTTP; Mon, 2 May 2016 09:02:53 -0700 (PDT)
In-Reply-To: <56AFA415.2090504@hq.sk>
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>
Date: Mon, 02 May 2016 09:02:53 -0700
Message-ID: <CAG4Q_aueH3EhNhQhmTqkHH7q+EY0wd=gkjvwOei-sT3R-KXFMw@mail.gmail.com>
From: Ina Minei <inaminei@google.com>
To: Julien Meuric <julien.meuric@orange.com>
Content-Type: multipart/alternative; boundary="94eb2c115e721149b90531de2026"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/unXw3iGBtVMblCcAlqkJBlw3L04>
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: Mon, 02 May 2016 16:02:57 -0000
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> 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>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