Hi Wenjuan,
I do think that if the concern is encoding efficiency one point would be to state it in the objective in the document, but I think that introducing new objects to optimize one type of request is increasing the complexity of the protocol for a corner case. A more general optimization would be to bundle the common Request parameters only once, then the requests, there is certainly several possibility, One that come to my mind (just for example) is to defined a new type of endpoint, that would indicate that the objects in the requests are applicable to the other requests (it could be all requests if no SVEC is present, all request in the SVEC, ..etc) this would be more general, apply to any future extension and solve the requirement. For sharing within requests of the SVEC, the IRO cannot be used as-is, because the node and links are not known in advance by the PCC, the objective is to say : reuse the links you are calculating for the other request, so a kind of IRO containing the other request id, but this need more consideration. As pointed out for the stateful PCE, an association object could be considered, it might also be possible to use this association and state that resource reuse between LSP having the same association is desired. Best regards / Mit freundlichen Grüßen Cyril Margaria From: ext [email protected] [mailto:[email protected]] Sent: Tuesday, October 25, 2011 7:12 PM To: Margaria, Cyril (NSN - DE/Munich); [email protected] Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 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 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
