Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
Hi, Yes/support (as a co-author). Thanks, Rakesh On Thu, Jan 5, 2017 at 10:24 AM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote: > All, > > > > This is start of a two week poll on making > draft-dhody-pce-stateful-pce-auto-bandwidth-09 > a PCE working group document. > > https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pc > e-auto-bandwidth/ > > > > Please review the draft and send an email to the list indicating > “yes/support” or “no/do not support”. If indicating no, please state your > reasons. If yes, please also feel free to provide comments you'd like to > see addressed once the document is a WG document. > > > > The poll ends on Thursday January 19. > > > > Thanks, > > Jon, JP and Julien > > > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
Hi Yes/support (co-author). Regards Ravi From: Rakesh Gandhi [mailto:rgandhi.i...@gmail.com] Sent: Friday, January 6, 2017 2:25 PM To: Jonathan Hardwick ; luyu...@gmail.com; Ravi Singh ; udayasree.pa...@huawei.com; Dhruv Dhody ; leeyo...@huawei.com; Zhangxian (Xian) ; kin...@tencent.com Cc: pce@ietf.org; pce-cha...@ietf.org; draft-dhody-pce-stateful-pce-auto-bandwi...@ietf.org Subject: Re: Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09 Hi, Yes/support (as a co-author). Thanks, Rakesh On Thu, Jan 5, 2017 at 10:24 AM, Jonathan Hardwick mailto:jonathan.hardw...@metaswitch.com>> wrote: All, This is start of a two week poll on making draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document. https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/ Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Thursday January 19. Thanks, Jon, JP and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-ietf-pce-pce-initiated-lsp
Hi Aaron, Thank for you comment. As you point out, the current I-D has taken a timer-based approach: - while State Timeout is not expired, decision is at the PCE level, any PCE with ID knowledge may claim control (not necessarily granted); - once State Timeout is expired, the PCC gets the decision. What you are proposing could be a valuable enhancement, but at this stage we would prefer to send this version that has been there and implemented for a while. As a result, your proposal would deserve a new extension draft, focusing on take-over negotiation, which could be discussed with the WG. Please feel free to proceed. Best regards, Julien Jan. 05, 2017 - aitsk...@cisco.com: > Hi Jon, > > Thanks for your reply. > My interpretation of the following section of the existing > draft-ietf-pce-pce-initiated-lsp is > that PCC cannot just re-delegate PCE initiated LSP to a PCE. > > > >In case of PCEP session failure, control over PCE-initiated LSPs >reverts to the PCC at the expiration of the redelegation timeout. At >this point, the LSP is an "orphan" until the expiration of the State >Timeout timer. To obtain control of a PCE-initiated LSP, a PCE >(either the original or one of its backups) sends a PCInitiate >message, including just the SRP and LSP objects, and carrying the >PLSP-ID of the LSP it wants to take control of. Receipt of a >PCInitiate message with a non-zero PLSP-ID normally results in the >generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT >generate an error and MUST redelegate the LSP to the PCE. The State >Timeout timer for the LSP is stopped upon the re-delegation. > > > I read it as PCC is not free to delegate PCE initiated LSP even in > orphan state, > it rather waits (using State Timer) for other PCE server to "adopt" such > "orphan" LSP. > This behavior is different for the PCE initiated LSPs vs PCC initiated > LSPs. > Hence my suggestion was a mechanism that will help redundant PCE servers to > discover PCE initiated LSPs that enter "orphan" state and trigger > "adoption" > process which is different then the just re-delegation. > > Thanks > Aaron > > > On 2017-01-05 11:25 AM, Jonathan Hardwick wrote: >> Hi Aaron >> >> Thanks for the comment. There are no procedures defined that would >> allow a PCE to initiate a take-over of an LSP from a PCC. Rather, the >> PCC must delegate the LSP to an appropriate PCE (if the LSP is >> initiated by a PCE then it must initially be delegated to that PCE). >> The cases you mention would be resolved by the PCC making a local >> decision whether or not to re-delegate the LSP to an alternative PCE. >> >> So, I am not sure that the "orphan" flag would be useful to the PCE, >> at least not for the purpose that you describe. >> >> Best regards >> Jon >> >> >> -Original Message- >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aaron Itskovich >> Sent: 04 January 2017 20:08 >> To: pce@ietf.org >> Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp >> >> >> I suggest to add indication that PCE Initiated LSP is orphan to LSP >> object in PCReport message. This information will be useful in >> facilitating takeover of an orphan LSP by redundant PCE server. >> >> Option 1) Adding bit to the LSP flags (L-bit "parentless/orphan") that >> will be set in the LSP object of the PCReport message sent when PCE >> Initiated LSP becomes orphan as result of connection loss to the PCE >> server that initiated this LSP or because such PCE server returns LSP >> delegation to the PCC to initiate transfer of LSP "ownership" to >> another PCE server. >> >> Option 2) Adding bit to the LSP flags (D2-bit ) that is set when such >> LSP is delegated to any PCE server. In this option PCE receiving >> report will be able to derive when PCE Initiated LSP is in orphan >> state when C flag in the report is set and the new D2-bit is not set. >> >> >> This proposal (regardless which option 1 or 2 is used ) alows PCC to >> propagate "orphan" state for the PCE initiated LSP to all PCE servers. >> It will help to trigger takeover of a PCE initiated LSP. The existing >> alternative is to rely on the PCE server to server communication for >> detection of such events which is prone to errors. >> >> For example: >> >> - loss of communication between PCE-A and PCE-B may be >> interpreted as "takeover" trigger which is not necessarily true as >> PCE-A<->PCC connection may still be up. >> - In case where PCE-A <-> PCC connection is down and both PCC >> <-> PCE-B and PCE-A <-> PCE-B connections are up we will need each >> PCE server to distribute information about connection with it's >> clients to all peers >> >> The suggestion frees PCE server from the need to propagate it's client >> connection status to all other PCE servers. >> >> Let me know what you think >> >> Thanks >> Aaron >> >> ___ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/ma
Re: [Pce] draft-ietf-pce-pce-initiated-lsp
Hi Aaron Thanks. So actually, I need to backtrack and agree that there is a mechanism defined for a backup PCE to request that an orphaned LSP is delegated to it - I had missed that. I am not sure that this implies that the PCC cannot re-delegate of its own free will. It would be useful to have that clarified in the draft. However, given this mechanism exists, it does raise the question about how PCEs should properly cooperate in terms of how orphaned LSPs are detected and who should request ownership. I know that there is work ongoing in the following draft which discusses co-operation between redundant PCEs. I am not sure whether your idea is best discussed in the context of that draft or in draft-ietf-pce-pce-initiated-lsp. Perhaps the authors could chime in? https://tools.ietf.org/id/draft-litkowski-pce-state-sync-00.txt Best regards Jon -Original Message- From: Aaron Itskovich [mailto:aitsk...@cisco.com] Sent: 05 January 2017 19:30 To: Jonathan Hardwick ; pce@ietf.org Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp Hi Jon, Thanks for your reply. My interpretation of the following section of the existing draft-ietf-pce-pce-initiated-lsp is that PCC cannot just re-delegate PCE initiated LSP to a PCE. In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. At this point, the LSP is an "orphan" until the expiration of the State Timeout timer. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. Receipt of a PCInitiate message with a non-zero PLSP-ID normally results in the generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT generate an error and MUST redelegate the LSP to the PCE. The State Timeout timer for the LSP is stopped upon the re-delegation. I read it as PCC is not free to delegate PCE initiated LSP even in orphan state, it rather waits (using State Timer) for other PCE server to "adopt" such "orphan" LSP. This behavior is different for the PCE initiated LSPs vs PCC initiated LSPs. Hence my suggestion was a mechanism that will help redundant PCE servers to discover PCE initiated LSPs that enter "orphan" state and trigger "adoption" process which is different then the just re-delegation. Thanks Aaron On 2017-01-05 11:25 AM, Jonathan Hardwick wrote: > Hi Aaron > > Thanks for the comment. There are no procedures defined that would allow a > PCE to initiate a take-over of an LSP from a PCC. Rather, the PCC must > delegate the LSP to an appropriate PCE (if the LSP is initiated by a PCE then > it must initially be delegated to that PCE). The cases you mention would be > resolved by the PCC making a local decision whether or not to re-delegate the > LSP to an alternative PCE. > > So, I am not sure that the "orphan" flag would be useful to the PCE, at least > not for the purpose that you describe. > > Best regards > Jon > > > -Original Message- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aaron Itskovich > Sent: 04 January 2017 20:08 > To: pce@ietf.org > Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp > > > I suggest to add indication that PCE Initiated LSP is orphan to LSP object in > PCReport message. This information will be useful in facilitating takeover of > an orphan LSP by redundant PCE server. > > Option 1) Adding bit to the LSP flags (L-bit "parentless/orphan") that will > be set in the LSP object of the PCReport message sent when PCE Initiated LSP > becomes orphan as result of connection loss to the PCE server that initiated > this LSP or because such PCE server returns LSP delegation to the PCC to > initiate transfer of LSP "ownership" to another PCE server. > > Option 2) Adding bit to the LSP flags (D2-bit ) that is set when such LSP is > delegated to any PCE server. In this option PCE receiving report will be able > to derive when PCE Initiated LSP is in orphan state when C flag in the report > is set and the new D2-bit is not set. > > > This proposal (regardless which option 1 or 2 is used ) alows PCC to > propagate "orphan" state for the PCE initiated LSP to all PCE servers. > It will help to trigger takeover of a PCE initiated LSP. The existing > alternative is to rely on the PCE server to server communication for > detection of such events which is prone to errors. > > For example: > > - loss of communication between PCE-A and PCE-B may be interpreted as > "takeover" trigger which is not necessarily true as PCE-A<->PCC connection > may still be up. > - In case where PCE-A <-> PCC connection is down and both PCC > <-> PCE-B and PCE-A <-> PCE-B connections are up we will need each > PCE server to distribute information about connection with it's > clients to all peers > > The sug
Re: [Pce] draft-ietf-pce-pce-initiated-lsp
Hi, This topic was tackled a while ago in the context of draft-ietf-pce-pce-initiated-lsp: https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE It looks like the I-D would benefit from clarification on this matter before sending it to the IESG. Authors, what to do you think? Aaron (Cyril?), while keeping feature extensions for another document (cf. Dhruv's proposal), would you have some clarification text to propose here? Thanks, Julien Jan. 09, 2017 - jonathan.hardw...@metaswitch.com: > Hi Aaron > > Thanks. So actually, I need to backtrack and agree that there is a mechanism > defined for a backup PCE to request that an orphaned LSP is delegated to it - > I had missed that. > > I am not sure that this implies that the PCC cannot re-delegate of its own > free will. It would be useful to have that clarified in the draft. > > However, given this mechanism exists, it does raise the question about how > PCEs should properly cooperate in terms of how orphaned LSPs are detected and > who should request ownership. I know that there is work ongoing in the > following draft which discusses co-operation between redundant PCEs. I am > not sure whether your idea is best discussed in the context of that draft or > in draft-ietf-pce-pce-initiated-lsp. Perhaps the authors could chime in? > https://tools.ietf.org/id/draft-litkowski-pce-state-sync-00.txt > > Best regards > Jon > > > -Original Message- > From: Aaron Itskovich [mailto:aitsk...@cisco.com] > Sent: 05 January 2017 19:30 > > Hi Jon, > > Thanks for your reply. > My interpretation of the following section of the existing > draft-ietf-pce-pce-initiated-lsp is that PCC cannot just re-delegate PCE > initiated LSP to a PCE. > > > > In case of PCEP session failure, control over PCE-initiated LSPs > reverts to the PCC at the expiration of the redelegation timeout. At > this point, the LSP is an "orphan" until the expiration of the State > Timeout timer. To obtain control of a PCE-initiated LSP, a PCE > (either the original or one of its backups) sends a PCInitiate > message, including just the SRP and LSP objects, and carrying the > PLSP-ID of the LSP it wants to take control of. Receipt of a > PCInitiate message with a non-zero PLSP-ID normally results in the > generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT > generate an error and MUST redelegate the LSP to the PCE. The State > Timeout timer for the LSP is stopped upon the re-delegation. > > > I read it as PCC is not free to delegate PCE initiated LSP even in orphan > state, it rather waits (using State Timer) for other PCE server to "adopt" > such "orphan" LSP. > This behavior is different for the PCE initiated LSPs vs PCC initiated LSPs. > Hence my suggestion was a mechanism that will help redundant PCE servers to > discover PCE initiated LSPs that enter "orphan" state and trigger "adoption" > process which is different then the just re-delegation. > > Thanks > Aaron > > > On 2017-01-05 11:25 AM, Jonathan Hardwick wrote: >> Hi Aaron >> >> Thanks for the comment. There are no procedures defined that would allow a >> PCE to initiate a take-over of an LSP from a PCC. Rather, the PCC must >> delegate the LSP to an appropriate PCE (if the LSP is initiated by a PCE >> then it must initially be delegated to that PCE). The cases you mention >> would be resolved by the PCC making a local decision whether or not to >> re-delegate the LSP to an alternative PCE. >> >> So, I am not sure that the "orphan" flag would be useful to the PCE, at >> least not for the purpose that you describe. >> >> Best regards >> Jon >> >> >> -Original Message- >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aaron Itskovich >> Sent: 04 January 2017 20:08 >> To: pce@ietf.org >> Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp >> >> >> I suggest to add indication that PCE Initiated LSP is orphan to LSP object >> in PCReport message. This information will be useful in facilitating >> takeover of an orphan LSP by redundant PCE server. >> >> Option 1) Adding bit to the LSP flags (L-bit "parentless/orphan") that will >> be set in the LSP object of the PCReport message sent when PCE Initiated LSP >> becomes orphan as result of connection loss to the PCE server that initiated >> this LSP or because such PCE server returns LSP delegation to the PCC to >> initiate transfer of LSP "ownership" to another PCE server. >> >> Option 2) Adding bit to the LSP flags (D2-bit ) that is set when such LSP is >> delegated to any PCE server. In this option PCE receiving report will be >> able to derive when PCE Initiated LSP is in orphan state when C flag in the >> report is set and the new D2-bit is not set. >> >> >> This proposal (regardless which option 1 or 2 is used ) alows PCC to >> propagate "orphan" state for the PCE initiated LSP to all PCE servers. >> It will help to trigger takeover of a PCE init
[Pce] I-D Action: draft-ietf-pce-association-group-02.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 of the IETF. Title : PCEP Extensions for Establishing Relationships Between Sets of LSPs Authors : Ina Minei Edward Crabbe Siva Sivabalan Hariharan Ananthakrishnan Xian Zhang Yosuke Tanaka Filename: draft-ietf-pce-association-group-02.txt Pages : 13 Date: 2017-01-09 Abstract: This document introduces a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of a stateful PCE as well as a stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-association-group-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-02 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] FW: New Version Notification for draft-ietf-pce-association-group-02.txt
Hi, PCErs, Just refresh the date to keep it alive. We would like to move this draft forward since this the base draft for many other drafts. So, please review this draft and let us know if you have any comments/suggestions. Cheers, Xian on behalf of the authors/contributors -邮件原件- 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 发送时间: 2017年1月10日 8:34 收件人: Siva Sivabalan ; Yosuke Tanaka ; Zhangxian (Xian) ; Hariharan Ananthakrishnan ; Edward Crabbe ; Ina Minei 主题: New Version Notification for draft-ietf-pce-association-group-02.txt A new version of I-D, draft-ietf-pce-association-group-02.txt has been successfully submitted by Xian Zhang and posted to the IETF repository. Name: draft-ietf-pce-association-group Revision: 02 Title: PCEP Extensions for Establishing Relationships Between Sets of LSPs Document date: 2017-01-09 Group: pce Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-pce-association-group-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ Htmlized: https://tools.ietf.org/html/draft-ietf-pce-association-group-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-02 Abstract: This document introduces a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of a stateful PCE as well as a stateless PCE. 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] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
Yes/Support From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: 06 January 2017 17:21 To: Jonathan Hardwick Cc: draft-dhody-pce-stateful-pce-auto-bandwi...@ietf.org; pce@ietf.org; pce-cha...@ietf.org Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09 Yes/Support. Regards, Dhruv (as co-author) On Thu, Jan 5, 2017 at 8:54 PM, Jonathan Hardwick mailto:jonathan.hardw...@metaswitch.com>> wrote: All, This is start of a two week poll on making draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document. https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/ Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Thursday January 19. Thanks, Jon, JP and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
