[Pce] [Errata Verified] RFC8231 (5492)
The following errata report has been verified for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5492 -- Status: Verified Type: Editorial Reported by: Upendra Singh Date Reported: 2018-09-05 Verified by: Deborah Brungard (IESG) Section: 6.1 Original Text - Under section 6.1, PCRpt message is defined. In definition of path, Where: ::= [] Corrected Text -- Where: ::= [] [] Notes - The change aligns the RBNF with the following text in the document (section 6.1) - Note that the intended-attribute-list is optional and thus may be omitted. -- RFC8231 (draft-ietf-pce-stateful-pce-21) -- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date: September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category: PROPOSED STANDARD Source : Path Computation Element Area: Routing Stream : IETF ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing
Hi Dhruv, The issue we have is that all the PCC and PCE implementations which successfully interoperated until and during last year EANTC event implemented the top level SR-PCE-CAPABILITY TLV with a value of 26. While one can reasonably quickly upgrade a PCE to use the combination of the PATH-SETUP-TYPE-CAPABILITY TLV and SR-PCE-CAPABILITY sub-TLV, the issue is really with the PCC. Many of our customers deploy routers with support of the top level SR-PCE-CAPABILITY TLV only and upgrading them is not always possible within a reasonable timeframe. In fact some customers will only upgrade if they are picking a new major feature. So, we cannot control this as vendors really. My vote is to relax the rule and make it a SHOULD because the onus will most likely be on PCE implementations to support both earlier and latest encodings. Implementations which chose to do this optional behavior MUST send both TLVs. Also, the text below is not sufficient. It should also state the behavior of newer implementation towards implementations which followed the earlier versions of this draft. The newer implementation must send both the PATH-SETUP-TYPE-CAPABILITY TLV (with the SR-PCE-CAPABILITY TLV as sub-TLV) *and* the SR-PCE-CAPABILITY as a top level TLV. That way the earlier implementations will ignore the first TLV (and its sub-TLV) and honor the second TLV. The text below does not state that. Also, I am not sure if the sub-TLV will have a codepoint drawn from the same space as the top level PCEP TLVs. If so, then we cannot re-use the value of 26 as far as I understand but I may be wrong. Regards, Mustapha. -Original Message- From: Pce On Behalf Of Dhruv Dhody Sent: Wednesday, February 6, 2019 8:40 AM To: pce@ietf.org Subject: Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing Hi WG, I wanted to clarify the context for the mail. We added the quoted text (see below mail) to allow backward compatibility with older implementations of this draft (which did not follow the later changes reflected in RFC 8408). The IESG has however pointed out that our proposal does not meet the expectation for a Standard Track document (c.f. "It is inappropriate to use Internet-Drafts as reference material" from the boilerplate). It is the expectation that any pre-standards implementations needs to figure out a way forward and comply with the standard. We need to resolve this IESG discuss to allow this document to move forward. Please reply on the mailing list or send mail to pce-cha...@ietf.org, if removing this text is an issue for you with your reasons. The last date is extended to 13th Feb to accommodate for the Lunar New Year break (Happy year of the Pig!) Thanks! Dhruv (for the PCE chairs) On Sat, Feb 2, 2019 at 8:49 AM Dhruv Dhody wrote: > > Hi WG, > > To accommodate earlier implementations of PCEP-SR (before the path > setup type capability exchange was changed), we added this text to > allow backward compatibility with older versions - > > > https://tools.ietf.org/html/draft-ietf-pce-segment-routing-14#section- > 7 > >Some implementations, which are compliant with an earlier version of >this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in >their OPEN objects. Instead, to indicate that they support SR, these >implementations include the SR-CAPABILITY-TLV as a top-level TLV in >the OPEN object. Unfortunately, some of these implementations made >it into the field before this document was published in its final >form. Therefore, if a PCEP speaker receives an OPEN object in which >the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST >interpret this as though the sender had sent a PATH-SETUP-TYPE- >CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and >SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub- >TLV. If a PCEP speaker receives an OPEN object in which both the SR- >CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level >TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process >only the PATH-SETUP-TYPE-CAPABILITY TLV. > > It has been a while since RFC8408 was published and this document > updated, and you might have already updated your implementations to > the latest standard. > > - Are there any older implementations, still in the field that needs > to inter-operate with other pcep speakers that are running the latest > standard? > - If yes, can they be patched to latest standard in a planned manner, > without impacting the network operations? > - Please shout out the impact if the above text is removed. > - Further, if you have a valid rationale to keep the text, would you > be fine with changing MUST to SHOULD in the text? > > Please respond by 8th Feb. You may choose to reply directly to the > chairs/AD instead of mailing list if you wish. > > Thanks! > Dhruv (for the PCE chairs)
[Pce] FW: New Version Notification for draft-ietf-pce-segment-routing-15.txt
Hi PCE WG This new version of the PCEP segment routing draft resolves all of the comments that we received during IESG review, except for the issue concerning the necessity of the backwards compatibility section, which is still pending. Cheers Jon -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, 12 February, 2019 10:53 AM To: Wim Henderickx ; Siva Sivabalan ; Jonathan Hardwick ; Jonathan Hardwick ; Jeff Tantsura ; Clarence Filsfils Subject: New Version Notification for draft-ietf-pce-segment-routing-15.txt NOTE: Message is from an external sender A new version of I-D, draft-ietf-pce-segment-routing-15.txt has been successfully submitted by Jon Hardwick and posted to the IETF repository. Name: draft-ietf-pce-segment-routing Revision: 15 Title: PCEP Extensions for Segment Routing Document date: 2019-02-12 Group: pce Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-15.txt Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ Htmlized: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-15 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-15 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link- state Interior Gateway Protocols (IGPs). A Segment Routing Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. 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-segment-routing-15.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 WG of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Clarence Filsfils Jeff Tantsura Wim Henderickx Jon Hardwick Filename: draft-ietf-pce-segment-routing-15.txt Pages : 33 Date: 2019-02-12 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link- state Interior Gateway Protocols (IGPs). A Segment Routing Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-15 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-15 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] Adoption poll for draft-lee-pce-flexible-grid
Hi Adrian, Yes/Support (as co-author). BR, Ricard On 5/2/2019 15:16, Adrian Farrel wrote: Hi WG, Please read and review draft-lee-pce-flexible-grid-03 and send your comments to the mailing list. Should we adopt it? Why / why not? What needs to be fixed before/after adoption? Is this a draft you would be willing to work on? Do you plan to implement? This poll will run until 20th February. Thanks, PCE Chairs ___ 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
Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid
Hi Adrian, all I support the adoption of the draft (as co-author); We do need a way to specify constraints in the RSA using PCEP. I plan to implement at least the core objects and TLVs to allow a flexi-grid SA, and being able to constrain e.g. the (n,m) for a given computation Regards Ramon On 12/02/2019 9:19, Daniele Ceccarelli wrote: Hi Adrian, Yes i support the adoption of the document. This is needed to complete the work done by CCAMP on flexi grid. Thanks, Daniele -Original Message- From: Pce On Behalf Of Italo Busi Sent: den 11 februari 2019 17:10 To: pce@ietf.org Subject: Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid Hi Adrian, PCE WG, Yes/Support. We have a plan for implementation for this. I think this work is useful and complementary to the on-going work in CCAMP to cover the cases where networks are using PCEP Italo -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, February 5, 2019 8:16 AM To: pce@ietf.org Subject: [Pce] Adoption poll for draft-lee-pce-flexible-grid Hi WG, Please read and review draft-lee-pce-flexible-grid-03 and send your comments to the mailing list. Should we adopt it? Why / why not? What needs to be fixed before/after adoption? Is this a draft you would be willing to work on? Do you plan to implement? This poll will run until 20th February. Thanks, PCE Chairs ___ 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 mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce -- Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://networks.cttc.es/ons CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid
Hi Adrian, Yes i support the adoption of the document. This is needed to complete the work done by CCAMP on flexi grid. Thanks, Daniele -Original Message- From: Pce On Behalf Of Italo Busi Sent: den 11 februari 2019 17:10 To: pce@ietf.org Subject: Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid Hi Adrian, PCE WG, Yes/Support. We have a plan for implementation for this. I think this work is useful and complementary to the on-going work in CCAMP to cover the cases where networks are using PCEP Italo -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, February 5, 2019 8:16 AM To: pce@ietf.org Subject: [Pce] Adoption poll for draft-lee-pce-flexible-grid Hi WG, Please read and review draft-lee-pce-flexible-grid-03 and send your comments to the mailing list. Should we adopt it? Why / why not? What needs to be fixed before/after adoption? Is this a draft you would be willing to work on? Do you plan to implement? This poll will run until 20th February. Thanks, PCE Chairs ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
