Subject: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00

From: [email-masked]
Date: Mon, 24 Oct 2011 17:36:20 +0800

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 computation can 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

---

From: Jan Medved <[email-masked]>
Date: Mon, 24 Oct 2011 11:21:23 -0700

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-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> 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。

Thanks
Wenjuan

---

From: [email-masked]
Date: Wed, 26 Oct 2011 09:56:24 +0800

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.

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. 

Your comments on this are most welcome.

Thanks

Wenjuan

Jan Medved <[email-masked]> 
2011-10-25 02:21

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
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-masked]<mailto:[email-masked]
>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

As described in 
sided provisioning, the path computationcan be

Thanks
Wenjuan

---

From: Jan Medved <[email-masked]>
Date: Wed, 26 Oct 2011 22:39:57 -0700

Hi Wenjuan,

Please see inline.

Thanks,
Jan

On 10/25/11 6:56 PM, "[email-masked]" <[email-masked]>
wrote:

>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

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.

>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.

>Jan Medved <[email-masked]>2011-10-25 02:21
>收件人
>"[email-masked]" <[email-masked]>,
>"[email-masked]" <[email-masked]>抄送
>主题
>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-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>> wrote:
>
>
>Hi all,
>http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>lsp-02,
>bidirectional
>LSP is optimal, as described in http://tools.ietf.org/html/rfc5557.

---

From: [email-masked]
Date: Sat, 29 Oct 2011 15:26:06 +0800

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?

Thanks

Wenjuan

2011-10-27 13:39

收件人

主题

Hi Wenjuan,

Please see inline.

Thanks,
Jan