Hi Jan, Thanks for your valuable comments.
I am glad we have reached the agreement, the Association object will be introduced to PCEP, which can be used to optimizing the associated bidirectional lsp. For the Double Sided Provisioning model, the PCC submits the PCReq message with Association object, the stateful PCE will look up the reverse lsp indicated by the Association object. If the request of the reverse lsp does not arrive,the PCE will compute the path considering the present network. When the second request with the same Assoication Object arrives, the stateful PCE will know the two reverse lsps form the bidirectional LSP and compute the two reverse lsps again to get the optimal path for the associated bidirectional lsp. After the successful computation, the PCE responses the PCC with the PCRep message and updates the reverse lsp with PCUpd Message. If the backward path setup fail, the tail-end may send the PCReq message to the PCE to ask for a new backward path. The two reverse lsps will be computed again and created using make-before-break in the re-signaling operation, see section 6.2, http://tools.ietf.org/html/draft-crabbe-pce-stateful-pce-00. The Extended Association object is defined in the draft http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00. A new Association Type "associated bidirectional LSP" is introduced in another draft, http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02 . I think it is more applicable that the Association object is introduced in this draft. Because the Association object is used to bind the forward and the backward lsps, and I don't see the other scenario asking for the Association object. What do you think? Your comments on this are most welcome. Thanks Wenjuan Jan Medved <jmed...@juniper.net> 2011-10-27 13:39 收件人 "he.wenju...@zte.com.cn" <he.wenju...@zte.com.cn>, "pce@ietf.org" <pce@ietf.org> 抄送 主题 Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 Hi Wenjuan, Please see inline. Thanks, Jan On 10/25/11 6:56 PM, "he.wenju...@zte.com.cn" <he.wenju...@zte.com.cn> wrote: > >Hi Jan, > >Thanks for the comments, I think it >is really valuable. > >For the Double Sided Provisioning model, >although the head-end and the tail-end or NMS submit the PCReq message >separately, the two reverse lsps can be associated >to be optimal if stateful PCE is used. > > >The draft http://datatracker.ietf.org/doc/draft-crabbe-pce-stateful-pce/ >just say that all other LSP's condition can be considered if a new request >is submitted, however, we want to consider the two related LSPs together >(especially the TE parameters), at the same time all the other LSP's >condition >should be taken into consideration. The "all LSPs" set also covers the "two related LSPs" set. If a PCE knows about all LSPs in the network, it must about the forward and backward LSPs as well, and can consider them together. > >How about introducing the Association Object in this scenario? When the >PCC submits the path computation request for the forward lsp or the >backward lsp, the PCReq message may carry association object to indicate >that a reverse lsp is needed to be provided later. When >the second request with the same Assoication Object arrives, the stateful >PCE can compute the two reverse lsps again, and get the optimal path for >the associated bi-directional >lsp. After the successful computation, the PCE responses the PCC with the >PCRep message and updates the reverse lsp with PCUpd Message. The Association Object on a PCReq message would introduce implicit state into the PCE. Error conditions would be difficult to handle. For example, what would the PCE do with the Association Object if the second request (from the tail-end) never comes? The object would have to be flushed, but when? Or, can the PCE flush the Association Object after the computation of the backward path is done? It probably can't - the backward path set up may fail, and the tail-end PCC may come back to the PCE to ask for a new backward path. Another issue is that the computation of forward and backward LSPs can not be synchronized - as you pointed out, they should be computed together. That said, I think we will need the Association Object, but we will need it with the stateful PCE mechanisms described in draft-crabbe-pce-stateful-pce. Both the head-end and the tail-end PCCs sync up and delegate their respective LSPs (forward and backward) to the PCE using PCRpt messages. The PCE will compute the forward and backward paths and then, using PCUpd messages, will trigger the head-end to setup the forward LSP and the backend to trigger the setup of the backward LSP. The PCE will coordinate LSP setup in the head-end and the tail-end. We will need the Association Object during synchronization to tell the PCE that the forward LSP and the backward LSP are a part of the same bi-directional LSP. > >Your comments on this are most welcome. > >Thanks > >Wenjuan > > > > >Jan Medved <jmed...@juniper.net>2011-10-25 02:21 >收件人 >"he.wenju...@zte.com.cn" <he.wenju...@zte.com.cn>, >"pce@ietf.org" <pce@ietf.org>抄送 >主题 >Re: [Pce] [PCE] Request comments on >draft-he-pce-pcep-associated-lsp-extensions-00 > > > > >Hi Wenjuan, > >Double Sided Provisioning (Section 3.2) will require LSP setup >coordination >between the head-end and the tail-end, which will need to be provided >either >by a management system or a stateful PCE proposed in >draft-crabbe-pce-stateful-pce-00 >(http://datatracker.ietf.org/doc/draft-crabbe-pce-stateful-pce/). > > > >Thanks, >Jan > > >On 10/24/11 2:36 AM, >"he.wenju...@zte.com.cn<mailto:he.wenju...@zte.com.cn>" ><he.wenju...@zte.com.cn<mailto:he.wenju...@zte.com.cn>> wrote: > > >Hi all, >We've submitted a draft for the extensions of PCEP to support associated >bidirectional lsp, below is the link: >http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00. > >The MPLS-TP requirements [RFC5654] and control plane framework >documents[RFC6373]describe >that MPLS-TP MUST >support associated bidirectional point-to-point LSPs. Path Computation >Element (PCE), see [RFC4655], may be used for path >computation of a GMPLS LSP,and consequently an associated bidirectional >LSP, across domains and in a single domain. > >As described in >http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >lsp-02, >the associated bidirectional LSP can be deployed by Single Sided >Provisioning >model or Double Sided Provisioning >model.For the double sided provisioning, the path computation of the >forward >and the backward LSP >are submitted by the head-end and the tail-end separately.For the single >sided provisioning, the path computationcan be >realized by the concurrent or successive computation. The concurrent >computation means that the head-end submits the computation request >for both two directional LSPs concurrently. As to the successive >computation, the head-end and the tail-end send the forward LSP and >backward LSP computation requests separately. > >We have extended PCEP protocol to support the Concurrent computation for >Single Sided Provisioning model. >Concurrent computation can ensure that the paths for the associated >bidirectional >LSP is optimal, as described in http://tools.ietf.org/html/rfc5557. >In this draft， an A-bit is added to the flag bits of the RP object to >indicate the request is about an associated bidirectional LSP or not. >futhermore，REVERSE_LSP object is added in a PCReq message to specify >the information of the reverse LSP。 > > >Please provide comments and feedback. > >Thanks >Wenjuan >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
