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

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Oct 2011 15:10:33 +0200

> Hi all,

Hi, 

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

According to [RFC5654], 
"Associated bidirectional path: A path that supports traffic flow in
both directions but that is constructed from a pair of unidirectional
paths (one for each direction) that are associated with one another
at the path's ingress/egress points.  The forward and backward
directions are setup, monitored, and protected independently.  As a
consequence, they may or may not follow the same route (links and
nodes) across the network."

>From PCEP protocol point the Concurrent computation for Single Sided
Provisioning model can be achieved with the following options: 
  - SVEC request containing one request for the forward direction and 
    one request for the reverse direction (forward and reverse path MAY
    be different) 
  - One bidirectional request using GENERALIZED-BANDWIDTH with forward 
    and reverse bandwidth if both direction must follow the same path 
    and have same other properties
    
This cover the requirements you are describing, I do not see the need for
PCEP extensions.

One thing that could be considered (As far as I remember it was also raised 
for backup ingress and egress draft) is that the SVEC only allows to compute
diverse route but there is no indication that one desire sharing of links,
node (SRLGS?) for synchronized requests.

BR 

> Thanks
> Wenjuan

---

From: [email-masked]
Date: Tue, 25 Oct 2011 19:11:35 +0800

Hi cyril,

Thanks for your comments, you catch the essence immediately. :-) 

For the first comment,-Yeah, the SVEC object can be used to synchronize 
the request about the forward and backward LSPs, and it is a more general 
method.

As to the second comment, I also agree that GENERALIZED-BANDWIDTH with 
forward and reverse bandwidth and the "B" bit set in the RP object can be 
used since associated or co-routed is the same in the data plane. 

But consider the usecase that only the forward and backward's bandwidths 
is specified, and there is no need to limit them to be co-routed. I think 
another bit "A" defined in the RP ojbect will be useful, for the encoding 
efficiency will be higher than using the method based on the "SVEC" 
object. What do you think?

The third comment,
-If we want to support the sharing of links,node, SRLG for synchronized 
requests, this can be realized by two methods:
  a)the IRO object can be used to carry the same link or node, but the 
SRLG is not supported;
  b)extend one tlv to specify the sharing link,node or SRLG in the SVEC 
object.
Just my two comments, do you think there are requirements or usecases 
about supporting the sharing SRLG?

Your comments on this are most welcome.

Thanks 

Wenjuan 

Hi, 

Hi, 

According to [RFC5654], 

One thing that could be considered (As far as I remember it was also 
raised 
for backup ingress and egress draft) is that the SVEC only allows to 
compute
diverse route but there is no indication that one desire sharing of links,
node (SRLGS?) for synchronized requests.

BR