From nobody Wed Dec 2 17:54:00 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F51B2B57; Wed, 2 Dec 2015 17:53:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203015357.7031.78765.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 17:53:57 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-13.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 01:53:57 -0000 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 Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Filename : draft-ietf-pce-stateful-pce-13.txt Pages : 51 Date : 2015-12-02 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 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: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 3 01:25:13 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E67701AC3DB; Wed, 2 Dec 2015 09:22:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151202172210.11479.53532.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 09:22:10 -0800 Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 01:25:12 -0800 Cc: Common Control and Measurement Plane Discussion List , JP Vasseur , Traffic Engineering Architecture and Signaling Discussion List , Vishnu Pavan Beeram , Path Computation Element Discussion List , David Sinicrope , Alvaro Retana Subject: [Pce] New Liaison Statement, "In Response to Broadband Forum Liaison: Achieving Packet Network Optimization using DWDM Interfaces" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:22:11 -0000 Title: In Response to Broadband Forum Liaison: Achieving Packet Network Optimization using DWDM Interfaces Submission Date: 2015-12-02 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1445/ From: "Daniele Ceccarelli" To: daniele.ceccarelli@ericsson.com Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,David Sinicrope ,Jonathan Hardwick ,Fatai Zhang ,Path Computation Element Discussion List ,Traffic Engineering Architecture and Signaling Discussion List ,Vishnu Pavan Beeram ,Alia Atlas ,Daniele Ceccarelli ,Lou Berger ,Common Control and Measurement Plane Discussion List ,JP Vasseur , Response Contacts: Vishnu Pavan Beeram , Lou Berger ,Jonathan Hardwick ,JP Vasseur ,Julien Meuric ,Fatai Zhang Technical Contacts: Purpose: In response Referenced liaison: Achieving Packet Network Optimization using DWDM Interfaces (https://datatracker.ietf.org/liaison/1432/) Body: Hello, The TEAS, PCE and CCAMP Working Groups would like to thank the Broadband Forum for informing us of your effort on packet-optical networks, and providing the IETF with the opportunity to review and comment on your document and its use of our RFCs. We have conducted an initial review where we noted the references to IETF RFCs on GMPLS and PCE for satisfying the control requirements. Below is some preliminary feedback based on this initial review we hope you will find helpful and consider for the document. However, given the recent IETF 94 meeting activity, we regret there was little time to conduct a thorough technical review of the document. We understand the document is in the last call stage of development. If time and the BBF process allows, the CCAMP, PCE and TEAS Working Groups would be happy to conduct a more in depth technical review over the coming weeks. Please let us know if you wish us to proceed with such a review. As the Broadband Forum progresses its work on "Achieving Packet Network Optimization using DWDM Interfaces", we would greatly appreciate if you keep us informed of any gaps you identify in the RFCs that are needed to satisfy these requirements. Feedback from the BBF on existing and progressing CCAMP, PCE and TEAS work would be greatly appreciated and can be provided via the relevant IETF Working Group mailing list without the need for a formal liaison. We look forward to your response and our continued communication on this important area of optical networking. Best Regards, Daniele Ceccarelli & Fatai Zhang - CCAMP Working Group Chairs Jonathan Hardwick, Julien Meuric & Jean-Philippe Vasseur - PCE Working Group Chairs Vishnu Pavan Beeram & Lou Berger - TEAS Working Group Chairs --------------------------- Preliminary Feedback --------------------------- Questions: * In A.2.1, how is the GMPLS communication between the Packet Node and the DWDM Network Element achieved? Is there a specific control interface that is used in your solution? There are a number of possibilities for control channel connectivity available. Perhaps clarifying which are intended would aid understanding and interoperability. * Are there more details on the management and SDN control aspects between the packet network and the optical network? Additional management and SDN control detail might convey a better understanding of the solution configuration and its operation. Comments: * When referring to PCE and related issues, e.g., in [R-26] and [R-27], it seems only stateless PCE (RFC4655) and corresponding PCEP (RFC5440) are included in the current solution. The PCE Working Group is investigating stateful PCE and PCE Initiated LSPs, which are planned to be published in the future. It may be worth specifying which kind of PCE is suggested to be used in the current solution, to differentiate the two. Has RFC 5623 - PCE-based inter-layer MPLS and GMPLS Traffic Engineering been considered? It may be a good reference for this solution. * In section 4.4 when talking about SDN, Openflow is mentioned as a standard protocol to interact between packet nodes and DWDM nodes. PCE Protocol (PCEP) could be considered as another example, as it is currently used in IETF. RFC 3413 about SNMP, and RFC 4208 about GMPLS UNI are also recommended references. * In section 4.5, [R-36] uses the term "North-Bound interface" to refer to the interface between Network Elements and the SDN controller. We noted that some commonly use the same term when referring to the interface between the controller and what sits "above" the controller (e.g. another controller or orchestrator). This could lead to unintended misunderstanding. Perhaps a clarification would help avoid misunderstanding. Attachments: No document has been attached From nobody Thu Dec 3 09:10:13 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BEA1AC3CB for ; Thu, 3 Dec 2015 09:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 E3xzccm7qd97 for ; Thu, 3 Dec 2015 09:10:02 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 6A3091A92E3 for ; Thu, 3 Dec 2015 09:10:02 -0800 (PST) Received: by ykdr82 with SMTP id r82so93083836ykd.3 for ; Thu, 03 Dec 2015 09:10:01 -0800 (PST) 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:content-type; bh=gpFQvfNnb+kDLs1Y1GE/xKp07Iw1H5MWr8VCtH31URM=; b=lKmrVgsglcdOHW4NvgFXPLOIyuVTE/0U12mi2dM18NKCUkawbHPsUD5B1iDqWjmELs X77MyH6fWmXNdSBY9Fpq95PhVKT0ewbyjPvbQRVfzfl5N8r8s7Dcqcvjyxi0QAUWrR6v Gnkt9pDTzqo7r49zbFXStSlGwkaWnxb/DX5YNRAWQg5+bWMPDgKh6fPqnyEUqR4zlBgv yNqf8KTNY7ecs6s5DSBoS12eF2CQ7zmxl+ixjg9sirhO7f+S+A6YyoRHY7YdILFAfL+7 OzQvmVxZ1fn1NPyBiZBw2uh38AE6Nw3ls3LSlG99FF9g0mt+pIBaankyLrUuLZyEoaNX lFug== 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:content-type; bh=gpFQvfNnb+kDLs1Y1GE/xKp07Iw1H5MWr8VCtH31URM=; b=kHdbHN956uqY1EdGH4rsgArgQBP+KxFrgYNg9Y1nlUYT0qzhr3xpcLK3Q4IvvMMP5h CZi1kUlQSFb2DWkbsNNnvZD/NIM3we4dvOVZnhOfoSzCQOoE8YdmxI0CXS8CkHY5lxgS +g6jdQaG62YomaeOmc8nC9MWfLyQSOqFX/UJyYO6NzbJqlV09B+2nSnmyO8BCIf9o0Ef Zm3hZd5sZ8hdgsN9mfqODgM6kvvF86GmRsj0ab09eXxsHkQcnyQwhb+9JmXAoPoqV/4w 4PiMIcBgvk7aeCq7eApdbcc4YXQQ8b14jiJXfm53tE+VdoBbVzabY6c8y/PLyPa+8se2 3VGQ== X-Gm-Message-State: ALoCoQl64E721V6sB+8y+cmfA4r9iBF4s80buZryT4DfeqIuCEmdUZwvybK53aCPNaboLX7PiD8a MIME-Version: 1.0 X-Received: by 10.129.78.7 with SMTP id c7mr8469833ywb.210.1449162601448; Thu, 03 Dec 2015 09:10:01 -0800 (PST) Received: by 10.37.119.197 with HTTP; Thu, 3 Dec 2015 09:10:01 -0800 (PST) In-Reply-To: References: <56210C68.1080904@orange.com> <56422DF8.6030403@orange.com> Date: Thu, 3 Dec 2015 09:10:01 -0800 Message-ID: From: Ina Minei To: Julien Meuric Content-Type: multipart/alternative; boundary=001a114dacbc154d4505260176d3 Archived-At: Cc: draft-ietf-pce-stateful-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.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 17:10:06 -0000 --001a114dacbc154d4505260176d3 Content-Type: text/plain; charset=UTF-8 All the changes discussed in this thread have been incorporated in version 13 published yesterday https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13 Thank you, Ina On Sun, Nov 29, 2015 at 1:21 PM, Ina Minei wrote: > Thanks a lot for the very useful discussions and for the continued review. > Please see inline %%%, a new version of the draft will be published next > week, > > Ina > > On Tue, Nov 10, 2015 at 9:48 AM, Julien Meuric > wrote: > > [snip] > >> Two questions and one ask >>> 1. Forward references to SRP object and SRP-ID - there are several in >>> the comments, though the relevant section is always mentioned. How should >>> such forward references be addressed? >>> >> [JM] A simple way is to add the acronym and its expansion into the >> terminology section, and optionally the forward reference. >> >> %%% Done > > >> 2. Section 7 - s/defined in this document/defined in that >>> (aforementioned) document/ >>> The comment was not clear to me. The intention is for the flags to be >>> set as explained for the new objects we are defining here, can you clarify >>> the comment? >>> >> [JM] Just suggesting a rewording, but my proposal was not clear either; >> "this current I-D" may be enough to clear the ambiguity. > > %%% Done > > [snip] > > >> - s/Active Stateful PCE: is an extension/Active Stateful PCE: an >>> extension/ >>> >>> ### Replaced as "an Active Stateful PCE that may issue >>> recommendations... >>> >>> [JM] Guessing you actually meant "a Stateful PCE that may...", it is OK. >> > %%% Yes :-) > > [snip] > >> >>> >>> >>> >>> - OLD >>> 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 or behaviors. >>> NEW >>> State Timeout Interval: the period of time a PCE waits for, when a >>> PCEP session is terminated, before flushing LSP state associated >>> with that PCEP session and reverting to operator-defined default >>> parameters or behaviors. >>> >>> ### Done >>> >> [JM] I hope you caught my (double) typo: I was only trying to rephrase, >> the waiting party remaining the PCC. >> >> %%% I did now :-), fixed. > > [snip] > >> >> >> >>> >>> - The reference to draft-sivabalan-pce-disco-stateful makes the >>> reader wonder why is is not part of draft-ietf-pce-stateful-pce >>> itself. Besides, Table 1 also mentions IS-IS and OSPF >>> PCE-CAP-FLAGS sub-TLV, only the allocation section seems to be >>> missing here. Would you talk to the authors (some being common to >>> both I-Ds) of the former to consider using their material as a >>> contribution? A separate document is quite an overhead for >>> allocating 2 bits. >>> >>> >>> ### I don't think discovery should be part of the base draft. Several >>> reasons: a) 5440 does not include discovery, b) the base spec is already >>> quite large, we want to keep only the core function and c) the discovery >>> draft is expired. I cleaned up table 1 and added the following text instead >>> of the reference to the draft: >>> Old text >>> [I-D.sivabalan-pce-disco-stateful] defines the extensions needed >>> tosupport autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or >>> IS-IS ([RFC5089]) for PCE discovery. >>> New text >>> Similarly to [RFC5440], no assumption is made about the discovery method >>> used by a PCC to discover a set of PCEs (e.g., via static configuration or >>> dynamic discovery) and on the algorithm used to select a PCE. Extensions >>> needed to support autodiscovery will be defined in a separate document. >>> >> [JM] Along with RFC 5557 and 6006, including discovery bit allocation >> with PCEP extensions in a single document would save much administrative >> processing. >> >> %%% Done > > >> >> >>> >>> - s/include an empty ERO/include an empty RRO/ [Along with RFC >>> 5440 (section 7.10), the object sent by a PCC to report to a PCE >>> is an RRO: let us keep it consistent.] >>> >>> ### XXX Pending >>> >> [JM] As discussed, clarifying that you encode the "intended path" using >> ERO (class 7) and "actual path" using RRO (class 8) will address my >> comments related to xROs. >> >> %%% Done > > >> >> >>> >>> - 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 >>> >> %%% No, we did not think we needed positive acks because we are using a > TCP session (guaranteed delivery all the way to the PCE). > > >>> - When mentioning errors, adding a sentence reminding that RFC >>> 5440 already defines a set of applicable error codes would be >>> valuable. >>> >>> ### XXX Pending >>> >> %%% Done see text below: > "Error reporting is done using the procedures defined in [RFC5440], and > reusing the applicable error types and error values of [RFC5440] wherever > appropriate. The current document defines new error values for several > error types to cover failures specific to stateful PCE." >> >> >>> >> >>> >>> - 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 >>> >> %%% Yes, it is allowed, modified the text to clarify. > > >> >> >>> >>> - s/SHOULD return the LSP delegation/MUST return the LSP delegation/ >>> >>> ### This should remain SHOULD. The nice way to do it is to return it >>> explicitly, but it may choose to wait until the next update and return the >>> delegation then by not setting the delegate flag. >>> >> [JM] As discussed together, I can live with that. >> >> - In section 5.5.3, assuming an LSP was delegated, does the >>> reception by the PCC of a non empty LSP Update Request with a >>> Delegate Flag to 0 trigger an error? >>> >>> ### XXX Pending >>> >> %%% No, this is a delegation return. I cleaned up the text, see below. > > In order to keep a delegation, a PCE MUST set the Delegate flag to 1 > on each LSP Update Request sent to the PCC. A PCE that no longer > wishes to update an LSP's parameters SHOULD return the LSP delegation > back to the PCC by sending an empty LSP Update Request which has the > Delegate flag set to 0. If a PCC receives a non-empty LSP Update > Request with the Delegate flag set to 0, it MUST treat this as a > delegation return. > > > >> >> >>> >>> - At the top of page 18, "and [assuming that] PCEs' decisions are >>> the same" should be added. >>> >>> ### The comment is not clear - I am assuming you refer to the text >>> "assuming that the state timeout... ' on page 17, changed to: " and >>> assuming that the primary and redundant PCEs take similar decisions, this" >>> >> [JM] You got my point. :-) >> >> >> >>> >>> - In section 5.6.2, in case of new LSP, the very first message >>> sent by the PCC aims at getting a path. This is clearly the role >>> of a PCReq message, and the I-D extends it to support the LSP >>> object including the delegation flag (section 7.3). However, >>> Figure 8 treats a new LSP the same way as reporting an existing >>> LSP, i.e., using a PCRpt message. In this case, there is an >>> overlap between PCReq and PCRpt, which MUST be resolved because >>> interoperability is at stake. Documenting the delegation of a new >>> LSP deserves some new text and possibly figure, the overlapping >>> specification of the PCRpt should be explicitly precluded. >>> >>> ### This is historical confusion in the figure, from the time when >>> initiation was rolled up in the same document. I modified the figure so it >>> is clear this is for updating parameters only. >>> >> [JM] Seems addressed. Just to be confirmed when published and to >> confront with draft-ietf-pce-pce-initiated-lsp. >> >> >> >>> >>> - s/// [Per RFC 5440, a >>> report from PCC to PCE is RRO.] >>> >>> ### XXX Pending >>> >> [JM] As above. > > %%% Done > >> >> >> - The need for the optional xRO is not well documented. Its proper >>> naming will depend on the associated use that must be clarified. >>> - "SRP" is still not defined. >>> >>> ### Isn't it enough to reference the section in which it is defined? >>> >> [JM] Once added in terminology section, all these are solved. >> >> %%% Done > > >> >> >>> >>> - The use of the optional xRO is mentioned, but its relationship >>> with the RRO (formerly ERO) is not clear. I suspect some >>> assumptions are made on the way the ERO/RRO are populated; RFC >>> 5440 only says ERO for PCE->PCC and RRO for PCC->PCE. >>> >>> ### XXX Pending >>> >> [JM] As above. >> >> %%% Done > >> >> >>> >>> - 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 >>> >> [JM] To be updated. >> %%% Done >> > > >> >> >>> >>> - s/defined in this document/defined in that (aforementioned) >>> document/ >>> >>> ### Unclear comment, the intention was for the flags to be set as >>> explained for the new objects in this document, not for anything in 5440. >>> >> [JM] As above: adding "current" may be enough. >> %%% Done > > > >> >> >>> >>> - s/on a PCRpt message/On a PCRpt or PCReq message/ >>> >>> ### We don't support delegation through a PCReq message >>> >> [JM] Addressed as part of the resolution of the new path delegation. >> >> >> >>> >>> - "PCE SHOULD remove all state" is written 3 times: I wonder about >>> "MUST". >>> >>> ### SHOULD is the correct operation, the PCE is free to choose to keep >>> state around for as long as it wishes. The 3 removal statements refer to >>> different scenarios. >>> >> [JM] I can live with that. >> >> >> >>> >>> - 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 inclusion in SRP was a historical leftover and is removed. > Regarding why it MUST be included in the LSP object is described in the > draft in section 7.3.2. It is a stable (across PCEP session, PCC restart, > ..etc), signaling protocol agnostic, and unique Identifier that identifies > the LSP during its lifetime. > > >> >> >>> - As mentioned above, in Error-Type 19, Error-value 4 should be >>> considered in a PCNtf. >>> ### XXX Pending >>> >> > > %%% Done > >> >> >>> - Again in section 10.4, the "resource limit exceed" information >>> (Error-value 4 of Error-Type 19) should be considered in a PCNtf. >>> >>> ### XXX Pending >>> >> >> > %%% Done > > --001a114dacbc154d4505260176d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All the changes discussed in this thread have been incorpo= rated in version 13 published yesterday

<= /div>
Thank you,=C2=A0

Ina=C2=A0

On Sun, Nov 29, 201= 5 at 1:21 PM, Ina Minei <inaminei@google.com> wrote:
Thanks a lot for the very use= ful discussions and for the continued review. Please see inline %%%, a new = version of the draft will be published next week,=C2=A0

= Ina=C2=A0

On T= ue, Nov 10, 2015 at 9:48 AM, Julien Meuric <julien.meuric@orange.co= m> wrote:

[snip]
Two questions and one ask
1. Forward references to SRP object and SRP-ID - there are several in the c= omments, though the relevant section is always mentioned. How should such f= orward references be addressed?
 [JM] A simple way is to add the acronym and its expansion into the terminol= ogy section, and optionally the forward reference.

%%% Done =C2=A0
<= div>=C2=A0
2. Section 7 - s/defined in this document/defined in that (aforementioned) = document/
The comment was not clear to me. The intention is for the flags to be set a= s explained for the new objects we are defining here, can you clarify the c= omment?
 [JM] Just suggesting a rewording, but my proposal was not clear either; &qu= ot;this current I-D" may be enough to clear the ambiguity.
%%% Done =C2=A0

[snip]
=C2=A0
=C2=A0 =C2=A0 - s/Active Stateful PCE: is an extension/Active Stateful PCE:= an
=C2=A0 =C2=A0 extension/

=C2=A0### Replaced as "an Active Stateful PCE that may issue recommend= ations...

 [JM] Guessing you actually meant "a Stateful PCE that may...", it= is OK.
%%% Yes :-)=C2=A0

