Re: reverse-lsp

[MATSUURA Nobuaki <matsuura.nobuaki@lab.ntt.co.jp>]

Hi Dimitri,

In the context of mpls, a receiver of data traffic is responsible for the label allocation.
So I think it is rapid and sure to initiate a setup of an lsp from the receiver's side, 
especially in a situation where the label availability is subject to dynamical change,

On the definition of "null" label set, your point taken.
For example, is "an inclusive list containing only a null label" OK?

 -Nobuaki


Dimitri.Papadimitriou@alcatel.be wrote:
>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