[Pce] State changed: charter-ietf-pce-06-00
State changed to Informal IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-pce/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] FW: New Version Notification for draft-alvarez-pce-path-profiles-04.txt
Folks, We've submitted a new version of draft-alvarez-pce-path-profiles. Based on previous feedback, we've added details on motivation and some introductory text. We've also added text on security considerations. Here's a view of the diffs: https://tools.ietf.org/rfcdiff?url2=draft-alvarez-pce-path-profiles-04.txt Your comments are welcome. Thanks. Cheers. SA -- > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Sunday, November 09, 2014 9:21 PM > To: Luis Tomotaki; Siva Sivabalan (msiva); Jeff Tantsura; Siva > Sivabalan (msiva); Rob Shakir; Santiago Alvarez (saalvare); Rob Shakir; > Zafar Ali (zali); Victor Lopez; Zafar Ali (zali); Luis Tomotaki; Victor > Lopez; Santiago Alvarez (saalvare); Jeff Tantsura > Subject: New Version Notification for draft-alvarez-pce-path-profiles- > 04.txt > > > A new version of I-D, draft-alvarez-pce-path-profiles-04.txt > has been successfully submitted by Santiago Alvarez and posted to the > IETF repository. > > Name: draft-alvarez-pce-path-profiles > Revision: 04 > Title:PCE Path Profiles > Document date:2014-11-07 > Group:Individual Submission > Pages:13 > URL:http://www.ietf.org/internet-drafts/draft-alvarez-pce- > path-profiles-04.txt > Status: https://datatracker.ietf.org/doc/draft-alvarez-pce- > path-profiles/ > Htmlized: http://tools.ietf.org/html/draft-alvarez-pce-path- > profiles-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-alvarez-pce- > path-profiles-04 > > Abstract: >This document describes extensions to the Path Computation Element >(PCE) Communication Protocol (PCEP) to signal path profile >identifiers. A profile represents a list of path parameters or >policies that a PCEP peer may invoke on a remote peer using an > opaque >identifier. When a path computation client (PCC) initiates a path >computation request, the PCC can signal profile identifiers to > invoke >path parameters or policies defined on the PCE which would influence >the path computation. Similarly, when a PCE initiates or updates a >path, the PCE can signal profile identifiers to invoke path >parameters or policies defined on the PCC which would influence the >path setup. > > > > > 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
Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09
Hi, For the error handling on PCUpd, and instantiation draft, I think it would be usefull to align the error procedures and capabilities. in draft-ietf-pce-stateful-pce-10 the error is returned via PCRpt, for the same kind of error its returned using a PCErr in draft-ietf-pce-pce-initiated-lsp-02 ( error-type 24 (LSP instantiation error) , error-value =1 (Unacceptable instantiation parameter) ) It would mean moving the definition from instantion to stateful and changing the type of error for one specific error type, this is not a too big change, BR Cyril On 27 October 2014 03:57, Cyril Margaria wrote: > Hi Ina, > > Thanks, see inline for the open points. > > On 27 October 2014 01:57, Ina Minei 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. >>> Th
Re: [Pce] FW: New Version Notification for draft-alvarez-pce-path-profiles-04.txt
Hi authors, Currently, the document proposes a numbered-based ID for the profiles. The name-based IDs are in practice more favourable in deployment (an example is the symbolic name for PCE instantiated LSP). Do you plan to extend the PATH-PROFILE object to carry textual based IDs? Also, it would be useful to clarify the scope of the PP IDs-- e.g. between PCEP peer pairs, or global across the network/PCEs.. For example, upon (re)delegation of LSPs from a PCE to alternate PCE, is the expectation that such PP-IDs can change? Regards, Tarek On 2014-11-10, 8:19 AM, "Santiago Alvarez (saalvare)" wrote: >Folks, > >We've submitted a new version of draft-alvarez-pce-path-profiles. Based >on previous feedback, we've added details on motivation and some >introductory text. We've also added text on security considerations. >Here's a view of the diffs: >https://tools.ietf.org/rfcdiff?url2=draft-alvarez-pce-path-profiles-04.txt > >Your comments are welcome. Thanks. >Cheers. > >SA >-- > > >> -Original Message- >> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >> Sent: Sunday, November 09, 2014 9:21 PM >> To: Luis Tomotaki; Siva Sivabalan (msiva); Jeff Tantsura; Siva >> Sivabalan (msiva); Rob Shakir; Santiago Alvarez (saalvare); Rob Shakir; >> Zafar Ali (zali); Victor Lopez; Zafar Ali (zali); Luis Tomotaki; Victor >> Lopez; Santiago Alvarez (saalvare); Jeff Tantsura >> Subject: New Version Notification for draft-alvarez-pce-path-profiles- >> 04.txt >> >> >> A new version of I-D, draft-alvarez-pce-path-profiles-04.txt >> has been successfully submitted by Santiago Alvarez and posted to the >> IETF repository. >> >> Name:draft-alvarez-pce-path-profiles >> Revision:04 >> Title: PCE Path Profiles >> Document date: 2014-11-07 >> Group: Individual Submission >> Pages: 13 >> URL:http://www.ietf.org/internet-drafts/draft-alvarez-pce- >> path-profiles-04.txt >> Status: https://datatracker.ietf.org/doc/draft-alvarez-pce- >> path-profiles/ >> Htmlized: http://tools.ietf.org/html/draft-alvarez-pce-path- >> profiles-04 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-alvarez-pce- >> path-profiles-04 >> >> Abstract: >>This document describes extensions to the Path Computation Element >>(PCE) Communication Protocol (PCEP) to signal path profile >>identifiers. A profile represents a list of path parameters or >>policies that a PCEP peer may invoke on a remote peer using an >> opaque >>identifier. When a path computation client (PCC) initiates a path >>computation request, the PCC can signal profile identifiers to >> invoke >>path parameters or policies defined on the PCE which would influence >>the path computation. Similarly, when a PCE initiates or updates a >>path, the PCE can signal profile identifiers to invoke path >>parameters or policies defined on the PCC which would influence the >>path setup. >> >> >> >> >> 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 mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
