Re: reverse-lsp

[Dimitri.Papadimitriou@alcatel.be]

hi,

in this i-d you have mentioned the following §:

"The signaling reverse-directional LSPs is used in three ways. 
In the first, it is used to establish a single reverse-
directional LSP. In the second, it can be used as parts of 
establishment of asymmetrical bidirectional LSPs. The final 
application is an alternative method for establishment of 
forward-directional LSPs, and it is an RSVP specific mechanism."

while i understand the second proposed way (even if its
applicability may be discussed) i don't understand why
cumulating a rsvp-te specific method with the first one
which seems to be "generic", you gave the explanation
that's may be due to ditto "For example, when a sender 
node does not have sufficient perspective of label 
(resource) availabilities along the route on which the 
LSP is set up, it may be an immediate and probable way 
to establish a forward-directional LSP from the sender's 
point of view." my question is why the receiver would 
have more label (resource) availabilities information ?
from this perspective it would be also good to expand
a little bit more on "Information required for the 
consequent Path message, except for an UPSTREAM_LABEL 
object, is enveloped in a POLICY_DATA object." in this
(g)mpls context

now from a processing viewpoint i have the following 
question when you write "Therefore, an initiator node 
sends a Path/Request messages including not only an 
Upstream Label but also a "null" Label Set object/TLV, 
i.e., a Label Set object/TLV which has label type of 0 
and no subchannel." to you mean by NULL a new "action" ?
do i correctly understand that the following processing
described in gmpls-sig section 2.5.1 "If the node is 
unable to pick a label from the Label Set or if there 
is a problem parsing the Label_Set objects, then the 
request is terminated and a PathErr message with a
"Routing problem/Label Set" indication MUST be generated."
should be adapted here ? 

thanks for your clarifications,
- dimitri.

MATSUURA Nobuaki wrote:
> 
> Hi all,
> 
> As you know, the upstream label has been introduced  originally to support
> bidirectional LSPs.
> I think that it can be used for even unidirectional LSPs and helps to
> reduce the setup latency.
> I have submitted a short document:
> 
> http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt
> 
> This scheme has new functional possibilities while keeps backward compatibility.
> There will be no big impact to existing implementations, if you already
> have the upstream label.
> 
> I'd like to here your comments.
> 
> Thanks,
> 
> -Nobuaki

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361