[Pce] IPR poll on draft-ietf-pce-association-diversity
Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] IPR poll on draft-ietf-pce-stateful-path-protection
Hi authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-pce-p2mp-12: Discuss 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-p2mp/ -- DISCUSS: -- This is a comparatively minor point, but I don't think some of the message layout is quite fully specified. In particular, Section 7.2 discusses some new TLVs (in a confusing way, referring to the class of two TLVs as a single nonexistent TLV) but does not always say which object the TLVs are allowed to appear within. (The first paragraph seems to talk of the TLV appearing in a PCRpt, which is a message and as such would contain only objects and not TLVs directly.) The second paragraph does mention the LSP object, which leads the reader to infer that this TLV is only intended to appear in the LSP object, and only in the PCRpt and PCUpd messages explicitly mentioned, but we probably shouldn't force readers to make that leap. -- COMMENT: -- I've made a lot of comments about grammar nits (tagged as such), but there are also some more substantial comments to look for. Section 1 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]). nit: some readers might wonder who has done this identification. Section 3.1 [RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc., which are equally applicable to P2MP TE LSPs. [RFC8231] defines the extensions to PCEP for P2P TE LSPs. [...] nit: maybe "the extensions to PCEP needed for stateful operation of P2P TE LSPs"? Just "the extensions" is pretty generic. Section 5.1 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report in a PCRpt message can contain actual P2MP TE LSP path attributes, Is this "can contain" or just "contains"? Section 5.6.3.1 The Instantiation operation of P2MP TE LSPs is same as defined in nit: "the same as" section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC- nit: comma after "[RFC8281]" PATH-NAME TLV etc. Rules of processing and error codes remains nit: comma after TLV unchanged. The N (P2MP) flag (Section 7.1) MUST be set in LSP object nit: "The rules for processing and use of error codes remain unchanged." nit: "in the LSP object" in PCInitiate message by PCE to specify the instantiation is for P2MP nit: "PCInitiate messages by the PCE to specify that the instantiation" TE LSPs. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIERS nit: parentheses around "as per [RFC8281]" TLV SHOULD NOT be included in the LSP object in PCIntiitate message nit: "PCInitiate messages" (as it is generated by PCC and carried in PCRpt message instead) and MUST be ignored on receipt. Section 6.1 Was it a conscious decision to depart from RFC 8231 and inline objects in the definition of (as opposed to keeping the intermediate construction)? The P2MP END-POINTS object defined in [RFC8306] is mandatory for specifying address of P2MP leaves grouped based on leaf types. nit: "addresses of P2MP leaves, grouped by leaf type" When reporting the status of a P2MP TE LSP, the destinations MUST be grouped in END-POINTS object based on the operational status (O field in S2LS object) and leaf type (in END-POINTS). This way, leaves of the same type that share the same operational status are grouped together. [...] Does this mean that it's an error for a PCRpt message to include more than one END-POINTS object with a given value of leaf-type? If so, it may be worth stating that explicitly. For a delegated P2MP TE LSP configuration changes are reported via PCRpt message. For example, adding of new leaves END-POINTS (leaf- type = 1) is used where as removing of old leaves (leaf-type = 2) is used. nit: "is used, and removing of old leaves (leaf-type = 2) is used". Note that the compatibility with the [RFC8231] definition of is preserved. At least one instance of MUST be present in this message for P2MP LSP. Interestingly,
Re: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT)
Hi Dhruv, > On Apr 9, 2019, at 2:23 PM, Dhruv Dhody wrote: > > Hi Suresh, > > Thanks for your review! > > On Tue, Apr 9, 2019 at 11:37 PM Suresh Krishnan via Datatracker > wrote: >> >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-pce-stateful-pce-p2mp-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-stateful-pce-p2mp/ >> >> >> >> -- >> COMMENT: >> -- >> >> * Section 7.2. >> >> "The special value of all zeros for this TLV is used to refer to all paths >> pertaining to a particular PLSP-ID." >> >> Can you clarify what fields are all zero? What would the length be? >> >> > > All fields of the value portion of the TLV are set to zero. The TLVs > has a fixed length of 16 and 40 for IPv4 and IPv6 respectively. > RFC8231 (section 7.3.1) also uses similar language for the TLV defined > there. Do you see a need to update text and be explicit? It would be nice to add but I will leave it to your discretion. Thanks Suresh ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Suresh Krishnan's No Objection on draft-ietf-pce-gmpls-pcep-extensions-14: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-pce-gmpls-pcep-extensions-14: 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-gmpls-pcep-extensions/ -- COMMENT: -- * Section 2.5.2 "In this object type the order of the TLVs MUST be followed according to the object type definition." Not sure what this means. Can you clarify? * Section 2.7 "C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]." I could not find any references to C-Types in RFC3471. Shouldn't you be referring to RFC3473 instead? I have a similar comment for the Label field. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT)
Hi Suresh, Thanks for your review! On Tue, Apr 9, 2019 at 11:37 PM Suresh Krishnan via Datatracker wrote: > > Suresh Krishnan has entered the following ballot position for > draft-ietf-pce-stateful-pce-p2mp-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-stateful-pce-p2mp/ > > > > -- > COMMENT: > -- > > * Section 7.2. > > "The special value of all zeros for this TLV is used to refer to all paths > pertaining to a particular PLSP-ID." > > Can you clarify what fields are all zero? What would the length be? > > All fields of the value portion of the TLV are set to zero. The TLVs has a fixed length of 16 and 40 for IPv4 and IPv6 respectively. RFC8231 (section 7.3.1) also uses similar language for the TLV defined there. Do you see a need to update text and be explicit? Thanks! Dhruv ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Proposed Implementation Policy for PCE WG
Hi WG, In discussion with our ADs and with other WG chairs in the Routing Area, the PCE chairs have decided that it would be good for the working group to have a stated policy about what implementation is needed, desired, or required before a draft can advance for publication as an RFC. The full range of options is available from "no implementation required" up to "multiple independent and inter-operable implementations required". The purposes are to help ensure quality and implementable RFCs, to make sure that our work is truly relevant and needed, and to understand the relative priorities of our work. The chairs briefly mentioned this at the IETF 104 PCE WG meeting, and we promised to start a discussion on what 'Implementation Policy' to set for the PCE WG. This is a subject for the WG to decide through the usual rough consensus, but the chairs would like to start the discussion with a proposal as follows - "All WG I-Ds are required to include an 'Implementation Status' Section (as per RFC7942) to document known existing or planned implementations. The chairs can make exceptions on a per-document basis." Please raise any concern with the proposed implementation policy by 24th April 2019. Thanks! Adrian, Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection
Hi all, This message initiates a bulk WG Last Call for both draft-ietf-pce-association-diversity-06 and draft-ietf-pce-stateful-path-protection-04. Please review these documents and share your feedback using the PCE mailing list. If you have an implementation of any of them, you may let the chairs know privately. This double LC will last for 3 weeks and will end on Tuesday April 30. Thanks, Adrian, Dhruv & Julien _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp
Authors, Working Group, MPLS-TP is defined as a network that: "It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. (RFC 5654, section 2.3, requirement 36.)" ... "It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. (RFC 5654, section 2.5.1.1, requirement 63.)" In fact most MPLS-TP networks are deployed without IP in the data plane. SR-MPLS on the other hand is a technology that is defined to USE IGPs to distribute MPLS-labels, and thus requires IP in the data plane. PCEP also runs over TCP/IP. The draft does not discuss this. I think this is needed, do you have plans to do so? /Loa -- Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
