Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)
Thanks. Make sure it appears in the ToC. Regards, B. Hi Benoit, Adrian, I have updated Appendix A to include all changes from RFC6006 and made the RBNF changes as a sub-section. See working copy at - https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt Diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-rfc6006bis-03&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt Thanks! Dhruv -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: 30 August 2017 17:39 To: 'Benoit Claise' ; 'The IESG' Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org; 'Fred Baker' Subject: Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce- rfc6006bis-03: (with COMMENT) Morning Komrade Claise, Did you spot Appendix A? A -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Benoit Claise Sent: 30 August 2017 10:32 To: The IESG Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org; Fred Baker Subject: [Pce] Benoit Claise's No Objection on draft-ietf-pce- rfc6006bis-03: (with COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-pce-rfc6006bis-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-rfc6006bis/ -- COMMENT: -- - Where is the "diff from RFC6006" section? The following is not useful: This document obsoletes RFC 6006 and incorporates all outstanding Errata: o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868. I found "Appendix A. Summary of the RBNF Changes from RFC 6006", as a good start, but it doesn't even appear in the table of content. Why? - I've not been following the IPR situation (as described by Alvaro), but would like to understand and it should be discussed during the telechat. Is it the case that https://datatracker.ietf.org/ipr/1686/ (related to RFC6006) is updated by https://datatracker.ietf.org/ipr/2983/ (related to RFC6006 and RFC6006bis)? ___ 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 . ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-pce-rfc6006bis-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-rfc6006bis/ -- COMMENT: -- - Where is the "diff from RFC6006" section? The following is not useful: This document obsoletes RFC 6006 and incorporates all outstanding Errata: o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868. I found "Appendix A. Summary of the RBNF Changes from RFC 6006", as a good start, but it doesn't even appear in the table of content. Why? - I've not been following the IPR situation (as described by Alvaro), but would like to understand and it should be discussed during the telechat. Is it the case that https://datatracker.ietf.org/ipr/1686/ (related to RFC6006) is updated by https://datatracker.ietf.org/ipr/2983/ (related to RFC6006 and RFC6006bis)? ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Benoit Claise's No Objection on draft-ietf-pce-stateful-pce-18: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-pce-stateful-pce-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ -- COMMENT: -- Below is Lionel's OPS DIR review. I've pointed out some "issues" that might not be real issues for people involved in PCE but that could be at least clarified for readers of this document. Detailed comments are provided below. Regards, Lionel 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, PCEP Speaker. This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State Database. [LM] I didn't find a clear definition of the LSP state, except through the definition of the LSP State database in ietf-pce-stateful-pce-app, i.e. The second is the LSP State Database (LSP-DB), in which a PCE stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth/resource usage, switching types and LSP constraints. As this document heavily relies on this LSP state concept, it could be useful to (re-)define it in this document or to find a correct reference for it. 3.2. Objectives The objectives for the protocol extensions to support stateful PCE described in this document are as follows: [...] o Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time. A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation. A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. [LM] I'm assuming that the PCE returning the delegation has also to notify the PCC. If so, maybe: "the If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCE about the revocation." [LM] the bullet point could be then splitted into two bullets, one for PCC, one for PCE. 5.4. Capability Advertisement During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of stateful PCEP extensions. A PCEP Speaker includes the "Stateful PCE Capability" TLV, described in Section 7.1.1, in the OPEN Object to advertise its support for PCEP stateful extensions. The Stateful Capability TLV includes the 'LSP Update' Flag that indicates whether the PCEP Speaker supports LSP parameter updates. The presence of the Stateful PCE Capability TLV in PCC's OPEN Object indicates that the PCC is willing to send LSP State Reports whenever LSP parameters or operational status changes. The presence of the Stateful PCE Capability TLV in PCE's OPEN message indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes. [LM] is it "willing/interested for" or just a capability indication? It is not the same thing from a procedure point of view. The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message. If the PCEP Speaker on the PCC supports the extensions of this draft but did not advertise this capability, then upon receipt of PCUpd message from the PCE, it MUST generate a PCErr with error-type 19 (Invalid Operation), error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised)(see Section 8.5) and it SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this draft but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with error- type 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if active stateful PCE capability was not advertised) (see Section 8.5) and it SHOULD terminate the PCEP session. [LM] why the recommendation for closing the session if an expl
[Pce] Benoit Claise's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-pce-pcep-service-aware-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ -- COMMENT: -- The authors and the OPS DIR reviewers (Jouni and Al) agreed on some new text. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] draft-ietf-pce-pcep-yang: YANG model compilation issue
Dear all, At the last IETF hackathon, we added a new compiler to our scripts: confdc While draft-ietf-pce-pcep-yang passes compilation with pyang, it fails with confdc. See http://www.claise.be/IETFYANGPageCompilation.html Note: confdc makes some more checks for xpath expressions. Regards, Benoit ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Benoit Claise's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-pce-iro-update-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-iro-update/ -- COMMENT: -- I'm surprised by this comment, from the write-up: There were nine responses to the survey, but the majority of these respondents have not commented on the proposed protocol update. ... even if I also see this in the write-up: it was clear that the majority of implementations would either be unaffected, or not significantly affected, by the change in semantics and format that are proposed in this draft. Anyway, I'll trust the working group did the right thing. Regarding the survey issue, my first reaction was to include (parts of) https://tools.ietf.org/html/draft-dhody-pce-iro-survey-02 in an appendix. On second thought, I'm with Alvaro: no need to mention the survey. The WHAT is important to document, not HOW you got there. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