<= div>[snip]




=C2=A0 =C2=A0 - OLD
=C2=A0 =C2=A0 State Timeout Interval: when a PCEP session is terminated, a = PCC
=C2=A0 =C2=A0 waits for this time period before flushing LSP state associat= ed
=C2=A0 =C2=A0 with that PCEP session and reverting to operator-defined defa= ult
=C2=A0 =C2=A0 parameters or behaviors.
=C2=A0 =C2=A0 =C2=A0 NEW
=C2=A0 =C2=A0 State Timeout Interval: the period of time a PCE waits for, w= hen a
=C2=A0 =C2=A0 PCEP session is terminated, before flushing LSP state associa= ted
=C2=A0 =C2=A0 with that PCEP session and reverting to operator-defined defa= ult
=C2=A0 =C2=A0 parameters or behaviors.

### Done
 [JM] I hope you caught my (double) typo: I was only trying to rephrase, the= waiting party remaining the PCC.

%%% I did= now :-), fixed.=C2=A0
=C2=A0
[snip]

<snip>

=C2=A0 =C2=A0 - The reference to draft-sivabalan-pce-disco-stateful makes t= he
=C2=A0 =C2=A0 reader wonder why is is not part of draft-ietf-pce-stateful-p= ce
=C2=A0 =C2=A0 itself. Besides, Table 1 also mentions IS-IS and OSPF
=C2=A0 =C2=A0 PCE-CAP-FLAGS sub-TLV, only the allocation section seems to b= e
=C2=A0 =C2=A0 missing here. Would you talk to the authors (some being commo= n to
=C2=A0 =C2=A0 both I-Ds) of the former to consider using their material as = a
=C2=A0 =C2=A0 contribution? A separate document is quite an overhead for =C2=A0 =C2=A0 allocating 2 bits.


