Subject: initiating a discussion on mpls singaling protocols

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Jul 2002 13:42:02 +0200

All,

at the mpls wg meeting at the 54th IETF in Yokohama the issue of having
two functional similar (not to say overlapping) protocols addressing
the same functional space, as rsvp-te and cr-ldp were brought up.

The background is that when the signaling protocol for mpls traffic
engineering and setting up explicit / constraint based routes were
designed, there were two different approaches. One  based on rsvp and
the other on ldp. It was not at that time possible to resolve the
differences between the two approaches and this protocol duplication
as been reflected in creation of sometimes functional duplicate
specifications.

Since then both protocols has been progressed to proposed standard
and implemented.

However, as has been shown in the survey on signaling protocols for
GMPLS the implementations of rsvp-te far out number the cr-ldp
implementations. As there are issues with having two similar standards
(potentially diverging), and it generates duplicate work in several
ietf working groups, the question was asked whether we should make
cr-ldp informational (which still make it available and possible to
work with) and progress only rsvp-te on the standards track.

At the meeting there were a wide spread support for this idea, but
it was ruled that it was premature to call wg consensus on this at the
meeting and that we wanted to take the discussion on the mpls mailing
list.

This mail is to initiate this discussion. Please keep the discussion
on the mpls list, do not cross post other lists. A separate mail to
the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this
discussion.

/Loa

-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           [email-masked]
     WWW             www.utfors.se

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Thu, 18 Jul 2002 20:15:00 +0400 (RET)

Hi,
  A long time pending issue for discussion. To beging with

1. In my opinion the number of implementation can't be a good metric to
dictate a standard. A better approach and design matters much more than
this. We see more implementations of rsvp rather being taken up as
extention to the existing code base. So all those people who would have
gone for rsvp-te extention to leverage on this advantage of existing code
with them.

2. CR-LDP is designed for a specific purpose of enabling mpls networks
forTE. Where as rsvp-te is one which was meant for a different purpose which
has been modified for this one. So it has come here with all its
drawbacksand limitations. I see CR-LDP as a much cleanner and focussed
approach to address specific issues and is more flexible.

3. The scalability issues of rsvp is a known fact today (soft state=20
maintenance, refreshment, error handling etc)...because of which the
plain rsvp itself never took off in a big way in internet.

The list grows....
So need to say now that I am a CR-LDP man.....

regards
Bhushana

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Jul 2002 11:02:32 -0400

Loa> the  question was  asked whether  we should  make  cr-ldp informational
Loa> (which still make it available  and possible to work with) and progress
Loa> only rsvp-te on the standards track. 

This seems like a very good idea to me.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 18 Jul 2002 11:09:25 -0400

Sounds like a pragmatic approach to me.

         --Tom

>the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: RajivPapneja <[email-masked]>
Date: Thu, 18 Jul 2002 11:36:53 -0400

>the question was asked whether we should make

The answer to this question is "yes" (as we have seen so far in the 
"discussion" thread) and everyone of us know that based on the actual 
implementations/deployments.  But, I think SPs should step in to make this 
call because eventually they are the ultimate users for the MPLS-TE protocols.

  Thanks,
   -Rajiv

---

From: Sachin Kalra <[email-masked]>
Date: Thu, 18 Jul 2002 11:48:17 -0400

Yes, I support this proposal.

Thanks,
Sachin Kalra

---

From: Ron Bonica <[email-masked]>
Date: Thu, 18 Jul 2002 11:37:03 -0400

> plain rsvp itself never took off in a big way in internet.

Many operators have deployed RSVP-TE. Are you aware of any who have deployed
it and run into scaling problems?

                                                   Ron

---

From: Bora Akyol <[email-masked]>
Date: Thu, 18 Jul 2002 11:18:51 -0700

We went through these same discussions in 1998. It may be argued that RSVP
has some scaling problems but in real deployments, none of these 
materialized.
So, I think the market has spoken already.

I support making CR-LDP informational and RSVP-TE standard.

Bora

---

From: Ping Pan <[email-masked]>
Date: Thu, 18 Jul 2002 11:34:35 -0700

Hi,

You seem to be confused here. RSVP-TE and the classic RSVP are meant for 
two completely different applications.

Generally, "scalability", an over-used term, can be represented in two 
parameters: the number of connections that a router can handle, and the 
number of connects that a providers can handle

RSVP-TE is used for MPLS, where LSP's normally don't change. Thus, by 
simply reducing the amount of RSVP refresh messages (via RSVP refresh 
reduction), a router can handle thousands of sessions without any 
problem. I think Ron Bonia's network has a couple hundreds of LSP's, and 
I have seen other networks with a couple thousands of LSP's. By turning 
on refresh reduction, routers don't seem to have any problem. I have 
seen routers that can handle 50,000+ LSP's.

