Subject: RE: RSVP-TE and PW

From: Benny Ammitzboll <[email-masked]>
Date: Wed, 29 Sep 2004 16:35:42 +0200

Come on, let's have it on the table: Isn't the case simply that Cisco had
developed LDP and tried to push this for TE tunnels, but lost to RSVP-TE? In
comes PW setup and voila - LDP is back in the game...

I agree fully that it seems a bit much to have to implement another protocol
JUST to carry a label value from one node to another... Oh, and to do so
both nodes must be touched first...

However, RSVP-TE does have some refresh overhead that becomes nasty when
there are many tunnels...

/Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Diego Caviglia
Sent: 29. september 2004 15:38
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] RSVP-TE and PW

Eric,
           I see your point and I can agree with you but what I was
actually meaning is: given that RSVP-TE is better than LDP for set-up
tunnel in the PSN network (do you agree?) and there no advantage, at list i
don't see any advantage, in using LDP in order to set-up PW why not use
RSVP-TE for both PW and Tunnel set-up?

The botton line is why I have to implement two different signalling
protocol in my box?

Regards

Diego

Eric Rosen <[email-masked]> on 09/29/2004 03:27:03 PM

Please respond to [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Sep 2004 15:39:18 +0100

Diego Caviglia wrote:

>tunnel in the PSN network (do you agree?) 
>
Well it's different rather than better.

An LDP tunnel has the property that it tracks what the IGP thinks is the 
best path and
repairs as necesary. So if the service was a best effort Ethernet, and 
that in turn was being
used to carry IP, then LDP would be a very good tunnel setup protocol.

RSVP-TE has static properties that may or may not be an overall benefit. 
For example
if you initiate the PW when the network is in some sub-optimal state due 
to a transient
failure, you may make sub-optimal use of network resources for the whole 
lifetime
of the PW (which may be a very long time).

Both can be protected by FRR if that is a requirement.

>and there no advantage, at list i
Well for a start, no one made a comprehensive proposal to use RSVP when 
we started
this work so we could not do a competitive analysis.

As things stand we are just putting the finishing touches to the LDP 
approach. The
LDP approach works, so there will need to be a good reason why we would 
want
a second competing approach with all the interoperability issues that 
would result.

>The botton line is why I have to implement two different signalling
Suppose we do persue the RSVP approach on the table. The standard IETF
approach would be to declare one of them mandatory. Given that LDP should
be an RFC by the time RSVP PW signalling even gets to the IESG, the
mandatory  protocol would almost certainly be LDP. So you would end up
with two PW signalling protocols on your box to make it conformant.

- Stewart

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Sep 2004 10:44:05 -0400

> given that RSVP-TE is better than LDP for set-up tunnel in the PSN network
> (do you agree?) 

Only if the tunnel is traffic engineered. 

> The botton line is why I have to implement two different signalling

Well, if  you're building a  box, you should  know that there are  many more
deployments of LDP than of RSVP-TE. 

But one could equally  well ask, "if I have implemented LDP  as the PW setup
and  maintenance  protocol,  as specified  by  the  PWE3  WG, why  should  I
implement  a  second PW  setup  and maintenance  protocol,  when  it is  not
necessary to do so in order to solve any problems?"