### I don't think discovery should be part of the base draft. Several r= easons: a) 5440 does not include discovery, b) the base spec is already qui= te large, we want to keep only the core function and=C2=A0 c) the discovery= draft is expired. I cleaned up table 1 and added the following text instea= d of the reference to the draft:
Old text
 [I-D.sivabalan-pce-disco-stateful] defines the extensions needed tosupport = autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or IS-IS ([RFC50= 89]) for PCE discovery.
New text
Similarly to [RFC5440], no assumption is made about the discovery method us= ed by a PCC to discover a set of PCEs (e.g., via static configuration or dy= namic discovery) and on the algorithm used to select a PCE. Extensions need= ed to support autodiscovery will be defined in a separate document.
[JM] Along with RFC 5557 and 6006, including discovery bit allocation with = PCEP extensions in a single document would save much administrative process= ing.

%%% Done=C2=A0
=C2= =A0
<snip>

=C2=A0 =C2=A0 - s/include an empty ERO/include an empty RRO/ [Along with RF= C
=C2=A0 =C2=A0 5440 (section 7.10), the object sent by a PCC to report to a = PCE
=C2=A0 =C2=A0 is an RRO: let us keep it consistent.]

### XXX Pending
 [JM] As discussed, clarifying that you encode the "intended path"= using ERO (class 7) and "actual path" using RRO (class 8) will a= ddress my comments related to xROs.

