Subject: bi-directional LSPs

From: Rohit Dube <[email-masked]>
Date: Tue, 19 Nov 2002 16:25:57 -0500

Hello,

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

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

The updated version of the draft should appear on ietf's
web-site when the draft queue starts getting processed again.

Regards,
--rohit.

---

From: Rohit Dube <[email-masked]>
Date: Wed, 20 Nov 2002 22:00:56 -0500

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Nov 2002 19:21:01 -0500

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

> 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

I think at this point you really need to differentiate between label objects and
the labels they carry.

Asymmetric bidirectional LSPs are a different matter altogether.
If there is a requirement for this, it should surely be moved to ccamp.

> 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

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 21 Nov 2002 13:52:50 -0800

Comments inline:

> "normal" 23 bit MPLS labels. The Generalized Label Request can ask for such

Yes, that is what I meant.

> > Here is some further clarification on the topic.

That is right again. Thanks for clarifying it.

> If there is a requirement for this, it should surely be moved to ccamp.

I would agree with that.