Hi Wenjuan, Please see inline.
Thanks, Jan On 10/25/11 6:56 PM, "[email protected]" <[email protected]> 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 <[email protected]>2011-10-25 02:21 >收件人 >"[email protected]" <[email protected]>, >"[email protected]" <[email protected]>抄送 >主题 >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, >"[email protected]<mailto:[email protected]>" ><[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