%%% Done=C2=A0
=C2= =A0
<snip>

=C2=A0 =C2=A0 - Avoiding "positive acknowledgements for properly recei= ved
=C2=A0 =C2=A0 synchronization messages" has scalability benefits in no= rmal
=C2=A0 =C2=A0 situations, but the PCC is blind and may keep on sending PCRp= t to
=C2=A0 =C2=A0 dead processes behind up PCEP sessions. Have you consider
=C2=A0 =C2=A0 acknowledgement, possibly using a compression mechanism like = the
=C2=A0 =C2=A0 one defined later in the I-D?

### XXX Pending
%%% =C2=A0N= o, we=C2=A0did not think we needed positive acks because we are using a= TCP session (guaranteed delivery all the way to the PCE).=C2=A0


=C2=A0 =C2=A0 - When mentioning errors, adding a sentence reminding that RF= C
=C2=A0 =C2=A0 5440 already defines a set of applicable error codes would be=
=C2=A0 =C2=A0 valuable.

### XXX Pending
%%% Done se= e text below:
"Error reporting is done using the procedures defin= ed in [RFC5440], and reusing the applicable error types and error values of= [RFC5440] wherever appropriate. The current document defines new error val= ues =C2=A0for several error types to cover failures specific to stateful PC= E."

 <snip>

=C2=A0 =C2=A0 - In section 5.5.1, it is not clear if an empty LSP Update Re= quest
=C2=A0 =C2=A0 with a Delegate flag to 1 is an acceptable way for a PCE to s= end a
=C2=A0 =C2=A0 delegation acknowledgement: to be clarified.

### XXX Pending
%%% Yes, it= is allowed, modified the text to clarify.=C2=A0
=C2=A0
 <snip>

=C2=A0 =C2=A0 - s/SHOULD return the LSP delegation/MUST return the LSP dele= gation/

### This should remain SHOULD. The nice way to do it is to return it explic= itly, but it may choose to wait until the next update and return the delega= tion then by not setting the delegate flag.
 [JM] As discussed together, I can live with that.

=C2=A0 =C2=A0 - In section 5.5.3, assuming an LSP was delegated, does the =C2=A0 =C2=A0 reception by the PCC of a non empty LSP Update Request with a=
=C2=A0 =C2=A0 Delegate Flag to 0 trigger an error?

### XXX Pending
%%% No, thi= s is a delegation return. I cleaned up the text, see below.
In order to=
 keep a delegation, a PCE MUST set the Delegate flag to 1
   on each LSP Update Request sent to the PCC.  A PCE that no longer
   wishes to update an LSP's parameters SHOULD return the LSP delegatio=
n
   back to the PCC by sending an empty LSP Update Request which has the
   Delegate flag set to 0.  If a PCC receives a non-empty LSP Update
   Request with the Delegate flag set to 0, it MUST treat this as a
   delegation return.
=C2=A0
 <snip>

=C2=A0 =C2=A0 - At the top of page 18, "and [assuming that] PCEs' = decisions are
=C2=A0 =C2=A0 the same" should be added.

### The comment is not clear - I am assuming you refer to the text "as= suming that the state timeout... ' on page 17, changed to: " and a= ssuming that the primary and redundant PCEs take similar decisions, this&qu= ot;
 =C2=A0[JM] You got my point. :-)

<snip>

=C2=A0 =C2=A0 - In section 5.6.2, in case of new LSP, the very first messag= e
=C2=A0 =C2=A0 sent by the PCC aims at getting a path. This is clearly the r= ole
=C2=A0 =C2=A0 of a PCReq message, and the I-D extends it to support the LSP=
=C2=A0 =C2=A0 object including the delegation flag (section 7.3). However,<= br> =C2=A0 =C2=A0 Figure 8 treats a new LSP the same way as reporting an existi= ng
=C2=A0 =C2=A0 LSP, i.e., using a PCRpt message. In this case, there is an =C2=A0 =C2=A0 overlap between PCReq and PCRpt, which MUST be resolved becau= se
=C2=A0 =C2=A0 interoperability is at stake. Documenting the delegation of a= new
=C2=A0 =C2=A0 LSP deserves some new text and possibly figure, the overlappi= ng
=C2=A0 =C2=A0 specification of the PCRpt should be explicitly precluded.
### This is historical confusion in the figure, from the time when initiati= on was rolled up in the same document. I modified the figure so it is clear= this is for updating parameters only.
 =C2=A0[JM] Seems addressed. Just to be confirmed when published and to conf= ront with draft-ietf-pce-pce-initiated-lsp.

<snip>

=C2=A0 =C2=A0 - s/<ERO><attribute-list>/<RRO><attribut= e-list>/ [Per RFC 5440, a
=C2=A0 =C2=A0 report from PCC to PCE is RRO.]

### XXX Pending
 [JM] As above.
%%% Done=C2=A0


=C2=A0 =C2=A0 - The need for the optional xRO is not well documented. Its p= roper
=C2=A0 =C2=A0 naming will depend on the associated use that must be clarifi= ed.
=C2=A0 =C2=A0 - "SRP" is still not defined.

### Isn't it enough to reference the section in which it is defined?
=C2=A0[JM] Once added in terminology section, all these are solved.

%%% Done=C2=A0
=C2= =A0
<snip>

=C2=A0 =C2=A0 - The use of the optional xRO is mentioned, but its relations= hip
=C2=A0 =C2=A0 with the RRO (formerly ERO) is not clear. I suspect some
=C2=A0 =C2=A0 assumptions are made on the way the ERO/RRO are populated; RF= C
=C2=A0 =C2=A0 5440 only says ERO for PCE->PCC and RRO for PCC->PCE.
### XXX Pending
 [JM] As above.

%%% Done =C2=A0
<snip>

=C2=A0 =C2=A0 - The behavior associated to the resource limit per PCC rathe= r
=C2=A0 =C2=A0 looks like a Notifcation than an Error (e.g., in RFC 5440, =C2=A0 =C2=A0 cancelling a set of pending requests relies on PCNtf). Please=
=C2=A0 =C2=A0 consider the use of Notification instead of Error here.

### XXX Pending
 [JM] To be updated.
 %%% Done
=C2=A0
<snip>

=C2=A0 =C2=A0 - s/defined in this document/defined in that (aforementioned)=
=C2=A0 =C2=A0 document/

### Unclear comment, the intention was for the flags to be set as explained= for the new objects in this document, not for anything in 5440.
 [JM] As above: adding "current" may be enough.
 %%% Done
=C2=A0
<snip>

=C2=A0 =C2=A0 - s/on a PCRpt message/On a PCRpt or PCReq message/

### We don't support delegation through a PCReq message
 [JM] Addressed as part of the resolution of the new path delegation.

<snip>

=C2=A0 =C2=A0 - "PCE SHOULD remove all state" is written 3 times:= I wonder about
=C2=A0 =C2=A0 "MUST".

### SHOULD is the correct operation, the PCE is free to choose to keep stat= e around for as long as it wishes. The 3 removal statements refer to differ= ent scenarios.
 =C2=A0[JM] I can live with that.

<snip>

