[Pce] I-D Action: draft-ietf-pce-lsp-control-request-04.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 : Ability for a stateful Path Computation Element (PCE) to request and obtain control of a LSP Authors : Aswatnarayan Raghuram Al Goddard Chaitanya Yadlapalli Jay Karthik Siva Sivabalan Jon Parker Mahendra Singh Negi Filename: draft-ietf-pce-lsp-control-request-04.txt Pages : 11 Date: 2019-06-04 Abstract: The stateful Path Computation Element (PCE) communication Protocol (PCEP) extensions provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where a Path Computation Client (PCC) delegates control over one or more locally configured LSPs to a stateful PCE. There are use-cases in which a stateful PCE may wish to request and obtain control of one or more LSPs from a PCC. This document describes a simple extension to stateful PCEP to achieve such an objective. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-04 https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-control-request-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-04 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
[Pce] I-D Action: draft-ietf-pce-association-diversity-07.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 : Path Computation Element communication Protocol (PCEP) extension for signaling LSP diversity constraint Authors : Stephane Litkowski Siva Sivabalan Colby Barth Mahendra Singh Negi Filename: draft-ietf-pce-association-diversity-07.txt Pages : 22 Date: 2019-06-04 Abstract: This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP) with the purpose of computing diverse paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PCE that a particular LSP belongs to a disjoint-group, thus the PCE knows that LSPs in the same group needs to be disjoint from each other. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-diversity-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-07 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
[Pce] I-D Action: draft-ietf-pce-stateful-path-protection-05.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 Associating Working and Protection LSPs with Stateful PCE Authors : Hariharan Ananthakrishnan Siva Sivabalan Colby Barth Raveendra Torvi Ina Minei Edward Crabbe Mahendra Singh Negi Filename: draft-ietf-pce-stateful-path-protection-05.txt Pages : 16 Date: 2019-06-04 Abstract: A stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering Label Switched Paths (MPLS LSP). Furthermore, it is also possible for a stateful PCE to create, maintain, and delete LSPs. This document describes PCEP extension to associate two or more LSPs to provide end-to-end path protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-05 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-path-protection-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-path-protection-05 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] Chair review of draft-ietf-pce-association-diversity
Hi, Thanks for making the update (-07). Just one more nit in the update - https://tools.ietf.org/html/draft-ietf-pce-association-diversity-07 Section 4.1 As per [I-D.ietf-pce-association-group], LSPs are associated with other LSPs with which they interact by adding them to a common association group. The Association parameters, as described in [I-D.ietf-pce-association-group] as the combination of the mandatory fields Association type, Association ID and Association Source in the ASSOCIATION object, that uniquely identify the association group belonging to this association. Not sure about "belonging to this association". I feel we should just stop at "that uniquely identify the association group." Thanks, Dhruv On Thu, May 16, 2019 at 4:41 PM Dhruv Dhody wrote: > > Hi Authors, > > I did a chair's review of the I-D. Expect a separate shepherd review from > Julien. A little effort needs to be made by the authors to make this I-D > crisp. > > (1) Section 3, discussion related to SVEC feels incorrect inside a section > called 'Motivation'. Lets create a new section (I made minor changes) - > > Relationship to SVEC > >[RFC5440] defines a mechanism for the synchronization of a set of >path computation requests by using the SVEC (Synchronization VECtor) >object, that specifies the list of synchronized requests that can >either be dependent or independent. The SVEC object identify the >relationship between the set of path computation requests, identified >by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] >further clarified the use of the SVEC list for synchronized path >computations when computing dependent requests as well as described a >number of usage scenarios for SVEC lists within single-domain and >multi-domain environments. > >The SVEC object includes a Flags field that indicates the potential >dependency between the set of path computation request in a similar >way as the Flags field in the TLVs defined in this document. The >path computation request in the PCReq message MAY use both SVEC and >ASSOCIATION object to identify the related path computation request >as well as the diversity association group. The PCE MUST try to find a >path that meets both the constraints. It is possible that the >diversity requirement in the association group is different from the one >in SVEC object. The PCE would consider both the objects as per the >processing rules and aim to find a path that meets both these constraints. >In case no such path is possible (or the constraints are incompatible), >the PCE MUST send a path computation reply (PCRep) with NO-PATH object >indicating path computation failure as per [RFC5440]. > > (2) Section 3, I am not sure about this - > >Using the disjoint-group within a PCEP messages may have two purpose: > >o Information: in case the PCE is performing the path computation, > it may communicate to the PCC the disjoint parameters. > >o Configuration: in case the PCC are configured with disjoint > requirements, these are communicated to the PCE. > > This feels incomplete as it singles out information from PCE to PCC and > configuration at PCC. Maybe better to re-word along our TLVs - where the > disjoint status is included by PCE but configuration is included by both. > > (3) Section 4.1, >But a PCE may be limited >in how many LSPs it can take into account when computing >disjointness. If a PCE receives more LSPs in the group than it can >handle in its computation algorithm, it SHOULD apply disjointness >computation to only a subset of LSPs in the group. The subset of >disjoint LSPs will be decided by PCE as a local matter. > > You then say > >Local polices on the PCC or PCE MAY define the computational behavior >for the other LSPs in the group. For example, the PCE may provide no >path, a shortest path, or a constrained path based on relaxing >disjointness, etc. > > Better to merge the above with the previous paragraph and also include some > text on the disjoint status information. > > (4) Section 4.2, > > * P (Shortest path) bit: when set, this indicates that the > computed path of the LSP SHOULD satisfies all constraints and > objective functions first without considering the diversity > constraint. This means that an LSP with P flag set should be > placed as if the disjointness constraint has not been > configured, while the other LSP in the association with P flag > unset should be placed by taking into account the disjointness > constraint. Setting P flag changes the relationship between > LSPs to a unidirectional relationship (LSP 1 with P=0 depends > of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP 1 > with P=0). > > Instead of unidirectional, maybe one-sided r
Re: [Pce] Chair review of draft-ietf-pce-stateful-path-protection
Hi Mahendra,
Thanks for making the update (-05). I see a few non-blocking issues that can
handled later.
https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-05
(1) You added -
[RFC8051] describes
applicability of Path protection in PCE deployment.
I suggest change this to -
[RFC8051] describes
applicability of path protection for stateful PCE deployments.
(2) Add a space between "Report" and "(" in "Report(PCRpt) message", similarly
for "Report(PCRpt) message" and "Initiate(PCInitiate) message"
(3) Number of authors is still an issue that needs to be handled, either by
reducing the number of co-authors or providing a justification. Please do so
before we ship this out of the WG.
Thanks for handling my other comments.
Thanks,
Dhruv
On Thu, May 16, 2019 at 4:41 PM Dhruv Dhody wrote:
>
> Hi Authors,
>
> I did a chair's review of the I-D. Expect a separate shepherd review from
> Julien. I found minor issues that can be easily fixed.
>
> (1) The issue with number of authors on the front page is bound to come up,
> either provide valid justification to your shepherd or reduce to 5.
>
> (2) Add reference to RFC8051 in introduction, which had a section on
> protection.
>
> (3) It would be good to explicitly state that in PCE-initiated LSPs case, the
> association group is created by PCE.
>
> (4) Section 4.1.
>
> OLD:
>During state synchronization, a PCC MUST report all the existing path
>protection association groups as well as any path protection flags to
>PCE(s) as per [I-D.ietf-pce-association-group].
> NEW:
>During state synchronization, a PCC report all the existing LSP state as
>described in [RFC8231], the the association group membership pertaining to
>a LSP is also reported as per [I-D.ietf-pce-association-group]. This
>includes PPAG.
> END
>
> Nits
>
> s/Path Computation Element Protocol (PCEP)/Path Computation Element
> communication Protocol (PCEP)/
> s/between one a pair of PCEs/between a pair of PCEs/
> s/Stateful pce/Stateful PCE/
> s/Path Protection Association Object Type/Path Protection Association Type/
> s/[A|a]ssociation-type/Association type/
> Section 4.4, extra "." at the end.
> Section 4.5, closing braces missing, end of 2nd paragraph.
> Expand on 1st use - PCRpt, PCUpd, PCInitiate...
>
> Regards,
> Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG LC prep for draft-ietf-pce-lsp-control-request
Hi, Thanks for the posting the update (-04) with the Implementation Status. https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-04#section-5 I see the number of co-authors is not resolved, but that's okay, just do so before we ship the document out of the WG. We will start the WG LC and IPR poll shortly. Thanks, Dhruv On Fri, May 17, 2019 at 3:24 PM Dhruv Dhody wrote: > > Hi Authors, > > In preparation for WG LC for this I-D, please update the document to > include the 'Implementation Status' Section as per the new > implementation policy [1]. > > You also have 7 authors, we usually limit to 5 on front page and rest > as contributors [2]. > > Hari is assigned as the document shepherd for this I-D. > > There are no IPR declared on this I-D. We will start the IPR poll > along with WGLC to reconfirm. > > Please feel free to reach out if you have any questions/concerns. > > -- > > Hi WG, > > You don't have to wait for the official WGLC, add this I-D in your > review queue and please provide comments! > > Thanks! > Dhruv, Julien & Adrian > > [1] "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." > [2] https://tools.ietf.org/html/rfc7322#section-4.1.1 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] WG LC for draft-ietf-pce-lsp-control-request-04
Hi WG, This email starts a working group last call for draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till 19th June 2019. https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ Please indicate your support or concern for this draft. If you are opposed to the progression of the draft, please articulate your concern. If you support, please indicate that you have read the latest version and it is ready for publication. Further, explaining the importance of the work in your opinion is appreciated. As always, review comments and nits are most welcome. Silence on the list, not so much :) Thanks, Dhruv, Julien, & Adrian ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] IPR poll on draft-ietf-pce-lsp-control-request-04
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
Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04
Yes/support Regards, Jeff > On Jun 4, 2019, at 20:26, Dhruv Dhody wrote: > > Hi WG, > > This email starts a working group last call for > draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till > 19th June 2019. > > https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/ > > Please indicate your support or concern for this draft. > > If you are opposed to the progression of the draft, please articulate your > concern. > > If you support, please indicate that you have read the latest version and > it is ready for publication. Further, explaining the importance of the work in > your opinion is appreciated. > > As always, review comments and nits are most welcome. Silence on the list, not > so much :) > > Thanks, > Dhruv, Julien, & Adrian > > ___ > 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
