The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

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

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.

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

> 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