=C2=A0 =C2=A0 - It would be nice to elaborate on the reason why the
=C2=A0 =C2=A0 SYMBOLIC-PATH-NAME MUST be included and not SHOULD.
=C2=A0 =C2=A0 - I do not see why SYMBOLIC-PATH-NAME may be included in SRP<= br> =C2=A0 =C2=A0 Object: defining the LSP Object as its single place seems eno= ugh
=C2=A0 =C2=A0 and much simpler.


### XXX=C2=A0 Pending
%%% T= he inclusion in SRP was a historical leftover and is removed. Regarding why= it MUST be included in the LSP object is described in the draft in section= 7.3.2. It is a stable (across PCEP session, PCC restart, ..etc), signaling= protocol agnostic, and unique Identifier that identifies the LSP during it= s lifetime.
=C2=A0
=
<snip>
- As mentioned above, in Error-Type 19, Error-value 4 should be considered = in a PCNtf.
### XXX Pending
 <snip>
%%% Done=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

=C2=A0 =C2=A0 - Again in section 10.4, the "resource limit exceed"= ; information
=C2=A0 =C2=A0 (Error-value 4 of Error-Type 19) should be considered in a PC= Ntf.

### XXX Pending
 <snip>
%%% Done=C2=A0


--001a114dacbc154d4505260176d3-- From nobody Fri Dec 4 03:34:14 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E387B1B305C; Fri, 4 Dec 2015 03:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=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 18VeKMu2Smps; Fri, 4 Dec 2015 03:34:12 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB211B305B; Fri, 4 Dec 2015 03:34:12 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4FC9C410221; Fri, 4 Dec 2015 12:34:11 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 417F341021C; Fri, 4 Dec 2015 12:34:11 +0100 (CET) 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.224.2; Fri, 4 Dec 2015 12:34:10 +0100 To: Ina Minei References: <56210C68.1080904@orange.com> <56422DF8.6030403@orange.com> From: Julien Meuric Organization: Orange Message-ID: <56617A32.2000602@orange.com> Date: Fri, 4 Dec 2015 12:34:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-pce-stateful-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.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 11:34:14 -0000 Hi Ina, Thank you for publishing the update. It looks like most comments are incorporated. Just a few remain open, see [JM] below. Cheers, Julien Dec. 03, 2015 - inaminei@google.com: > All the changes discussed in this thread have been incorporated in > version 13 published yesterday > > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13 > > Thank you, > > Ina > > > > > > - 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 > > %%% No, we did not think we needed positive acks because we are using > a TCP session (guaranteed delivery all the way to the PCE). > [JM] Yes, leaving the man in the middle case apart, we almost agree on that, but I believe it is not enough. Even if PCEP and TCP stacks are OK, the PCC still cannot know if the PCRpt has been processed by the PCE and/or properly stored in its DB. E.g., how can the PCC distinguish between the expected processing and a PCE considering some message as wrongly formed while not supporting the relevant error message? - In section 5.5.3, assuming an LSP was delegated, does the reception by the PCC of a non empty LSP Update Request with a Delegate Flag to 0 trigger an error? ### XXX Pending %%% No, this is a delegation return. I cleaned up the text, see below. In order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request sent to the PCC. A PCE that no longer wishes to update an LSP's parameters SHOULD return the LSP delegation back to the PCC by sending an empty LSP Update Request which has the Delegate flag set to 0. If a PCC receives a non-empty LSP Update Request with the Delegate flag set to 0, it MUST treat this as a delegation return. [JM] That is quite difficult to fully understand. Delegation returns <=> flag set to 0 seems clear. But why are "empty" associated to "SHOULD" and "non-empty" to MUST? Rewording is required to make sure all sub-cases are covered. > > > > - In section 5.6.2, in case of new LSP, the very first message > sent by the PCC aims at getting a path. This is clearly > the role > of a PCReq message, and the I-D extends it to support the LSP > object including the delegation flag (section 7.3). However, > Figure 8 treats a new LSP the same way as reporting an > existing > LSP, i.e., using a PCRpt message. In this case, there is an > overlap between PCReq and PCRpt, which MUST be resolved > because > interoperability is at stake. Documenting the delegation > of a new > LSP deserves some new text and possibly figure, the > overlapping > specification of the PCRpt should be explicitly precluded. > > ### This is historical confusion in the figure, from the time > when initiation was rolled up in the same document. I modified > the figure so it is clear this is for updating parameters only. > > [JM] Seems addressed. Just to be confirmed when published and to > confront with draft-ietf-pce-pce-initiated-lsp. > [JM] Reading the new section 6.1, the /ERO being mandatory, the case of an empty ERO should be documented. I believe adding an error code to handle it would be enough. From nobody Mon Dec 7 00:43:11 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934A01B32E1 for ; Sun, 6 Dec 2015 04:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.512 X-Spam-Level: X-Spam-Status: No, score=-105.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 EBOutIC6vx6I for ; Sun, 6 Dec 2015 04:26:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8731ACD08 for ; Sun, 6 Dec 2015 04:26:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id ADF34180003; Sun, 6 Dec 2015 04:24:27 -0800 (PST) To: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jonathan.hardwick@metaswitch.com, jpv@cisco.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151206122427.ADF34180003@rfc-editor.org> Date: Sun, 6 Dec 2015 04:24:27 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2015 00:43:10 -0800 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC5440 (4555) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 12:26:24 -0000 The following errata report has been submitted for RFC5440, "Path Computation Element (PCE) Communication Protocol (PCEP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5440&eid=4555 -------------------------------------- Type: Editorial Reported by: Mahendra Singh Negi Section: Appendix A. Original Text ------------- The following set of variables are initialized: TCPRetry=0, Corrected Text -------------- The following set of variables are initialized: ConnectRetry=0, Notes ----- Variable TCPRetry is not defined, defined variable is ConnectRetry. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5440 (draft-ietf-pce-pcep-19) -------------------------------------- Title : Path Computation Element (PCE) Communication Protocol (PCEP) Publication Date : March 2009 Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Dec 7 03:39:09 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 945151AC3D0; Mon, 7 Dec 2015 03:39:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151207113905.12977.66053.idtracker@ietfa.amsl.com> Date: Mon, 07 Dec 2015 03:39:05 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-domain-sequence-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 11:39:05 -0000 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 : Domain Subobjects for Path Computation Element (PCE) Communication Protocol (PCEP). Authors : Dhruv Dhody Udayasree Palle Ramon Casellas Filename : draft-ietf-pce-pcep-domain-sequence-12.txt Pages : 33 Date : 2015-12-07 Abstract: The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a Domain- Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-domain-sequence-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 8 01:50:12 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BED1AC3B5 for ; Tue, 8 Dec 2015 01:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.406 X-Spam-Level: * X-Spam-Status: No, score=1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MANGLED_TRNFER=2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=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 JhzJlk74w6A8 for ; Tue, 8 Dec 2015 01:50:09 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 530651A87DF for ; Tue, 8 Dec 2015 01:50:09 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64E4541021F for ; Tue, 8 Dec 2015 10:50:08 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 0B28B41021E for ; Tue, 8 Dec 2015 10:50:08 +0100 (CET) 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.224.2; Tue, 8 Dec 2015 10:50:07 +0100 References: <20151207203943.29857.75324.idtracker@ietfa.amsl.com> From: Julien Meuric Organization: Orange To: "pce@ietf.org" X-Forwarded-Message-Id: <20151207203943.29857.75324.idtracker@ietfa.amsl.com> Message-ID: <5666A7CF.5070400@orange.com> Date: Tue, 8 Dec 2015 10:50:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207203943.29857.75324.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Pce] Fwd: Last Call: (IS-IS Path Computation and Reservation) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 09:50:11 -0000 Hi all, FYI, this I-D in IETF LC extensively makes use of "PCE". Regards, Julien -------- Message transféré -------- Date : Mon, 7 Dec 2015 12:39:43 -0800 De : The IESG The IESG has received a request from the IS-IS for IP Internets WG (isis) to consider the following document: - 'IS-IS Path Computation and Reservation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-pcr/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-pcr/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2533/ From nobody Wed Dec 9 04:33:08 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520781A9044 for ; Wed, 9 Dec 2015 04:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 V3NfMAhdvEk3 for ; Wed, 9 Dec 2015 04:33:05 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC711A9035 for ; Wed, 9 Dec 2015 04:33:04 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id tB9CWrtW029331; Wed, 9 Dec 2015 12:32:53 GMT Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id tB9CWp5X029305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2015 12:32:52 GMT From: "Adrian Farrel" To: , , , , , , , References: <20151206122427.ADF34180003@rfc-editor.org> In-Reply-To: <20151206122427.ADF34180003@rfc-editor.org> Date: Wed, 9 Dec 2015 12:32:50 -0000 Message-ID: <02f801d1327d$b85a1ff0$290e5fd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJMetW20tWMazzEAbNQY0jPN6mpqJ3MBXMw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-21990.007 X-TM-AS-Result: No--11.179-10.0-31-10 X-imss-scan-details: No--11.179-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTo4HKI/yaqRm8zWN98iBBeGkPqe52Sp8B1VbFClxBANxgi9 cmFBBPB+1KSbN/e88rGsg2Bf0V+jfIWDz7mPxd0p71Wx2uUbPLeEHldzTrGjrRwKSCi0KXuEvQK JOxWBZm9Y+XGpfmaXLN0iK4aOzykGlTFYj5iEM4XNjFbNkZ/OVCGi0ftsSkQyaxNXOJgeVJo+g8 hk6wNrblXC0Qaw/rHiZmOikWeBzs5HtiMn7sZRDKm4PbloS2C3+KgiyLtJrSCyd65qZFFPkzpbf dTAcNXm4vM1YF6AJbZcLc3sLtjOt1ZFWWuOwo7w3QfwsVk0UbtuRXh7bFKB7lpcXwBOHa0lHjW8 9h8Sr1KYF2H8swDFSLuWoAMPyxg3xYVzI3UCCaY= Archived-At: Cc: pce@ietf.org Subject: Re: [Pce] [Editorial Errata Reported] RFC5440 (4555) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 12:33:07 -0000 That looks right to me. Adrian > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: 06 December 2015 12:24 > To: jpv@cisco.com; jeanlouis.leroux@orange-ftgroup.com; akatlas@gmail.com; > db3546@att.com; aretana@cisco.com; jonathan.hardwick@metaswitch.com; > jpv@cisco.com; julien.meuric@orange.com > Cc: pce@ietf.org; rfc-editor@rfc-editor.org > Subject: [Pce] [Editorial Errata Reported] RFC5440 (4555) > > The following errata report has been submitted for RFC5440, > "Path Computation Element (PCE) Communication Protocol (PCEP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5440&eid=4555 > > -------------------------------------- > Type: Editorial > Reported by: Mahendra Singh Negi > > Section: Appendix A. > > Original Text > ------------- > > The following set of variables are initialized: > > TCPRetry=0, > > > > Corrected Text > -------------- > > The following set of variables are initialized: > > ConnectRetry=0, > > Notes > ----- > Variable TCPRetry is not defined, defined variable is > ConnectRetry. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5440 (draft-ietf-pce-pcep-19) > -------------------------------------- > Title : Path Computation Element (PCE) Communication Protocol (PCEP) > Publication Date : March 2009 > Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. > Category : PROPOSED STANDARD > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Wed Dec 9 13:49:32 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DEF1B2E44 for ; Wed, 9 Dec 2015 13:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kKXbqXd7ATqP for ; Wed, 9 Dec 2015 13:49:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6196F1B2E4B for ; Wed, 9 Dec 2015 13:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2443; q=dns/txt; s=iport; t=1449697769; x=1450907369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FhG2uw8OdrbHEXR0arNklA7yOjwzvoD+4Ba2Ywcy2ZA=; b=lZBBH6LQaBvpUI19wyXmSQxskjYFc1QGYTr2YY3tQY0inpDUncfiKY18 Ikw2peDd31tjnrzKkwWScF6P+114zVA8Cggah0baJqBIDg0cevDmOzdK1 2eWES+Qr3yiGdtIX6BJNJ77JXkwHLR0B388Cr+PJL+Q+ZY/5wIk3jns3u Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQBnoGhW/5xdJa1EGoM6U24GvTkBD?= =?us-ascii?q?YFiFwqFbgKBKTgUAQEBAQEBAYEKhDQBAQEDAQEBATc0CwUHBAIBCBEEAQEBHgk?= =?us-ascii?q?HIQYLFAkIAgQOBYgaAwoIDTu6FQ2EPAEBAQEBAQEBAQEBAQEBAQEBAQEBARiGV?= =?us-ascii?q?oIPgm6BQIETggaDTYEaBYdUCocCiAkBi0mBeYFbhESPC4dZAR8BAUKCEQ0QgVZ?= =?us-ascii?q?yAROEXoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,405,1444694400"; d="scan'208";a="57799849" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2015 21:49:28 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tB9LnSMf031284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2015 21:49:28 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Dec 2015 15:49:27 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Wed, 9 Dec 2015 15:49:27 -0600 From: "JP Vasseur (jvasseur)" To: Adrian Farrel Thread-Topic: [Pce] [Editorial Errata Reported] RFC5440 (4555) Thread-Index: AQHRMst6vDZzF36/pEG2F25Ahe6pxw== Date: Wed, 9 Dec 2015 21:49:27 +0000 Message-ID: <8BEAA62A-AA93-4724-AF71-64778046E446@cisco.com> References: <20151206122427.ADF34180003@rfc-editor.org> <02f801d1327d$b85a1ff0$290e5fd0$@olddog.co.uk> In-Reply-To: <02f801d1327d$b85a1ff0$290e5fd0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.96.209] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: JP Vasseur , "pce@ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [Pce] [Editorial Errata Reported] RFC5440 (4555) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:49:31 -0000 Agreed indeed. Thanks. JP. > On Dec 9, 2015, at 7:32 AM, Adrian Farrel wrote: >=20 > That looks right to me. > Adrian >=20 >> -----Original Message----- >> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of RFC Errata System >> Sent: 06 December 2015 12:24 >> To: jpv@cisco.com; jeanlouis.leroux@orange-ftgroup.com; akatlas@gmail.co= m; >> db3546@att.com; aretana@cisco.com; jonathan.hardwick@metaswitch.com; >> jpv@cisco.com; julien.meuric@orange.com >> Cc: pce@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Pce] [Editorial Errata Reported] RFC5440 (4555) >>=20 >> The following errata report has been submitted for RFC5440, >> "Path Computation Element (PCE) Communication Protocol (PCEP)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5440&eid=3D4555 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Mahendra Singh Negi >>=20 >> Section: Appendix A. >>=20 >> Original Text >> ------------- >>=20 >> The following set of variables are initialized: >>=20 >> TCPRetry=3D0, >>=20 >>=20 >>=20 >> Corrected Text >> -------------- >>=20 >> The following set of variables are initialized: >>=20 >> ConnectRetry=3D0, >>=20 >> Notes >> ----- >> Variable TCPRetry is not defined, defined variable is >> ConnectRetry. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5440 (draft-ietf-pce-pcep-19) >> -------------------------------------- >> Title : Path Computation Element (PCE) Communication Proto= col > (PCEP) >> Publication Date : March 2009 >> Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. >> Category : PROPOSED STANDARD >> Source : Path Computation Element >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >=20 From nobody Tue Dec 15 09:00:38 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE21A6FC9; Tue, 15 Dec 2015 09:00:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215170033.20936.77419.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 09:00:33 -0800 Archived-At: Cc: draft-ietf-pce-pcep-domain-sequence@ietf.org, pce@ietf.org, The IESG , pce-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] Document Action: 'Standard Representation of Domain-Sequence' to Experimental RFC (draft-ietf-pce-pcep-domain-sequence-12.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 17:00:33 -0000 The IESG has approved the following document: - 'Standard Representation of Domain-Sequence' (draft-ietf-pce-pcep-domain-sequence-12.txt) as Experimental RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence/ Technical Summary This document specifies a standard representation and encoding of an ordered sequence of domains in Path Computation Element Protocol (PCEP). In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). The domain sequence is used by a Path Computation Client (PCC) to stipulate a pre-determined sequence of domains that a path must traverse. It is also used by a Path Computation Element (PCE) to inform a PCC of a sequence of domains that a path must traverse, without giving full details of the sub-paths within those domains. Working Group Summary There were no particular points of contention in the WG process. The consensus behind publication of this document as an Experimental RFC appears solid. Document Quality There are two existing implementations of this draft. The document has been well reviewed by the PCEP working group, as reflected in the Acknowledgements section. In particular, Adrian Farrel did a thorough review and provided substantial comments, which were all addressed. Personnel Who is the Document Shepherd for this document? Jonathan Hardwick Who is the Responsible Area Director? Deborah Brungard From nobody Tue Dec 15 20:47:49 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BBC1A701C; Tue, 15 Dec 2015 20:47:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216044745.30653.89084.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 20:47:45 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-iro-update-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 04:47:45 -0000 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 : Update to Include Route Object (IRO) specification in Path Computation Element communication Protocol (PCEP) Author : Dhruv Dhody Filename : draft-ietf-pce-iro-update-04.txt Pages : 6 Date : 2015-12-15 Abstract: During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs, it was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). An informal survey was conducted to determine the state of current and planned implementation with respect to IRO ordering and handling of Loose bit (L bit). This document updates the IRO specification of RFC 5440 based on the survey conclusion and recommendation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-iro-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-iro-update-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-iro-update-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 15 20:58:12 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C51A024E for ; Tue, 15 Dec 2015 20:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Og7eMdBMT2KM for ; Tue, 15 Dec 2015 20:58:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14CC1A702A for ; Tue, 15 Dec 2015 20:58:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ49073; Wed, 16 Dec 2015 04:58:05 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Dec 2015 04:58:03 +0000 Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Dec 2015 04:58:03 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.125]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Wed, 16 Dec 2015 10:28:02 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-iro-update-04.txt Thread-Index: AQHRN70WmgrEh4YL0kS866SV4ef+GJ7NCxJA Date: Wed, 16 Dec 2015 04:58:01 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C496F93@BLREML509-MBX.china.huawei.com> References: <20151216044745.30653.89084.idtracker@ietfa.amsl.com> In-Reply-To: <20151216044745.30653.89084.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5670EF5D.0098, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.125, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 28a683dde3ab13e4722b39c876902389 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-iro-update-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 04:58:11 -0000 Hi WG,=20 With this update -=20 (1) Change in copyright notice, because of the text from RFC 5440 (pre-Nov2= 008 work disclaimer). (2) Explicit section on what changes need to be made in RFC 5440, as sugges= ted by our AD. =20 =20 Please let me know if you have any concerns.=20 Regards, Dhruv > -----Original Message----- > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 16 December 2015 10:18 > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D Action: draft-ietf-pce-iro-update-04.txt >=20 >=20 > 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. >=20 > Title : Update to Include Route Object (IRO) specificat= ion > in Path Computation Element communication Protocol (PCEP) > Author : Dhruv Dhody > Filename : draft-ietf-pce-iro-update-04.txt > Pages : 6 > Date : 2015-12-15 >=20 > Abstract: > During discussions of a document to provide a standard representation > and encoding of Domain-Sequence within the Path Computation Element > (PCE) communication Protocol (PCEP) for communications between a Path > Computation Client (PCC) and a PCE, or between two PCEs, it was > determined that there was a need for clarification with respect to > the ordered nature of the Include Route Object (IRO). >=20 > An informal survey was conducted to determine the state of current > and planned implementation with respect to IRO ordering and handling > of Loose bit (L bit). >=20 > This document updates the IRO specification of RFC 5440 based on the > survey conclusion and recommendation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-iro-update/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pce-iro-update-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-iro-update-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From nobody Mon Dec 21 08:29:24 2015 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2E1B398C; Fri, 18 Dec 2015 14:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: , , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218222638.30243.60692.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 14:26:38 -0800 Archived-At: X-Mailman-Approved-At: Mon, 21 Dec 2015 08:29:23 -0800 Cc: Common Control and Measurement Plane Discussion List , JP Vasseur , Traffic Engineering Architecture and Signaling Discussion List , Vishnu Pavan Beeram , The IETF Chair , Path Computation Element Discussion List , Alvaro Retana , David Sinicrope , michael.fargano@centurylink.com Subject: [Pce] New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 22:26:38 -0000 Title: Achieving Packet Network Optimization using DWDM Interfaces Submission Date: 2015-12-18 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1449/ Please reply by 2016-01-25 From: "Michael Fargano" To: vbeeram@juniper.net, lberger@labn.net,akatlas@gmail.com,aretana@cisco.com,db3546@att.com,jonathan.hardwick@metaswitch.com,jpv@cisco.com,julien.meuric@orange.com,daniele.ceccarelli@ericsson.com,zhangfatai@huawei.com Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,David Sinicrope ,Jonathan Hardwick ,Fatai Zhang ,Alia Atlas ,Path Computation Element Discussion List ,Vishnu Pavan Beeram ,The IETF Chair ,Daniele Ceccarelli ,Traffic Engineering Architecture and Signaling Discussion List ,Lou Berger ,Common Control and Measurement Plane Discussion List ,JP Vasseur , Response Contacts: michael.fargano@centurylink.com Technical Contacts: Purpose: For comment Body: Dear IETF Routing Area and Working Group Leaders: Thank you very much for your timely response to our last liaison concerning our document WT-319 Part B, Achieving Packet Network Optimization using DWDM Interfaces – Physically Separated, Logically Separated. We understand the time constraints you faced with IETF94. We appreciate your effort to send us preliminary feedback on the document despite these constraints and your kind offer to do a thorough technical review of our document. We respect the expertise of the IETF Routing Area and graciously accept your offer. We discussed and addressed your preliminary feedback in our recent Puerto Vallarta meeting (Nov 16-20). Attached, please find an updated version of the document for your review and comment. Our next meeting is February 1-6, 2016 in Hong Kong. If possible, we would appreciate your response by January 25, 2016 to help us prepare for our meeting. Please let us know if this time frame is insufficient. We want to again express our appreciation for your continued consideration and support with this important topic. Sincerely, Michael Fargano, Broadband Forum Technical Committee Chair Attachments: Straw Ballot https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-18-broadband-forum-rtg-ccamp-pce-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-1.pdf Liaison https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-18-broadband-forum-rtg-ccamp-pce-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-2.pdf From nobody Tue Dec 22 23:25:06 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67B1ACD53 for ; Tue, 22 Dec 2015 23:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hLLUkh30wCuC for ; Tue, 22 Dec 2015 23:25:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EA81ACD50 for ; Tue, 22 Dec 2015 23:25:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBX84464; Wed, 23 Dec 2015 07:24:58 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Dec 2015 07:24:57 +0000 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Dec 2015 07:24:57 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 15:24:52 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: NEXT STEP of draft-wu-pce-traffic-steering-sfc Thread-Index: AdE9UwME48jCt9IUS+CddE8WAdC8vg== Date: Wed, 23 Dec 2015 07:24:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.255] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852A96DCnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.567A4C4A.0096, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 948f6153cc1a9e4f9ad6fd69a8b97d4e Archived-At: Subject: [Pce] NEXT STEP of draft-wu-pce-traffic-steering-sfc X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 07:25:04 -0000 --_000_B8F9A780D330094D99AF023C5877DABA852A96DCnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks: If you didn't follow the discussion on SFC mailing list, I like to draw you= r attention that SFC control plane architecture adopted as a WG draft in August 2015 triggered a lot of SFC control plane requirements discussions that are related to draft-wu-pce= -traffic-steering-sfc-07. https://mailarchive.ietf.org/arch/msg/sfc/0H-H4BhyN0Nuroev_0hd5CMKOYM https://mailarchive.ietf.org/arch/msg/sfc/CVU-H4hP9kQD0CoLMHw9jYfZ0M4 https://mailarchive.ietf.org/arch/msg/sfc/3fy9X1VmGN6V6GIT_QMDXrXwVkY 1. The relationship between SFC,SFP and RSP was clarified, the contro= l plane operating on SPF IDs rather than SFC ID got agreed. 2. Service Chaining work doesn't requires correlating service path ID= s with service chain IDs within the data plane. The relationship of paths t= o chains falls in the control plane. 3.control-plane requirements defined in SFC control plane architecture allo= ws to instruct a loose path (SFP) or a strict path (RSP),whether a full pat= h is specified within a domain or if it is deferred to SFFs is really deployment-specific. 4.In addition, Encoding the Exact SFF-SF-sequence in Data Packets and Fully= Controlled SFF-SF-Sequence for a SFP were also discussed on the list and two new sections 4.10.4 and 4.10.5 were added into version (-02) of dra= ft-ietf-sfc-control-plane to discuss RSP related aspect. ( Referring to Section 2.3.1 of RFC7665, we can see RSP specify exact sequence of SFFs and SFs that the packets will= actually visit and SFF/SF locators while SFP may be fully constrained or p= artial constrained and is constrained version of the original SFC. ) draft-wu-pce-traffic-steering-sfc-07 is a draft that provides a solution to= SFC control plane requirements on RSP, SFC, SFP which was discussed on the= SFC mailing list. We authors plan to make revision to draft-wu-pce-traffic-steering-sfc to ca= pture all the discussing points in the SFC ML and get in line with the draf= t-ietf-sfc-control-plane adopted recently in SFC WG. Let us know if you have any comments/suggestion/inputs on this topic. Also wish you have a good holiday in Christmas.:-) Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA852A96DCnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks:

