The MPLS WG Archive

[Rahul Aggarwal <rahul@redback.com>]

Comments inline:

On Wed, Nov 20, 2002 at 07:21:01PM -0500, Adrian Farrel wrote:
> > 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, that is what I meant.

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

That is right again. Thanks for clarifying it.

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

I would agree with that.

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