Note, even when network links and nodes are going up and down, with a 
proper RSVP-TE fast-reroute implementation, there won't be any 
performance problem. The one-to-one fast-reroute is to establish LSP's 
ahead of failure, so no extra RSVP signaling is required when a node or 
a link is down (other than some error messages once in a while). The 
facility fast-reroute is to aggregate all RSVP messages into a 
pre-established bypass LSP at failure time, thus no performance problem 
here neither.

The only problem that I can see so far in MPLS is that there is no 
efficient method to manage too many LSP's in the network. Remember, the 
LSP's can be used for VPN's. How to map, monitor and diagnosis network 
resources, routes and LSP's, etc. is not a simple task. But this 
manageability problem is the same for both RSVP-TE and LDP.

Now, back to RSVP, when it is used to provide QoS signaling for 
inter-active real-time sessions (such as voice), it does not work well. 
This is mainly because the duration for real-time sessions is normally 
short. An average phone call is 3-4 minutes. When you plug in the 
network topology of an existing SS7 network, and the desired goal of the 
3G networks, the number of RSVP session changes (on/off traffic sources) 
is in the range of a few thousands sessions *per second*. When using 
RSVP, routers will be under a lot of stress. In this case, RSVP is not 
sufficient, refresh reduction has no use, and the soft-state approach 
seems to be a joke. I think this is the problem that NSIS WG is trying 
to handle.

2 cents,

- Ping Pan

---

From: Monique Morrow <[email-masked]>
Date: Fri, 19 Jul 2002 02:15:56 +0200

Yes -- reasonable approach

---

From: Zafar Ali <[email-masked]>
Date: Fri, 19 Jul 2002 02:29:38 -0400

I favor this notion; BTW I already saw that the majority is in favor of 
this proposal.

Thanks

Regards... Zafar

---

From: Vinay Vernekar <[email-masked]>
Date: Fri, 19 Jul 2002 16:44:48 +0530

I don't agree with the proposal of making CR-LDP as informational and RSVP-TE as

the standard. The current deployments may not be indicative of CR-LDP not being
a standard MPLS protocol. RSVP-TE being an extension to existing RSVP protocol
addresses the IntServ model of resource reservation, whereas CR-LDP which is
extension to LDP for QoS signalling should be flexible enough to address IntServ

and Diffserv over MPLS models. Such a signalling protocol is a need for Next
Generation Networks.

Vinay

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 19 Jul 2002 14:31:09 +0200

Hi,

At 20:15 18/07/2002 +0400, Nagabhushana Ramaswamy Nadig wrote:

>dictate a standard.

but the number of deployment might be a good metric ...

See bellow

>A better approach and design matters much more than

Again sorry to be so pragmatic but my impression was that this argument had 
been debated a while back and it seems clear this is a non argument. 
Thousands of TE LSPs have been demonstrated in real-life networks without 
any scalability problems. If you have any concern with refreshes, just use 
RFC2961. Then if you want to reduce the number of TE LSPs, introduce 
hierarchy.
Do not confuse RSVP used in the context of Interserv with per-flow 
reservation and RSVP TE for TE LSP.

So the proposal of making CD-LDP informational and progress only RSVP TE on 
the standards track looks very reasonable to me.

JP.

---

From: Loa Andersson <[email-masked]>
Date: Sat, 20 Jul 2002 07:14:23 +0200

Zafar and Rajiv,

thanks for comments. A quick word on process, at the meeting in
Yokohama it was very clear that we wanted to take a discussion on
the mpls mailing list.
Talking as a wg chair I think it is pre-mature to try to call consensus
just yet, wg chairs will do that when we have the picture, and hopefully
it won't drag out to far.
Nor did we give the (us) Service Provider any special role in this
(apart from what we always have), however you are right and I would like
to join you in encouraging SP's to step up and state their mind.

/Loa

RajivPapneja wrote:

 > implementations/deployments.  But, I think SPs should step in to make
 > this call because eventually they are the ultimate users for the MPLS-TE
 > protocols.
 >
 >  Thanks,
 >   -Rajiv

>>     WWW             www.utfors.se <http://www.utfors.se/>
>>
>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Sat, 20 Jul 2002 17:45:47 +0900

Vinay,

>and Diffserv over MPLS models. Such a signalling protocol is a need for Next

You need to read RFC3270 "Support of Diff-Serv over MPLS". You should then 
realise that Diff-Serv is supported in the exact same manner with both 
RSVP-TE and CR-LDP.

I do not see any benefit of one protocol over the other as far as Diff-Serv 
support is concerned.

Cheers

Francois

---

From: "Rajiv Papneja" <[email-masked]>
Date: Sat, 20 Jul 2002 10:02:05 -0400