If you didn't follow the discus= sion on SFC mailing list, I like to draw your attention that SFC control

plane architecture adopted as a= WG draft in August 2015 triggered a lot of

SFC control plane requirements = discussions that are related to draft-wu-pce-traffic-steering-sfc-07.<= /o:p>

https://mailarchive.ietf= .org/arch/msg/sfc/0H-H4BhyN0Nuroev_0hd5CMKOYM

https://mailarchive.ietf= .org/arch/msg/sfc/CVU-H4hP9kQD0CoLMHw9jYfZ0M4

https://mailarchive.ietf= .org/arch/msg/sfc/3fy9X1VmGN6V6GIT_QMDXrXwVkY

 

1= .   &= nbsp;   The relationship betwee= n SFC,SFP and RSP was clarified, the control plane operating on SPF IDs rat= her than SFC ID got agreed.

=  

2= .   &= nbsp;   Service Chaining work d= oesn't requires correlating service path IDs with service chain IDs within = the data plane. The relationship of paths to chains falls in the control pl= ane.

 

3.control-plane requirements de= fined in SFC control plane architecture allows to instruct a loose path (SF= P) or a strict path (RSP),whether a full path is specified within a domain = or

if it is deferred to SFFs is re= ally deployment-specific.

 

4.In addition, Encoding the Exa= ct SFF-SF-sequence in Data Packets and Fully Controlled SFF-SF-Sequence for= a SFP were also discussed on the list

