The MPLS WG Archive

[Rohit Dube <rohit@xebeo.com>]

Adrian,

On Wed, 20 Nov 2002 19:21:01 -0500 "Adrian Farrel" writes:
=>> At the MPLS WG meeting, the question came up that GMPLS already
=>> supports bi-directional LSPs. As Rahul pointed out, this only
=>> works for generalized labels and not for "classical" labels.
=>
=>Perhaps Rahul can comment, but I don't think that is what he meant at all.
=>
=>What I heard him say (and what is factually correct) is that GMPLS only works
=>with the Generalized Label Object. These objects can perfectly well contain
=>"normal" 23 bit MPLS labels. The Generalized Label Request can ask for such
=>labels.

Yes this is what I meant. Sorry if it wasn't clear.

=>
=>His comment was that since some change is needed in the implementation to
=>support bidirectional labels it is of no consequence which change is made and
> so
=>you might as well move the Label Object and Label Request Object to be
=>Generalized.
=>
=>> Here is some further clarification on the topic.
=>>
=>> For classical mpls networks there are two ways of supporting
=>> bidirectional lsps. One method is to make the UPSTREAM_LABEL
=>> objects applicable to classic MPLS labels.
=>
=>They are already since the upstream label contains a generalized label and
=>generalized labels can contain MPLS labels.

Yes. But what I am trying to say is that an mpls implementation or
a network which uses one can move to supporting bi-directional lsps
in two ways. The one that I mentioned simply applies existing
operations to regular mpls labels. The alternate is what you mention.
Both are feasible and one doesn't exclude the other.

=>
=>> The other is to
=>> exchange "generalized" labels between nodes that want to
=>> support bidirectional LSPs while continuing with classical
=>> labels for uni-directional ones. The draft presented uses
=>> the former approach.
=>>
=>> While both approaches are valid, for nodes that run classical
=>> MPLS already and which need to support uni-directional as well
=>> as bi-directional LSPs, this seems to be the easier approach as
=>> the operator and the implementor need to deal with just one
=>> type of label.
=>
=>
=>I think at this point you really need to differentiate between label objects 
>and
=>the labels they carry.

????

=>
=>
=>> The -01 version of the draft proposes an UPSTREAM_FLOWSPEC
=>> object which allows for asymmetric bandwidth reservation
=>> by carrying the required information for the reverse path
=>> in the PATH message. The updated draft is available at
=>>
=>http://members.tripod.com/~rohit_dube/papers/draft-dube-bidirectional-lsp-01.
>txt
=>
=>Asymmetric bidirectional LSPs are a different matter altogether.
=>If there is a requirement for this, it should surely be moved to ccamp.

Sure I can deal with them separately. The reason why I mention them at
all wrt bi-directional lsps is that they make sense only when talking about
bi-directional lsps in the first place.

=>
=>> The updated version of the draft should appear on ietf's
=>> web-site when the draft queue starts getting processed again.
=>
=>I suggest you notify the ccmap WG of the existence of this draft and the
=>discussion on the MPLS list.
=>
=>Adrian
=>

--rohit.