Thanks Loa for recognizing my point. I hope we can have consensus with SPs
input.

-Rajiv

---

From: Matt Squire <[email-masked]>
Date: Sat, 20 Jul 2002 16:58:15 -0400

Count me as a big "yes" for the idea.

---

From: Zafar Ali <[email-masked]>
Date: Mon, 22 Jul 2002 00:47:27 -0400

Hi Loa,

Thanks for the follow-up. I completely agree with you.

Regards... Zafar

---

From: "sailendra mahanty" <[email-masked]>
Date: Mon, 22 Jul 2002 13:41:37 +0530

This looks a good idea to me too as to the majority of the group.
I believe that we can scale efficiently with RSVP.

Regards,
-Sailendra
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
Rosen
Sent: Thursday, July 18, 2002 8:33 PM
To: Loa Andersson
Cc: MPLS wg; George Swallow; scott Giles; Wijnen, Bert (Bert)
Subject: Re: initiating a discussion on mpls signaling protocols

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: [email-masked]
Date: Mon, 22 Jul 2002 15:17:12 +0200

i definitely support the idea to progress rsvp-te on
the standard track and cr-ldp as informational only 

deployment reports (from the user community) can also 
help here (in addition, development report as delivered 
by the gmpls survey should also give a good orientation 
to the discussion)

- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

---

From: avri <[email-masked]>
Date: Tue, 23 Jul 2002 15:26:03 +0200

This seems to me a very strange proposal.  And in fact seems to be
a perversion of the IETF standards process as i understand it.

If things are as argued, then RSVP-TE will progress to draft standard
and then to standard, while CR-LDP remains a proposed standard.  If
it languishes long enough in the proposed state, without significant
deployment or utility, then it would seem appropriate to transition it
to historic at some point in the future.

Taking it to informational at this point seems a fairly blatant political
move without technical merit.  At best it is an administrative sleight
of hand that could strange repercussions as a precedent.  Is the IETF
going to embark next on an effort to define all protocol duplication
out of existence by voting on which alternative to make informational?

I would suggest (as voting is not something I thought the IETF did) that
both protocols remain as ps. If CR-LDP withers on the vine because it has
no utility, so be it.  Voting to change its status seems inappropriate to
me.

a.

---

From: Zafar Ali <[email-masked]>
Date: Tue, 23 Jul 2002 12:05:13 -0400

Dear Fellows,

Since the myth that CR-LDP is more scalable than RSVP-TE or that CR-LDP is 
technical more sound idea than RSVP-TE is mentioned many times on this 
tread, a few key points that are already raised by many on this list, but I 
see people keep making bold statements like CR-LDP is more scalable than 
RSVP-TE or is technically better than its RSVP-TE counter part.

By just moving the responsibilities from one layer (signaling) to another 
layer (TCP), one cannot say that they have a technically more profound 
solution. Not to mention TCP also have refreshes and acknowledgements, but 
it's just that they are hidden.

In short, when people say that CR-LDP is more scalable, are they stating 
that building a reliable layer on top of an unreliable network comes for 
FREE? Not to mention, relaying on the TCP layer to ensure data validity is 
an issue on its own (E.g., just look at the fault tolerant draft (I'll be 
back type of scheme), where signaling layer try to solve the problem of 
relying on TCP).

With refresh reduction, the amount of traffic is minimized and we have 
evidence from field, practical experiments (not simulations) that this is 
NOT an issue. So, I think the argument that RSVP-TE does not scale due to 
refreshes is only academic in nature.

Anyone who argues that CR-LDP is more scalable should provide evidence 
based on every packet that is sent by CR-LDP (including TCP control 
traffic) vs. every packet that is sent by RSVP, both in steady state and in 
transient conditions. Please also don't forget that CPU and control 
bandwidth usage matters more in the transit case, than in steady state 
case. In transit, in general, you will see more packets flowing in CR-LDP 
case than in RSVP-TE case.

RSVP refreshes is a FEATURE and is in sprite of making the protocol soft 
state in nature.

Soft state vs. (so-called) hard state is another non-issue. Each approach 
has its advantages and anyone stating hard state is better than soft state 
can never proof it quantitatively.

Thanks

Regards... Zafar

---

From: Ping Pan <[email-masked]>
Date: Tue, 23 Jul 2002 12:03:04 -0700

Zafar,

While I agree with your assessment in general, I don't think TCP 
oervhead is a big deal. TCP sockets or IP raw sockets (which RSVP may 
use) do not impose that much of processing overhead. UNIX VM has done 
wonders! In fact, under stress condition, both socket types will have 
the similar performance problem, that is, PCB's are queuing at socket 
level....

Regards,

- Ping