[Pce] I-D Action: draft-ietf-pce-stateful-pce-10.txt
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-10.txt Pages : 47 Date: 2014-10-26 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: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-10 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/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09
Dhruv, thank you for sending the reference. In that case, should already be compliant since the draft defines new pcep tlvs. On Sun, Oct 26, 2014 at 10:44 PM, Dhruv Dhody dhruv.dh...@huawei.com wrote: Hi Ina, Snipping to the only open issue… - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added? The Symbolic Path Name is padded to 4-bytes alignment; padding itself is not included in the Length field. ### No, I think this is a disruptive change for implementations that already handle the variable length of this TLV. Doing what you propose would break the parsing code. But RFC5440 TLV definition require this http://tools.ietf.org/html/rfc5440#section-7.1 *7.1* http://tools.ietf.org/html/rfc5440#section-7.1*. PCEP TLV Format* A PCEP object may include a set of one or more optional TLVs. All PCEP TLVs have the following format: Type: 2 bytes Length: 2 bytes Value: variable A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). So I am hoping the implementations of stateful PCE should follow the base RFC5440 TLV definition . Regards, Dhruv ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] 转发: New Version Notification for draft-xu-pce-sr-sfc-02.txt
Hi all, An updated revision has been uploaded. The main change is to support both the stateless and stateful PCE models. Your questions and comments are appreciated. Best Regards, Jianjie -邮件原件- 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 发送时间: 2014年10月27日 15:22 收件人: Luis M. Contreras; Siva Sivabalan; Xuxiaohu; Siva Sivabalan; Youjianjie; Xuxiaohu; Himanshu Shah; Himanshu C. Shah; Youjianjie; Luis M. Contreras 主题: New Version Notification for draft-xu-pce-sr-sfc-02.txt A new version of I-D, draft-xu-pce-sr-sfc-02.txt has been successfully submitted by Jianjie You and posted to the IETF repository. Name: draft-xu-pce-sr-sfc Revision: 02 Title: PCEP Extensions for SFC in SPRING Networks Document date: 2014-10-27 Group: Individual Submission Pages: 14 URL:http://www.ietf.org/internet-drafts/draft-xu-pce-sr-sfc-02.txt Status: https://datatracker.ietf.org/doc/draft-xu-pce-sr-sfc/ Htmlized: http://tools.ietf.org/html/draft-xu-pce-sr-sfc-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-xu-pce-sr-sfc-02 Abstract: [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC architecture in which the PCE is used to compute service function paths in SPRING networks. Based on the above architecture, this document describes extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and instantiate service function paths in SPRING networks. The extensions specified in this document are applicable to both the stateless PCE model and the stateful PCE model. 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. The IETF Secretariat ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-ietf-pce-lsp-setup-type-00.txt
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 : Conveying path setup type in PCEP messages Authors : Siva Sivabalan Jan Medved Ina Minei Edward Crabbe Robert Varga Filename: draft-ietf-pce-lsp-setup-type-00.txt Pages : 7 Date: 2014-10-26 Abstract: A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-00 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/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09
Hi Ina, Thanks, see inline for the open points. On 27 October 2014 01:57, Ina Minei inami...@google.com wrote: Thank you for the careful review, please see inline ###. [snip] I Have the following comment for draft-ietf-pce-stateful-pce-09: Section 2 The document references the following timers: - State Timeout Interval - Redelegation Timeout Interval RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section for those variables would be better, as they are integral part of the extensions. ### They are discussed in the main part of the draft, their use etc is introduced as early as page 4 of the doc. The suggested values for these timers are added in the operational section in the appendix, where they logically belong and I don't think we want to move them. I think it will be easier for YANG/MIB module designers to have a small appendix for those, with recommended values repeated there. The rest of the document does not need to be changed in that regards. Section 5.4 After the first paragraph, add: The State synchronization start with a LSP state report having the SYNC Flag in the LSP Object set to 1. Reason: This would allow for the PCC to fully resend its database after the Initialization phase, and clarify the PCE operation. ### This is covered in the current text and also clearly shown in figure 1. . It is implicit in the text,, I think making it explicit would be better for implementations. Section 5.6.2 OLD If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3 ) with LSP error-value=³Unacceptable parameters in the LSP object in the PCRpt message to the PCE NEW If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3 ) with LSP error-value=³Unacceptable parameters in the LSP object in the PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that were not accepted in the PCRpt message. Reason: If the PCC includes the objects (current PCC values) that caused the PCUpd to be rejected, it would help the PCE avoid resending them. A PCErr would allow to include the objects, a new error type would be needed but error handling from PCE side should be rather easy. Another possibility is having the LSP-ERROR-CODE containing a list of Object-Class, OT . ### While I agree in principle, I think if we go down this road we should also include the reason why the object was rejected to make this useful. Unless others feel strongly, I would not add this. I think having the mechanism would be aldready usefull with existing error messages. Having WG feedback in also welcomed. Section 7.3. Nits: Using Synchronize would be better aligned with other bits definition S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt. R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt (or it is allowed on PCUpd?) O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on transmission and MUST be ignored on receipt. ### This would preclude use of these bits in future documents, so I prefer not to add this. Reserved bit are usually defined as follows Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. So restricting those values on PCUpd in this document does not preclude another document indicating how to use them when supporting that other document (It will be likely negotiated). Moreover this allows the new defining document to make sure that those bits have a specific value when using the stateful document. Section 7.3.3. The error value ŒLSP preempted¹ could seem a bit redundant with ŒRSVP signaling error¹ and the corresponding RSVP preempted error code, I believe the error code ŒLSP preempted¹ should be seen when a PCC-local administrative preemption is made, and the RSVP signaling error should be used otherwise (the error node can be of value for the PCE) ### I think there is value to keep preemption separate from signaling error, and I prefer to leave them distinct. My comment was not much on removing it, but have the text scope them better, as they are mutually exclusive, implementation wise I would like to know when to send the PCEP preempted, and the signaling preempted. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt
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 : Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup Authors : Xiaoping Zheng Nan Hua Wangyang Liu Bingkun Zhou Guoying Zhang Filename: draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt Pages : 12 Date: 2014-10-27 Abstract: A stateful Path Computation Element (PCE) maintains the information of Label Switched Path (LSP) and resource availability within a domain, so multiple stateful PCEs are able to provide traffic engineering inter-domain routing through cooperating with each other. This document introduces the applicability of cooperative stateful PCE for establishing inter-domain inter-vendor LSP which is initiated by PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-inter-domain-lsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-inter-domain-lsp-00 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/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