and two new sections 4.10.4 and= 4.10.5 were added into version (-02) of draft-ietf-sfc-control-plane to di= scuss RSP related aspect.

 

( Referring to Section 2.3.1 of= RFC7665,

we can see RSP specify exact se= quence of SFFs and SFs that the packets will actually visit and SFF/SF loca= tors while SFP may be fully constrained or partial constrained and is<= /o:p>

constrained version of the orig= inal SFC. )

 

draft-wu-pce-traffic-steering-s= fc-07 is a draft that provides a solution to SFC control plane requirements= on RSP, SFC, SFP which was discussed on the SFC mailing list.

We authors plan to make revisio= n to draft-wu-pce-traffic-steering-sfc to capture all the discussing points= in the SFC ML and get in line with the draft-ietf-sfc-control-plane adopte= d recently in SFC WG.

Let us know if you have any com= ments/suggestion/inputs on this topic.

 

Also wish you have a good holid= ay in Christmas.:-)

 

Regards!

-Qin

--_000_B8F9A780D330094D99AF023C5877DABA852A96DCnkgeml513mbxchi_-- From nobody Wed Dec 30 11:42:41 2015 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EB31ACE89; Wed, 30 Dec 2015 11:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 utL0PsTKrIdV; Wed, 30 Dec 2015 11:42:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6938C1A03A1; Wed, 30 Dec 2015 11:42:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6A807180003; Wed, 30 Dec 2015 11:41:59 -0800 (PST) To: mahendrasingh@huawei.com, jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151230194159.6A807180003@rfc-editor.org> Date: Wed, 30 Dec 2015 11:41:59 -0800 (PST) Archived-At: Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Held for Document Update] RFC5440 (4555) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 19:42:35 -0000 The following errata report has been held for document update for RFC5440, "Path Computation Element (PCE) Communication Protocol (PCEP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5440&eid=4555 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Mahendra Singh Negi Date Reported: 2015-12-06 Held by: Deborah Brungard (IESG) Section: Appendix A. Original Text ------------- The following set of variables are initialized: TCPRetry=0, Corrected Text -------------- The following set of variables are initialized: ConnectRetry=0, Notes ----- Variable TCPRetry is not defined, defined variable is ConnectRetry. -------------------------------------- RFC5440 (draft-ietf-pce-pcep-19) -------------------------------------- Title : Path Computation Element (PCE) Communication Protocol (PCEP) Publication Date : March 2009 Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG